Serial protocol for communication with Flash Synth

Welcome. Please log in or register.

ddmm64	Posted: 16 May 2021, 09:07 AM
Member Posts: 4 Joined: 16-May 21	Hi, first of all let me say the Flash synth is a really nice piece of hardware and it sounds great! One part I don't like so far is the Universal Tuning Editor. It looks nice, and I've managed to sort of make it work, but so far it's been a struggle. Quite crash-prone on MacOS and super slow on windows. I'm not sure why, maybe some driver issue I could figure out at some point. It seems like communication is happening through a USB-serial connection. Would it be possible at some point to document how this communication works? It'd allow people to implement other editors, such as one for Linux (my daily driver). Thanks! -------------
	[top]

mit	Posted: 16 May 2021, 07:00 PM
yeah whatever Admin Posts: 566 Joined: 4-May 16	Hi, the protocol is actually the standard UART bootloader protocol used by STM32 chips. This is documented both in the official documents from ST and through several open-source implementations. I personally haven't used the UTE software, I merely described the protocol as part of the handover to Aaron. For the development here I was using a modified version of the stm32loader python script. In addition to the uart protocol, the programmer units use RTS and DTR to power-cycle and switch between boot modes. The tedious bit is the memory map of the chip, for instance the tuning tables are stored as blobs of IEEE754 float32 values which have been multiplied by a specific constant. If you're really keen I can dig up some of the details about that. -------------
	[top]

ddmm64	Posted: 18 May 2021, 06:59 AM
Member Posts: 4 Joined: 16-May 21	Understood, thanks for the info. I'll check that out! The newest version of UTE seems more stable on macos (even if still a bit weird I think), so it's not too pressing. Thanks again! -------------
	[top]

ddmm64	Posted: 18 May 2021, 07:26 AM
Member Posts: 4 Joined: 16-May 21	Ok, I think I get the idea. I'm assuming UTE does not recompile the firmware every time, but instead swaps values in the binary file and uploads that. Looking at the memory map visualization in the blog, it seems like the patches would be near the bottom, so if I wanted to change/add patches I would have to tweak those. Out of curiosity, is it possible to overwrite only parts of the memory map? Actually, some more pointers (literally, lol) on how the patch parameters are laid out in memory would be nice. (TBH I don't really care for alternative tunings, so I'd leave those as-is. No offense to Aaron ;). Thanks! Last edit by ddmm64 at 18 May 2021, 07:27 AM -------------
	[top]

mit	Posted: 19 May 2021, 04:13 PM
yeah whatever Admin Posts: 566 Joined: 4-May 16	Flash memory has to be erased and re-written in pages. From memory I think the STM32L432 has a page size of 2kB (might want to check that). The patches cover 8kB starting from 0x803c000, and there are 128 patches of 64 bytes each. Each patch starts with a list of parameters, one per byte, corresponding to different knobs, in the following order: cc_modulation cc_algo cc_fm_freq cc_fm_freq_fine cc_fm_depth cc_fm_attack_rate cc_fm_decay_rate cc_attack_rate cc_release_rate cc_waveform cc_wave_param cc_lfo_freq cc_detune cc_arpeg_speed cc_portamento cc_output_gain cc_pwm_depth The rest of the patch contains an ascii string representing the name of the patch, but that's just for convenience, the synth doesn't read it or do anything with it. -------------
	[top]

ddmm64	Posted: 21 May 2021, 10:23 AM
Member Posts: 4 Joined: 16-May 21	That's great, I'll see what I can come up with! -------------
	[top]