Max serial input?
T Chap
Posts: 4,223
in Propeller 1
I have a certain device that is currently sending via serial>USB to a PC GUI a stream of data at 460K. I'm looking to connect it to the P1. For a short wire, not PCB trace, less than 6" from board to board what can you get as max input baud and using what serial object?
Thanks
Comments
Which direction, and can this be half-duplex ? Is that 460k the data size, Byte rate or Baud rate ?
If your USB-Serial part fixed choice ?
eg google finds
https://forums.parallax.com/discussion/156376/serial-i-o-throughput-a-comparison
That mentions 5MBd but not all USB-UARTS can manage that setting, so that may be what actually sets your upper limit.
If playing above 4MBd things are simpler with HS-USB parts, which gives the choice of FTDI and WCH.
FTDI parts are 24MHz/N, so they can do 6MBd (96MHz P1 osc) but not 5MBd.
The WCH CH347 manages 120MHz/N from 9M down to 2M (more granular below that) so it can do 5MBd.
https://www.tindie.com/products/johnnywu/ch347-development-board/
Thanks for the info jmg. I just asked about the part, they said 460k bits. I think it only needs to be received on the Prop. If there is a case to send back to the device that would be rare and can be slow.
460k Baud should be no problem.
How much data and where does it need to go ?
As others have indicated, if you're only receiving you can get pretty zippy, even with the P1. I've attached a simple RX-only object that should work for you. You can adjust the RX buffer size as you see fit.
Great thanks I'll check that out! I have someone taking an STM32 part and trying to send data to P1, so I don't know a lot of specifics yet. It's seems like it will be a stream of 128 bytes back to back. From the VL53L5 sensor being read by STM32F01RE. I'm going to attempt to take the 64 zones that create a WORD so 64x2bytes minimum and do math on those in the P1 since I don't know how to program C it will be easier to do what I want and let the STM just stream the data out.
You could get them to select 2 stop bits in their stm32 code, as that gives more headroom for the software bit-bash to store bytes.
Then you can decide on a baud rate and packet sizes by mutual agreement.
If the Rx code uses waitcnt (as #5 does) the bit-time is N/80MHz granular so 460kBaud is good to ~ 0.05%
Good to know I will pass the info on. I get the P1 boards tomorrow, hope to have this running this week. I had another thread where I discussed a lot of buttons and LEDs, this the same just now trying to find the best and fastest way to get the data in and work on it. Hopefully SPIN does the job fast enough. The STM is not fast enough to read at a good enough read rate AND to the math I need to add to it. There is a C for the sensor to run on the STM but it is a beast of code to try to port to P1. I really don't know if it would run/fit as is or with mods and don't have time to chase it down. I need to solve an issue and this is down and dirty. Use the existing demo code on their EVAL board ( nucleo and VL53L5 SATEL). Stream the data to P1, let the P1 do all math, watch buttons, run the 64 RGB LEDS ( WS type). Then hopefully between the two processors make it work. I built I2C extenders on this board in hopes that I could run I2C for 25'( Like I do easily on other Omron Thermal sensors). But they run their demo at 1Meg. It's unlikely to run the extenrder IC method that fast having Nucleo/P1 on one end, VL53L5 on the other end of the wire. So that means probably putting Nucleo and Sensor together, run RS485 out of it to the P1 at 25' and see if the speed holds up that way at 460kbits.
Got boards in today, testing baud rates soon.