I just stumbled upon this platform a few days ago and I’m evaluating it for use in our product.
The one thing that could be a show stopper or only having access to 1 USART port. Our product at the moment really needs two USART ports as we don’t want to use a digital/analog multiplexer.
Will a version of the Core be made that breaks out another USART to another set of TX/RX pins?
Or, any ideas how to accomplish this without another USART port, and I’m not a fan of bit banging…
Yup. If I remember correctly the I2C pins can be repurposed for UART duty. In fact, if you could get access to two timers you could make a highly reliable software UART as well.
Another option is to get a cheap $0.15 micro (like a PIC or MSP430) and make a Serial to I2C bridge. I’ve actually got this going with the 430 and it works brilliantly up to 115kbps.
Oh, I’ve seen TI do .20~ on 1xxx and G2 series at 5k (might have been 10k) quantity. This was a couple of years ago, but I’m sure they still work deals.
Anyway, there are .05, .10 and .15 cent MCUs out there, you’ve just got to know where to look. What do you think they put in your electric toothbrush and universal remote?
Give me a bit and I’ll get you a couple of links. There’s a whole world off cheap off-brand micros out there!
Hi, I’m looking for 8N1 9600 baud and don’t need hardware flow control. However if the pins for rx/TX are available shouldn’t the firmware / libraries be able to be updated to use them as Serial2 just as the first uart is supported in software?
The idea of using a small chip to cobble a second serial port together is interesting but seems less than optimal.
Are plans being made to support the second uart in the firmware?
If you want it ASAP and can build locally it can be done fairly quickly, (but not ideally from a space, maintainability perspective).
Replicate the current spark_wiring_usartserial.cpp file and change all the references to UART2 things to UART1, then in the begin, ensure to set the alternate pin functions so that D0, D1 are enabled to UART1
I would do it for you but, I am backed up on my client’s jobs at the moment.
Alright you made me look at the file. yep it does look that simple but I did not check the data sheet.
Also check Wiring_USART1_Interrupt_Handler (Declared as weak in stm32_it.cpp) if it is not there make it so.
If it is the same IRQ demux it in stm32_it.cpp to Wiring_USART1_Interrupt_Handler or Wiring_USART2_Interrupt_Handler
Mind you, this is not the long term solution. You could even revert to the non - interrupt version of spark_wiring_usartserial.cpp and mod that file for a “Quick” fix.
Thanks everyone. I’m going to be buying a few of the Cores to experiment with and create a prototype board. Hopefully by the time I’m ready the firmware will officially support the second UART.
Who know, maybe I’ll end up with the time to work on the support and / or help finish it up.
team is focusing on the higher priority issues before the rest gets implemented