P2 Multi-port Serial and Smart Pins
Hi All,
I am currently designing a PCB using the P2 processor. I have used the P1 for a previous project which has worked very well, but I have not used the P2 before.
I would like to use smart pins for several serial ports (RS232, 9600 or 19200 or a few other slow rates only).
The serial Devices can run in 2 different modes, the first is asynchronous and the second polled and I need to support either.
Asynchronous mode is easy to handle, I could possibly just use the "Multiple Serial Port (8 UART – 16 Tx/Rx) Object" for the comms as it looks ideal.
The Polled mode requires the devices to receive a specific byte and the devices I will respond with their sensor reading.
To Enable Polled mode, I was originally thinking of using a circuit to break the normal TX paths and switch all the TX lines to a common TX output to simultaneously send the "TRIGGER" byte to each attached serial device. That way, a single poll byte can trigger each device to simultaneously send the sensor data.
Something like this (only Tx path shown here, P2 ports on Left):-
While I am sure the above would work OK, I have been reading up on Smart Pins (and getting rather confused by it all) I was wondering if it is possible to simultaneously send the same byte to each attached serial device from within the P2 smart pins, eliminating the need to the external switching?
I saw some videos on YouTube that seemed to show Smart pins being used to send the same data to a range of pins and the CRO traces showed synchronous outputs. I think that was using SPI but my question is, is that possible with a serial byte?
Any assistance would be greatly appreciated, I think perhaps this MAY be posible but I can't quite work it out so far. Thanks all.
Comments
It could be done, using the
ADDPINS
feature, but there is a notable caveat on doing it this way: All TX pins on the Prop2 are then required to be unbroken consecutive output pin numbers. eg: P0-P15.However, why not just send the same command to all driver ports at the software level. Surely the polling doesn't need to be exactly on the same clock edge?
Hi Thanks for the hints.
I will look into the ADDPINS feature, this is really new for me, thanks also for the tip on the consecutive pin numbers, I would normally use TX/Rx as a pair.
I am not sure if the ADDPINS and the 8 port RS232 driver can even be made to work together.
Ideally the sensors would all be triggered simultaneously as the sensors will be looking for variations under the ground, if there is, say a pipe at a certain location, the results should show a straight line across the channels, variations in timing might make the results more wobbly. Admittedly RS232 wouldn't be the best way of triggering, a pulse would be better but that is how these devices operate so I am stuck with it.
You could be right though, in that at these slow baud rates the slight differences in timing might not really be that significant, I need to try both to tell.
Couldn't you just stick a diode from the "poll" pin to each "port" pin?
Edit: Ah, would require a bit more than that.
I never considered using the smartpins other than the current use for the multiport serial driver. I think you may find it difficult to use the ADDPINS in this driver.
I have been thinking about the above.
When I wanted to operate in POLLED MODE, could I restart the "multiport serial driver" and just specify the RX pins in that driver (like you can with the P1 code for the "Quad serial driver" in the OBEX) and use the ADDPINS with a separate driver just for TX pins?
The TX could even be Bit-banged for the poll byte, provided I can send the POLL byte to all the TX pins at a fixed interval.
Sounds feasible to me but then I haven't tried it yet
So the polled mode will only be occasionally switched in? What else will the devices do when not polled?
What driver are you currently looking at, btw?
Sorry Evan, I didn't see this reply till now.
Yes Polled Mode will be an one of the 2 operating modes, in the other mode, the sensors operate independently with their own timebase, sending data at there own rate, unrelated to any other sensor.
The "multiport serial driver" as detailed here:- https://parallax.com/multiple-serial-port-16-object/ and seems ideal for this job. @Cluso99 (Ray Rodrick) from one of the comments up above and @JonnyMac (Jon McPhalen) have their names on it, so thanks guys!
It states "any baud". Surely there are limits 🤔
That'll be meaning each channel is independent of the others. Not that there's no limit to the min/max baud.
PS: From memory, max rx baud, using smartpins, gets patchy once it is faster than sysclock/5.
PPS: And min tx/rx baud, using smartpins, is sysclock/65535. 9600 baud is safe, but if ever wanting say 1200 baud then that would limit sysclock down to around 78 MHz.
@evanh
Many thanks and apologies for not being informed but in a nutshell, we can have multiple UARTS running at high baud rates, on a single cog?
I have only just started working on serial coms between the P2 and RPi Pico and am totally geeked with it but I need a Pico on one port and a string of Picos on another port (RS422/485 FD)
This is even better if can be handled with a single cog
Craig
I haven't really looked at the sources. It wasn't very large at first glance. That's a good sign.
Reality is the smartpins only have a one-word hardware buffer. This notably limits throughput ... and handling many port in a round robin will be slower again.
PS: I've just done an all-nighter. Can't concentrate any more. Off to bed.
A man after my own heart. I currently have a sleeping bag in the factory; on a mission and I can get along with cat-naps
Craig
@Mickster
I wrote an assembly 'serial router' which manages 6x bidirectional async serial ports and takes the data coming from one port and output it up to selected 5x OUT ports, all at a speed of 460800baud.
It is 'spaghetti code' so I do not feel comfortable to share it and it is missing many parts since the PIN config and memory buffer allocation, for example, are done in TAQOZ, but for me it is working.
My Smartserial is rock-solid and I have spare cogs so I think I'll stick with this for now