3 weeks ago, I ordered a Zynthian V4.4. I now see that V4.5 is being sold.
Is there a document that concisely describes the changes in Zynthian hardware from version to version?
Such a document would be invaluable to me as a software developer, to make sure that any changes I might make won’t break older (or newer) versions of the hardware.
cheers!
I don’t know of such a document (concisely describes the changes).
The Zynthian wiki page:
wiki.zynthian.org/index.php/Zynthian_Box_Building
Has a list of tutorials for all the versions with their build instructions so you can see the changes there.
Thanks @tunagenes
I figured the answer was that none existed due to the deafening silence.
Given that collection of build instructions you point out, I suppose I could infer an evolution of hardware by reading between the lines. That’s a lot of work. On the other hand, as people have evolved the hardware, it should have been natural to capture documentation as new variants of Zynthian are developed and released. But I guess that wasn’t the case.
Another potential answer to my query might have been: “all hardware differences are abstracted away by device drivers; if you use the driver correctly, the underlying hardware differences will be hidden from your software”.
However, my understanding is that the encoders rest on shaky ground. But that is the least of my concerns.
I’m mostly interested in understanding the architectures of the codecs and the display, especially as they have evolved over time.
¯\(ツ)/¯
Thanks again.
cheers
Well, on one level it’s a raspberry pi, which is a general purpose computer. All hardware is pretty much abstracted by the Linux Kernel at some point.
On the official kit audio is driven by the i2s bus to the DAC. I doubt there is much in the way of codecs. I think it’s just like a PWM signal from ALSA.
There is an official display but as people build their own projects all sorts of display configurations are available.
Have a rummage around the zynthian github repos.
That, in itself, can be quite an achievement in an audio device.
Mostly it’s about indexing. The information is all there but like all documentation people want access via an indexing system that aligns with their specific approach. That’s many, many paths and frequently one can be the first person to approach from any specific direction.
We tend to try an add a bit as we go, and as this is an open source environment we have considerably more to cover than commercial products. The actual chunks of audio we collect as go is confirmation of the legitimacy of the device, to confirm what we say can be done actually can be! so I hope if you do some research then please share your walk path. We are in the throws of a heavy redesign of the gui front end in the light of new software components and part of that proofing is ensuring that the devices support the existing hardware instances. In our world that means the hardware crazies like myself as well as the versioned hardware instances. it’s kind of summed up as 
The hardware components of an official kit started out as an expansion board using i/o on the existing GPIO port with a couple of designs of encoder boards.
Transited to 12c boards built around the MCP23017 , we then had all the upheaval of the Pi 4 and it’s considerable changes, then the integration of the screen and encoders into one board and then the addition of the hardware additions for CV & trigger in/out.
There have been changes in the audio cards during the history, we didn’t even have an audio in in the early days. All this can be comfortably configured via the webconf, and that layer of abstraction has worlked pretty effectively. The GPIO mechanism that configures the encoders copes with both i2c and GPIO in a similar fashion and that continues to be the case.
The zynthian plugs audio hardware together at the Jack level and hardware is presented at that level and configured, once again, in the webconf.
Have a look here too for hardware:
And especially in:
and what is supported:
the "dtoverlay= parameter is a good query string:
Edit:
This directory is a must too regarding the Alsa ASOC layer:linux/sound/soc/bcm at rpi-5.10.y · raspberrypi/linux · GitHub
And that one for the sound codec driver itself: linux/sound/soc/codecs at rpi-5.10.y · raspberrypi/linux · GitHub