I’m trying to interface my Spark Core with a medical device that puts out serial data in ASCII format @ 9600 baud, 1 start bit, 2 stop bits, 8 data bits (e.g. SERIAL_8N2 if I was using an Arduino). It looks like the core is hard-coded to use 1 stop bit (hence the junk data I’m getting when trying to capture serial data after passing the RS-232 signal through a logic level shifter).
void USARTSerial::begin(unsigned long baud, byte config)
Can anyone provide any guidance on how to go about adding SERIAL_8N2 (and other bit/parity configurations) on the core? Can I make these changes using the web IDE or do I need to download the firmware and make the changes / flash those changes using DFU-util?
@jmekler, in order to pass the configuration parameters to the USART, you would need to modify the HAL begin() code. That would mean parsing the “config” byte to then set the USART_InitStructure correctly. None of this can be done on the web IDE so you will have to install the toolchain and pull in the HAL branch. If you get things working, you could put in a pull request with your changes
@peekay123 I took a cut at modifying the firmware, building, and flashing to the core. I haven’t had a chance to test whether the USART is working yet, but will plan to give it a go as soon as I can get my hands the device I’m working with (sometime later this week).
The current commit exposes most of the STM32’s USART functionality (e.g. everything except disabling RX/TX), and the USART configuration can be specified from a predefined configuration (e.g. Serial1.begin(9600, SERIAL_8N2);) or by combining different configuration flags (e.g. Serial1.begin(9600, FLOW_NONE | WL_8 | PAR_NONE | SB_1);). It might make sense to provide the most common configurations and allow users to access the configuration flags for less common configurations (e.g. 9N1.5).
@jmekler, just some quick feedback. Hardware flow control on the STM32 requires specific GPIO pins. Those pins are not currently mapped onto physical pins of the Core, explaining why HW flow control is not implemented. Also, if you are defining 9-bit operation, then the ISR , all buffers and supporting code will need to change since they are currently setup for 8-bit operation.
In my own experience I have only seen 7-bit and 8-bit configurations with variations on parity (none, odd, even) and stop bits (1 or 2). The STM32 does not support 7-bit operation so that leaves 8-bit as most common. My recommendation is to support variations of the 8-bit protocol only, keeping the base code compatible with Arduino.
I realized I wasn’t working on the HAL branch, so I switched over an implemented the code on that branch. Hopefully I put things in the right places… Here’s the diff from the spark/feature/hal branch and summary of changes:
On second thought, it might make more sense to put the SERIAL_XXX definitions in a conditional macro so that the compiler throws an error if someone tries to use an invalid configuration (e.g. SERIAL_5N1 on the Core).
@jmekler, nice work! I agree with the SERIAL_XXX conditional macro since the full list can be misconstrued as being supported by all platforms. You may want to put default cases in your switch statements as an extra precaution OR have PLATFORM_ID specific IS_USART_CONFIG_VALID macros.
Also, after looking at the pin mapping on the Core (not sure about Photon yet), hardware CTS and RTS lines are brought out at the expense of using a GPIO line. Not sure if this is really necessary to support.
Just want to say that I am eager to see this enhancement (i.e. support of parity) as I need it to communicate with a heat pump! Great to see someone is working on it already. I was afraid I had much more work ahead of me!