VP's, UARTs and I2C

Javalin

Hello Chaps,

Is it possible to make an SX chip run 3 uarts of different speeds, and an I2C slave all at the same time.· Purpose of this would be to "switch" several slow serial data connections (19k) into one (115k).· I2C would be used for setup/control of switching etc.

thanks,

James

pjv

Hi James;

Absolutely, at 50MHz with horsepower to spare.

Peter

Javalin

thanks!

Guenther Daubach

Hi James,

I did several SX applications with UARTS and I²C interfaces. For example my RS-232/I²C Adapter. Usually, I run the UARTs as Virtual Peripherals (VPs) inside the ISR because they require exact timing, where I run the I²C code in the main loop which normally has not much else to do, i.e. it cycles through the loop even faster than the ISR. When running an I²C master, timing is not critical at all because the master generates the SCL signal. When running an I²C slave, the code must be fast enough to detect start and stop conditions, and the transitions of the SCL signal. At 50 MHz clock rate, this is not a problem for data rates of up to 100 kBit/s but even higher rates can be handled with clever coding.

When combining several UART VPs, you need to find the common denominator for the different timings. The most critical is the one for 112.5 kBaud. As the lower baud rates can also be derived from the same ISR call period, it is doable.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

Günther

Javalin

Hi,

Thanks for the info. The SX would be a I2C slave and run 3 UARTS (full duplex). 2 Uarts would run at 115k, and 1 at 19.2.

Couple of extra questions:

1) Are there limits to the number of VP's on the SX?
2) Does SX/B use the serial VP's, or is it all bit banging
3) How difficult would you say this was to achieve, and can it be done with SX/B

Thanks!

james

pjv

Hi James;

I interpreted your earlier post to indicate 3 uarts at 19.2 Kbits/sec. Now it appears you want two UARTs at 115 Kbits/sec.

Now I'm not sure at what rate you wanted to run the I2C.

Things are definitely getting a little tighter, and perhaps a whole bunch.

I'm presuming the data may come at this SX steadily, and as the SX has very little buffer, it will need to get rid of data as quickly as it arrives.

Once you know for sure what the baud rates will be, a more certain assessment can be made.

Peter

Javalin

Hi Peter,

Sorry - yes that was not clear. The data flow will not be two much (ascii commands) except for a number of large (ish) transfers (binary). The I2C bus will not be hardly used, and could be ignored.

Does the SX have the same speed limits as the Javalin in writing to RAM. I am using a Javalin to do this at present, and am only able to achieve about 10k. For example - recieve on UART1 and transmitt it out on UART2?

Something like:

Wireless link <---- 115k ----> SX <

---

115k

---

> Camera
········································· |
········································· | 19.2k
········································· |
······································ Javalin

Thanks

james

pjv

Hi James;

I know nothing at all about Javalin, but I'm very comfortable with SX in assmbler.

What you now descibe is quite possible with an SX running at 50 Mhz. I understand from your desciption that largish bursts of 115 Kb/s data originate at one source, to be sent on to a destination at also 115 Kb/s. Not quite sure how the Javalin fits into the picture. I'm also assuming that each of the 115 Kb/s channels are probably half duplex? That is; one (re)transmits what the other receives?

At 115 Kb/s we have one bit per (roughly) 8.7 microseconds, and that is about 435 instructions. Assuming 3X oversampling on the receiver, that works out to 145 instructions available per bit of data.......plenty for a fairly concise "frillsfree" UART. So, now it depends on what else this baby needs to do, ie the Javalin port.

Please descibe the data flow a little better, or, if you can, how the application is intended to work.

Peter

Javalin

Hi Peter,

Thanks for the info - your interpretration is correct. The Javalin will also be connected to the SX via the 3rd serial port. It will ascii commands at 19.2k, also from the 1st 115k wireless port. In effect the SX is a Y join from a fast wireless to 2 equal or slower devices.

What I was trying to describe with the Javalin was the limitation (so I believe) of receiving and writing to memory buffer, then reading buffer and transmitting, seems to be about 10kbytes/sec.

James

kjennejohn

Hi there.
This sounds like the SX is a 'snooper' monitoring this data traffic so as to send it at a slower speed to the Javelin (which, if I remember correctly is a Parallax SX product that runs Java). If so, it need not transmit anything to and from the faster devices. It only needs to monitor the transmit from each device and send it at a slower pace to the Javelin. Yes? No? If yes, then the fast devices can talk straight to each other, and there is that much less for the SX to do. If no, if the SX has to make decisions on this traffic, it can still do so. If it has to determine if this traffic needs to be modified before passing it on, then things will get verrry busy. I have to wonder if a constant high speed stream like this can be successfully passed to and fro, monitored for key info, retransmitted to a slower device, and a large RAM buffer stuffed and retrieved on command.

Later!
kenjj
All my pencils *used* to have erasers!

Javalin

Hi Kenjj

Thanks for the info - I hadn't thought of that. Question, how do you deal with the transmitt and recieve lines being held high/low by the two 115k modules, which would surely create issues when trying to inject data into it?

James

kjennejohn

Let's cover a couple of your earlier questions first:

Couple of extra questions:

1) Are there limits to the number of VP's on the SX?
2) Does SX/B use the serial VP's, or is it all bit banging
3) How difficult would you say this was to achieve, and can it be done with SX/B

1. Probably, with limitations based on memory usage, interrupts, stack size, and processor speed. I read somewhere that there is a VP that emulates an octal USART- i.e., it handles eight serial ports.

2. SX/B is a limited BASIC that largely needs a thorough knowledge of assembler and page layout/usage to be used. It is, as Parallax says, an educational aid, not a real tool. For now, download the latest SX manual and start reading.
EVERYTHING with the SX is bitbanging. There are no builtin peripherals. Ubicom's claim is that the processor's instruction cycles are so short (20ns with the 50MHz clock) that the user can emulate most any circuit, including A/D converters, USARTs, D/A converters, and lots more. They have several VPs available for downloading.

3. Don't rightly know, I have little practical experience with SX. I do own a SX-Key, purchased 5 years ago. I haven't done much with it so far, but plan to train myself in embedded processors with self employment in mind. However, as I pointed out above, this can't be done solely in SX/B.

Back to the present question:
If these devices are using RS232, then levels are not a problem, IF USED PROPERLY. Sometimes extra lines are used between devices, and levels on these lines indicate if a device has data or is ready to recieve data. This is called 'hardware handshake'. This is not absolutely necessary, however.

Typically, the transmit lines sit at a known quiescent level (called a 'space', I believe) until a transfer is started. The level is changed for a known period (called the 'start bit') which signals the other device to get ready to recieve a byte. This is usually where interrupts are used to start a routine that handles this incoming data. However, once an interrupt starts, all interrupts are disabled until the end of this routine, which means traffic from another serial device gets ignored. At that end of the int routine, there is an interrupt enable command, then a·ret(w) command back·to the point the program jumped from. Since you say these are full duplex, handling two devices at once is impossible. (I THINK! Maybe someone can set me straight on this!) And, I don't know if the serial VPs will do full duplex, though I would think it possible. Anyone...?

If it has to catch data, buffer it, then transmit the buffer on to the other device, and ONLY take data from one device at a time, you're probably OK. This is typical for a Master/Slave configuration, where the Master starts a message cycle and then waits for the Slave's response. There is usually a wait time involved here. If the data takes too long passing both ways through the SX, the Master will time out and declare an error.
But, if the SX has to act as a transparent serial buffer between two devices, you're dead in the water I'd say.
Also, these data transfers can't be interrupted once started. If these transfers come close enough together, they could eat up all your processing time and leave you inadequate time to do other jobs.

There are too many variables present here for me to call it.
I wish you luck.

kenjj

pjv

Hi Again James;

I think Kenjj brings up valid points, and I agree with him on some of it.

In principle there is no specific limit on the number of VP's, other than the total amount of work to be done in the processor time and code/variable space to do it.

Regarding SX/B, this may be nearing the limit of the current SX/B offering, but with some clever approaches, and some assumptions of what needs to be done, as in half-duplex operation, the SX/B can handle it.

James, a much more detailed description of exactly what needs to be accomplished is required. As Kenjj said, what about the handshaking stuff etc. etc. etc.

For a "no-frills" application, this is quite simple for someone very fluent in SX assembler. For an "all-the-goodies" approach, it could be a lot of work.

Please spell out the detail.

Peter

Javalin

Hi Chaps,

Thanks a lot for your input, very useful.

I think looking at this I will go for the receieve and re-transmit in a Y join type senario.

Just waiting for pay day now!

James