I’ve had some ideas for alternate Yarns layouts (2x monophonic voices with velocity, and 6x controllers plus clock) and started digging into the code base.
I have some C++ experience from doing stuff in openFrameworks, but looking at unfamiliar code I still wonder if I’m hitting all the connection points I need to when making a new layout.
Does anyone have a stab at an alt Yarns firmware out there I could compare against? I could also post my diff and get thoughts… Do I really have to worry about bricking this thing via an update over the midi input?
Post your code to GitHub and point to it there. Start with a fork of Olivier’s repository so it is easy to see what you have changed. Then clone your fork to your deskktop or laptop, make your changes, and then push them back to your origin, which is your forked repository on GitHub. Use the GitHub client, it makes it easy.
If your compiled code is too large or otherwise overwrites the settings storage area, then yes, you could brick your Yarns via the audio interface. You would then need to recover it via the JTAG/SWD programming port on it (unlike other MI modules, it doesn’t have an FTDI serial port, so you can’t use the built-in serial bootloader in the STM32F1 chip on a Yarns).
Looks like I should grab the JTAG connectors then so I can un-brick if I screw it up. And if it simplifies deploying code to the module all the better.
I forked his repo and have a branch for my first idea (2x mono with velocity). If it works on the unit, I’ll make a little “Yarns alt-firmware” project page and post it.
I still feel like I don’t fully have a handle on the architecture or limitations, but i should get there if I keep digging around in the Yarns code base.
I had no idea what I was doing with the Braids code at first, but now I have a dim inkling. Ability to rescue your module is paramount. My advice is to ask people who can also unbrick theirs to test your code before you make compiled versions widely available. The last thing you want is a hundred angry Yarns owners accusing you of bricking their module with your modified firmware. Have a look at the warnings on my project page.
What I said above is not quite right. If your code overwrites the settings, then re-installing the factory firmware via the audio bootloader should work to recover the module. But if your firmware changes the settings, it is possible that if the factory firmware is re-installed, it will try to load your changed settings data and then crash or misbehave in a way that prevents recovery by just re-installing the firmware via the audio interface. Re-installing by JTAG will always recover it, of course.
To guard against this in Braids, Olivier aded some extra checking code in the Braids v1.7 firmware that automatically re-writes the settings if it detects that alternative firmware has been installed on the module. I don’t think that checking code has been added to Yarns, so just be cautious, particularly when providing compiled audio firmware files to others, until you are certain your hacks don’t prevent re-installation of the factory firmware. No-one appreciates a one-way trip.