So if i connect this module with P2, and use libraries listed at download links then will it work? Does anyone connected this module to P2 and enabled Wi-Fi connectivity on P2?
Because in example they are using wifi.h and this is not available directly on Flexprop C. Though wifi.h is present in libwifi folder in Download("32420-Parallax-ESP-2016-11-02-1804-e\parallax-esp-2016-11-02-1804-e\Examples\Propeller C\libwifi"), so planning to use that in FlexProp using this tutorial(https://learn.parallax.com/tutorials/language/propeller-c/parallax-wx-wi-fi-module-prop-c/join-module’s-wi-fi). So just want to know if this will going to work for P2?
Just a quick comment. So you know of some work already done in this space:
Without doing anything special but guaranteeing the P2 can buffer and not miss any traffic I had to drop the serial link rate down to 624KBaud. Just FYI!
This is all documented (configuring the RPi, the python code doing the comms with the P2, and the Spin2/Pasm2 code I use on the P2 side in the github:ironsheep/P2-RPi-IoT-gateway project. The P2 code also runs a dedicated Rx Cog with circular queuing at the message level (not character level) if I'm remembering correctly. There are also test programs for RPI and for P2 that test that link in a pretty loose fashion but they serve the purpose.
Also, you may want to take a look at some initial research I did into the RPi comms capabilities: github:ironsheep/RPi-P2D2-Support
and github:ironsheep/RPi-LED-Strings which deals with issues like creating a loadable kernel module so you have full performance control over the I/O without interrupts getting in your way, removing a processor form the Linux multi-tasking kernel so you have a full processor focused on your I/O effort, etc.
I had to drop the serial link rate down to 624KBaud. Just FYI!
Why?
I tested 4 Mbps, no problems except the proper cable needed to connect them. I needed as fast as possible link to transmit a video stream from a L515 depth camera connected to the RPi.
The P2 was fast enough (at 285 MHz) to display this stream on a screen connected to P2 via HDMI.
The link worked, but at the end I moved a lot of processing from the P2 to the Pi, which allowed me to slow down the link. I did it to add a safety margin - this hardware works inside a robot with a lot of EM noise (motors, switches, UVC fluorescent lamps power supply, a lot of DC<->DC converters, etc). That's why I used an Ethernet cable for the link.
I have a new toy now, it is called MiniDexed and it is bare metal RPi based synth which emulates Yamaha TX816 (!) It can output sound to i2s bus so I want to connect the P2 to this.
I had to drop the serial link rate down to 624KBaud. Just FYI!
Why?
I tested 4 Mbps, no problems except the proper cable needed to connect them. I needed as fast as possible link to transmit a video stream from a L515 depth camera connected to the RPi.
I think it depends on direction, and software.
Without hardware handshake, and with the Pi's relatively small FIFO hardware buffers, there will be limits on how fast a busy Pi can swallow data.
Sending from Pi to P2 should be more tolerant, as P2 can certainly keep up and any small pauses in Pi send due to OS activity, would be tolerated by P2.
Based on my tests so far, the CH347 can sustain its max 7.5Mbd duplex, (it has small pauses every 512 chars for some reason) and it has good baud granularity between 2Mbd and 7.5Mbd of 120M/N
My CH347 are 'on the plane', and I expect them to sustain 9Mbd (and maybe 12Mbd) when I get them here for tests.
It seems the claimed 9Md is not standard, the parts I tested managed 120M/16 max, which is 7.5Mbd
Still, 7.5Mbd is still faster than any FS-USB bridges can manage without handshakes.
@jmg said:
Based on my tests so far, the CH347 can sustain its max 7.5Mbd duplex, (it has small pauses every 512 chars for some reason) and it has good baud granularity between 2Mbd and 7.5Mbd of 120M/N
My CH347 are 'on the plane', and I expect them to sustain 9Mbd (and maybe 12Mbd) when I get them here for tests.
It seems the claimed 9Md is not standard, the parts I tested managed 120M/16 max, which is 7.5Mbd
Still, 7.5Mbd is still faster than any FS-USB bridges can manage without handshakes.
Update on CH347 HS-USB UART Bridge tests : I queried the CH347 7.5Mbd vs 9Mbd (on web) and they sent an internal firmware update tool
This changes
Before update : USB\VID_1A86&PID_55DA&REV_0140&MI_02
After update : USB\VID_1A86&PID_55DA&REV_0241&MI_00
NEW BAUD :
For > 7.5Mbd formula for 3 new baud rates is 144M/N for N = 16,17,18
9 * 16/16 = 9M (and anything 9-12Mbd gives 9Md, 15Mbd gives a error )
round(9M*16/17) = 8470588 also looks valid
9 * 16/18 = 8M ( this is useful for P1 highest burst speeds )
For Baud 2M thru 7.5M formula is 120M/N for N = 16..60
Below 2M, they seem to use a table of common baud, mostly 6M/N
At 9Mbd sustained average DUPLEX data flow (no HW handshake needed ) is 4.457*2/9 = 99.044% ie a 500k file sends/echoes in ~600ms
I had to drop the serial link rate down to 624KBaud. Just FYI!
Why?
>
I was doing round-trip communications with a P2 dedicated cog receiving traffic. The P2 wasn't keeping up at faster speeds (dropping chars). Go figure! If you find insight as to why please let me know! ;-). I was satisfied with the 600+ kBaud so I stopped investigating but from what you are seeing there might be headroom on the P2 that I missed. Hmmm... Oh and yes, cable length, probably shielding too, were issues that I saw as well.
Comments
Hello I have seen parallax-wx wifi module. And here is its examples and firmware links((https://www.parallax.com/package/parallax-wx-downloads/)).
So if i connect this module with P2, and use libraries listed at download links then will it work? Does anyone connected this module to P2 and enabled Wi-Fi connectivity on P2?
Because in example they are using wifi.h and this is not available directly on Flexprop C. Though wifi.h is present in libwifi folder in Download("32420-Parallax-ESP-2016-11-02-1804-e\parallax-esp-2016-11-02-1804-e\Examples\Propeller C\libwifi"), so planning to use that in FlexProp using this tutorial(https://learn.parallax.com/tutorials/language/propeller-c/parallax-wx-wi-fi-module-prop-c/join-module’s-wi-fi). So just want to know if this will going to work for P2?
Just a quick comment. So you know of some work already done in this space:
Without doing anything special but guaranteeing the P2 can buffer and not miss any traffic I had to drop the serial link rate down to 624KBaud. Just FYI!
This is all documented (configuring the RPi, the python code doing the comms with the P2, and the Spin2/Pasm2 code I use on the P2 side in the github:ironsheep/P2-RPi-IoT-gateway project. The P2 code also runs a dedicated Rx Cog with circular queuing at the message level (not character level) if I'm remembering correctly. There are also test programs for RPI and for P2 that test that link in a pretty loose fashion but they serve the purpose.
Also, you may want to take a look at some initial research I did into the RPi comms capabilities:
github:ironsheep/RPi-P2D2-Support
and
github:ironsheep/RPi-LED-Strings which deals with issues like creating a loadable kernel module so you have full performance control over the I/O without interrupts getting in your way, removing a processor form the Linux multi-tasking kernel so you have a full processor focused on your I/O effort, etc.
Why?
I tested 4 Mbps, no problems except the proper cable needed to connect them. I needed as fast as possible link to transmit a video stream from a L515 depth camera connected to the RPi.
The P2 was fast enough (at 285 MHz) to display this stream on a screen connected to P2 via HDMI.
The link worked, but at the end I moved a lot of processing from the P2 to the Pi, which allowed me to slow down the link. I did it to add a safety margin - this hardware works inside a robot with a lot of EM noise (motors, switches, UVC fluorescent lamps power supply, a lot of DC<->DC converters, etc). That's why I used an Ethernet cable for the link.
I have a new toy now, it is called MiniDexed and it is bare metal RPi based synth which emulates Yamaha TX816 (!) It can output sound to i2s bus so I want to connect the P2 to this.
I think it depends on direction, and software.
Without hardware handshake, and with the Pi's relatively small FIFO hardware buffers, there will be limits on how fast a busy Pi can swallow data.
Sending from Pi to P2 should be more tolerant, as P2 can certainly keep up and any small pauses in Pi send due to OS activity, would be tolerated by P2.
I'm curious to see if anyone has run a CH347 HS-USB-UART on a Pi, as that gives an 'significantly different' UART pathway that has much larger FIFO buffers than the basic Pi chipset UARTs , and USB support should be well tested on a Pi.
eg https://www.aliexpress.com/item/1005004685449797.html
https://lcsc.com/product-detail/USB-ICs_WCH-Jiangsu-Qin-Heng-CH347T_C5122332.html
Based on my tests so far, the CH347 can sustain its max 7.5Mbd duplex, (it has small pauses every 512 chars for some reason) and it has good baud granularity between 2Mbd and 7.5Mbd of 120M/N
It seems the claimed 9Md is not standard, the parts I tested managed 120M/16 max, which is 7.5Mbd
Still, 7.5Mbd is still faster than any FS-USB bridges can manage without handshakes.
Update on CH347 HS-USB UART Bridge tests : I queried the CH347 7.5Mbd vs 9Mbd (on web) and they sent an internal firmware update tool
This changes
Before update : USB\VID_1A86&PID_55DA&REV_0140&MI_02
After update : USB\VID_1A86&PID_55DA&REV_0241&MI_00
NEW BAUD :
For > 7.5Mbd formula for 3 new baud rates is 144M/N for N = 16,17,18
9 * 16/16 = 9M (and anything 9-12Mbd gives 9Md, 15Mbd gives a error )
round(9M*16/17) = 8470588 also looks valid
9 * 16/18 = 8M ( this is useful for P1 highest burst speeds )
For Baud 2M thru 7.5M formula is 120M/N for N = 16..60
Below 2M, they seem to use a table of common baud, mostly 6M/N
At 9Mbd sustained average DUPLEX data flow (no HW handshake needed ) is 4.457*2/9 = 99.044% ie a 500k file sends/echoes in ~600ms
>
I was doing round-trip communications with a P2 dedicated cog receiving traffic. The P2 wasn't keeping up at faster speeds (dropping chars). Go figure! If you find insight as to why please let me know! ;-). I was satisfied with the 600+ kBaud so I stopped investigating but from what you are seeing there might be headroom on the P2 that I missed. Hmmm... Oh and yes, cable length, probably shielding too, were issues that I saw as well.