I was wondering if anyone has gotten bluetooth support with Daisy? There are some interesting micro usb bluetooth dongles that could be plugged into the secondary USB ports. Would love to be able to control Daisy from a smartphone and I think I could contribute some support for this.
Just wanted to drop some notes as questions as I find things. Iām a fairly proficient C/C++ engineer but have very little hardware experience. One potentially easy path to success here is using something like this:
From a hardware perspective, it seems like libDaisy has serial communication and most of the Daisy hardware models give access to all the pins.
I ordered one and a DaisyPod, Iāll post if I make any progress 
I donāt think Iāve gotten back around to adding all of the configuration options to the UART driver yet, but the part you linked looks like it could work.
If you need to do any reconfiguration you can edit the settings directly in src/per/uart.cpp if you get around to trying this out before I have time to add it to the driver.
The settings for UART 1 are currently fixed to 8bit, 1 stop bit, no parity w/ 31250 baud rate.
It looks like based on the product page that the CTS/RTS pins are necessary, which are not available on Daisy for UART1, but doing a quick check on the pinout it looks like RX, TX, RTS, and CTS are all broken out for the UART5 peripheral which will definitely require updates to the uart driver to function.
So that may give you a bit of a good start for rolling something up to work. Happy to answer any questions, and Iāll hopefully have a chance to flesh out the libdaisy driver soon.
Excited to see what you do with it!
1 Like
Thanks! Iāve always wanted to learn what writing drivers entails, thisāll be fun! So CTS is sort of a gate to tell the other hardware that Daisy is ready to receive more data? Which Daisy pins are RTS and CTS for UART5? Daisy 6 is TX and 5 is RX, right?
As far as I understand you connect the host CTS to the device RTS, and vice versa, and they generally just assert that the device is ready for communication. Sort of similar to the chip select signal for SPI.
The pins shares a lot of the pins with the SDMMC pins:
| UART function | Daisy HW Pin number | DaisySeed::GetPin(number) | STM32 GPIO |
|---|---|---|---|
| UART5_CTS | 4 | 3 | PC9 |
| UART5_RTS/UART5_DE | 5 | 4 | PC8 |
| UART5_RX | 6 | 5 | PD2 |
| UART5_TX | 7 | 6 | PC12 |
I donāt have the AF mappings on hand at the moment, but thereās a table in the datasheet you can reference.
It works I did a quick test with USART1 at 9600 baud, tying the RTS and CTS pins to ground (you can disable flow control with that BLE module linked above by doing so) and I have data from/to my iPhone!
Iām assuming that right now if I want full flow control I have to use UART5, which means losing the SD card. Can I āhijackā other pins and use those for a re-wired sdcard or is the sdcard similarly inherently tied to certain pins at the HAL layer?
Also, could you share how you mapped the pins to the functions? Is there an exact STM32 datasheet for Daisy/chip Daisy uses? I think I found one that looks similar that indicates that USART1_CTS is available on the same pin as UART4_RX (which sort of makes sense layout wise), but Iām not sure this is right for Daisy. Which would be grand as I could do hw flow control using pins 14-11 without blocking the sd card.
Thanks for all the hard work on Daisy, I just realized youāre all over the codebase love this project.
Nice! glad you got it working! We should be getting to the update of the UART peripheral very shortly that would make it a bit easier to work with, especially without having to rebuild the library constantly.
The documents on this page are the most up to date for the processor itself. The daisy uses the STM32H750IB variant. The datasheet will have the tables with all of the alternate functions for each pin, the reference manual has specific info on how the peripherals work and what they can do. Sometimes things are named just differently enough between the reference and the ST HAL to be annoying, but if youāre using VS code or some other editor with intellisense. itās pretty easy to bounce around and find the structs/values you need to configure stuff.
There is also a csv pinout file for the Daisy that contains many of the alternate functions as well.
Hope that helps a bit
Thatās very helpful, thank you!
Excited about the UART improvements too. I just moved the class over into my own project and renamed it to something else to make my changes to it without recompiling libDaisy. Itās nice and self-contained from the rest of libDaisy!
Itās definitely an interesting game trying to find available pins to map out all the hardware features you want
Iām wondering if Iām being overly cautious with the desire for full flow control. At 9600 with a 256 double buffered receive buffer, it seems like data would be lost if the main loop takes longer than 213 ms to iterate. Right? Iām assuming I could always raise this up if I really need toā¦ Is there a way to use the SDRAM for this buffer? Still if the main loop is taking longer than a ~1/4 second things are going south elsewhereā¦
No problem!
Are you using the DMA mechanism (i.e. StartRx()) to fill your buffer, or are you just polling with the PollReceive() function?
If the former, what I normally do is have a separate RingBuffer of whatever data in whatever RAM region I want that can be filled with stricter timing requirements, and then less periodically process the stuff as necessary.
Right now the size of the internal FIFO, and all of the DMA configuration is completely fixed but that will become somewhat flexible as well with the update.
Currently using StartRX before the main loop and then PopRx while Readable() != 0 in the main loop to get the data out of the buffer as fast as possible.
Iām reading a custom format thatās variable sized using a really simple TLV protocol. Iām just sending that to the logger to verify itās working but my plan is to copy it to SDRAM as I PopRx. Itās a custom sequencing format that the audio callback will decode at runtime directly from SDRAM to trigger sounds (I guess itās kind of like Midi).
Iām basically building a step sequencer with multiple song parts controlled from a mobile app that synchronizes changes over to Daisy in realtime. So you play the mobile app and Daisy sings
1 Like
Yeah that sounds totally feasible, you should be able to just pipe the data youāre popping from the Uart into a RingBuffer/FIFO in the SDRAM or the internal SRAM for you to handle in your audio loop.
What a cool project! Would love to see it working once itās done! Youāve got me thinking of getting a few of those bluetooth modules, too!
1 Like
A comment from the āpeanut galleryā:
If you want-need flow control without having to sacrifice pins, you could use āsoftwareā flow control, where you embed flow control in the datastream. But I agree with your reasoning that you donāt need it for the present case.
Thatās cool! I was reading something about that earlier, but it was suggesting notifying when one side is sending and when itās done. I didnāt follow how that helped not overwhelm the receiver (send/receive buffers seem to be separate).
The only way I can think of rolling my own would be by doing something sort of similar to TCP/IP where you confirm/acknowledge having received ordered packets (some arbitrary protocol-specific defined size, with a simple checksum). If I see data corruption, maybe Iāll look into generalizing something like this, although itād definitely impact transmission speed even furtherā¦