It was so difficult to get the thing to work
the program is not documented
there is a strange mix of print and logging
the program lines can be apparently infinite
it seems OOP,but I could not find a object for the hardware rotary-switch.
The encoder and switch are split up
spread across different programs (c, phyton) and mixed in the applications!
To my surprise boots the system without error after removing the MCP23008.
So there is no detection at startup for a MCP23008 at address 0x20
the initialization should give errors !
A real configuration file (.json?) is desirable
so that there can be verified what to expect.
Yes, the zynthian UI code should be improved for better readability and structure. Zynthian started as a personal project and now it’s evolving towards something more serious.
The encoder code (zyncoder library) is programmed in raw C for performance and this can be quite confusing, also, the main program “zynthian_gui.py” is too long and dirty. In the next iteration i hope to refactorize and comment the confusing parts as well as split the code in smaller parts. Also, some tests must be added …
Please, when you have some time, share your modifications. I would like to study what you have done …
Anyway, congratulations for your work!! I hope to see your finished unit very soon …
I’m curious about the arrow-buttons panel. Do you intend to replace the encoder switches?
maybe you should make first some time to put on-line
the schematics and the test programs that I send you (private-mail).
Then I can also deliver the test program for the MCP23017 !
I’ve been asked by a musician to build one.
I am making preparations for mine.
I want a better way to navigate through the menus.
on the 4 free lines of the MCP23017 could either be
a nav-pad (photo) or an additional (5°) rotary connected
those than just used for the navigation.
I’ve added your shemes and test programs to HW repository:
Regarding the MCP23017, i understand that you have connected the rotaries to the MCP23017. Have you find a way to get IRQs from MCP23017 or have you modified the zyncoder library to poll the rotary’s pins?
Perhaps usefull… In another project I used the pikeyd keyboard deamon, which uses the interrupt function of the MCP chips… check: https://github.com/mmoller2k/pikeyd it has got a wiring diagram.
Also check the datasheet, because the pinout of the DIP package differs from the QFN package (int A and B on pin 19/20 for the DIP and 15/16 for the QFN)
Thanks for adding the shemes and the test programs.
As promised, I make a description of the use of the test programs in the next few days.
Which category is the best position, Hardware, Building Zynthian ?
I’ll also send you the test program for the MCP23017.
To the implementation, there must still be made at least one improvement
and the measurement of the pulse time should also be added .
I’ve thinking about this topic and now i’m pretty sure that the next “official” hardware reference should include your idea of not using the RBPi GPIO ports for the encoder/switches. It’s the best way to achieve compatibility with the different soundcards and displays. The MCP23017 is a good option, as we already have good experience with its “lite” version (MCP23008).
I will be adding the “interrupt” code for the MCP230XX in the next days. Stay tunned
If you look at the implementation of the rotary’s in ESN17
you will see that these are separate from the application(s)
I think it’s important to adjust your deployment
so that the rotary’s come loose from the application
and not mixed in the application as is currently the case.
In summary
a rotary consists of:
1/ Switch
a switch that you can press
the value is 0 if not pressed or
the time in ms from the time of impressions
2/ Encoder
the encoder has no 0 point, everything is relative
and can be rotated clockwise or counterclockwise by hand
the speed with which one does can also be a given
the encoder value can be: 0, positive (CW) or negative (CCW)
and is set back to 0 after the application has used its value
the speed value is the average pulse time in ms of the last 5 rotary steps
Currently this functionality and some more is implemented in the zyncoder C library.
Thre is some application code related to the different types of “switches” (short, bold, long, double):
def zynswitches(self):
for i in range(len(zynswitch_pin)):
dtus=lib_zyncoder.get_zynswitch_dtus(i)
if dtus>0:
#print("Switch "+str(i)+" dtus="+str(dtus))
if dtus>300000:
if dtus>2000000:
logging.info('Looooooooong Switch '+str(i))
self.zynswitch_long(i)
return
# Double switches must be bold!!! => by now ...
if self.zynswitch_double(i):
return
logging.info('Bold Switch '+str(i))
self.zynswitch_bold(i)
return
logging.info('Short Switch '+str(i))
self.zynswitch_short(i)
but that’s all.
Of course, the event management in the main app is not very clear and must be improved.
The ESN17 functionality should be implemented in the zyncoder module, using the wiringPi library.
The main app should be hardware-agnostic. Currently this is not completely true, but it will be.
I would prefer to move this conversation to a new topic. This one is not related
