interesting Serial problem

synapse

All,
I have got my serial connections all working I can take data from one prop to another. So here is were this gets fun. I can have up to 15 serial connections on one propeller. I am thinking about using several of the 4 serial connection object found on OBEX. Now for the problem really this propeller is more like a communications switch of sorts. Each data packet has a header that tells FROM, TO, TYPE and LENGTH much like Ethernet does. I have two possible scenarios that I am considering one is to act more like a hub than a switch taking every byte received from any of the 15 serial connections and retransmitting them to all of the other serial connections. This scenario seems a little excessive. Since in my header of each packet of data contains the address it needs to go to. I think in the long run it will both overload the chip doing this and overrun it's buffers real fast. however going with scenario 2 making it act like a switch and read each header of 7 bytes and rebroadcasting to the correct requires taking the time to read each packet form each of the ports also seems like it would slow it down too much and cause the same problem. Ideally it might be faster to use PASM taking each byte and just memory copying to each output. Each of the serial connections is to another Propeller or Micro controller. At this point all Propellers,

However I don't know where this project will lead me down the road. Most micro controllers will most likely just ignore incoming packets because there sole job will be to constantly stream new data out from there connected sensor or sensors. However other devices will likely be looking for specific data targeted to them. and will need to react very quickly to the packets they are looking for. so hub or broadcast seems like the wrong option for this.

I guess my question is based on this information what would be a better scenario or if you had this issue to solve how would you go about it. unless there is a better chip or design that could handle this better. I am open to suggestions however my costs per chip and size need to remain around the same as the prop in the QFN package.


I am open to all ideas!!!!

MagIO2

I'd do some changes to the driver. Usually a driver only knows one read buffer and one write buffer in this case of course two per serial interface. If you change that in a way that the buffers can be changed on the fly could be a good solution for your problem.
You'd then have one or more COGs which manage those buffers.

How it works:
All serial interfaces (only the readers at the beginning) are attached to a buffer. When the buffer is filled the "manager" will be acknowledged. The manager assigns a free buffer to the reader, so it can immediately read the next "message". Then the manager can have a look at the address and assign that filled buffer to the according serial interface as tx-buffer. If its content has been send, the manager can use the buffer again for a reader.

synapse

I like that that seems clean and would require very little code change.

Mike G

Maybe if you explain what you're doing. I don't see why you would want so many serial connections. A multidrop bus might do the trick?

synapse

Mike G wrote: »

Maybe if you explain what you're doing. I don't see why you would want so many serial connections. A multidrop bus might do the trick?

What is a multidrop bus?

The reason I have so many serial connections is I am building an expandable system and serial is very easy to implement on a prop with any 2 pins.

Mike Green

If you try this, remember that you have at least 4 cogs, all sharing the same pool of buffers. You'll need to use the LOCKxxx instructions to guarantee that the queue pointers belong to the cog using them at the time. Once a buffer 'belongs' to a serial channel, you won't need to lock it again until it's returned to the pool since only that channel (and its cog) will access it.

Dave Hein

The 4 cogs can use different buffers, so there no need for a lock as long as only one cog accesses all 16 pairs of buffers.

Edit: Mike, I was confused by your response. It looks like you were responding to MagIO2's suggestions about switching buffers. Yes, that would definately require locks.

MagIO2

Why would you need locks? The "manager" assignes one or two buffers to one serial port (one buffer for RX and maybe one buffer for TX if there is something to send to this serial interface). So, only the COG that's responsible for this serial interface will access it. When it's done with reading or writing it will acknowlede the manager. If it's done with sending the buffer is put back in the pool of free buffers. If it's done with reading, the manager will take care to assign it to the right serial port for sending. The buffer assignment of course also includes the pointers. So it's always clear who is accessing which buffer.

The approach here was to receive the full message and then distribute it. Of course you could also start sending when receiver is still receiving. But there you have no problem as well, as the receiver only changes the end of message pointer and the sender only changes the "to be send" pointer.

Again ... the idea is to have 32 buffers, as in worst case everybody wants to send something at the same time. At the beginning you'd only attach one buffer to each RX. If something has been received (there is a message length, so the receiving COG knows when transfere is complete), the receiving COG set's a flag for the manager. The manager picks the next unused buffer and attaches it to the RX of that serial interface. Then the manager checks the address and attaches this filled read-buffer to the TX of the serial interface that's been addressed. The COG responsible for that transfer starts sending. When it's done it returns the buffer back to the manager.

Depending on how busy your serial interfaces are, you might need one or two or more managers. Each one would then be responsible for a subset of buffers and serial interfaces.

Oh ... the manager could even attach one stream to several receivers. It's only a matter of programming ;o)