SX is only receving, not sending any serial data.

william chan

Dear Mr. Bean,

My SX is only receving, not sending any serial data.
The SX actually syncs with the startBit and from there tries to sample in the middle of the rest of the bits.
This is common in all SX UART codes.

I am not surprised that you are having problems with 9600 baud at 4Mhz.
My tests show that even with 2400 baud, I have to get lucky to get it working with any PC, even after fine tuning the middle bit position.

So I decided to play it safe and go with 1200 baud.
From our experience, the closest selected freq, in worst case would be around 3.92 Mhz to 4.08 Mhz. ( as seen in the SXKey freq dialog )
That is only 2% tolerance. So for 8 bits, 8 x 2% = 16%
But 3 / 16 interrupts per sample = 18.7%. So it should not run by more than 3 interrupt times per byte, which is beautiful.
B'cos it has to be out be more than 7 interrupt times to be out by half a bit, which will then definitely fail.
So at 1200bps it should have no problem at all.

That is why I am very certain that the IDE usually did not select the closest freq, b'cos at times when it did, the SX just continues
to communicate well day after day.

I am sure my problem is nothing to do with using header bytes,
bcos the single header byte itself couldn't be received correctly all the time once the freq is out.

You seem to be an expert with the SX. Are you the designer of StampII SX?
Please ask Peter to hurry.

Post Edited By Moderator (Joshua Donelson (Parallax)) : 10/23/2009 4:19:02 AM GMT

KenM

William,

What clock source are you using withe the SX, internal or external?

allanlane5

From his earlier post, William is using Internal clock at 4 Mhz.

William, are you using any interrupts? At 50 MHz the 'Virtual Peripherals' run really fast. At 4 Mhz the interrupt service time may be throwing off your SERIN sample time.

And I believe the SX/B SERIN command is NOT interrupt driven -- I believe it is coded with an in-line delay loop. If you are coding your own interrupt driven serial uart (which is what it sounds like), you certainly can't complain that Parallax has broken anything.

William, I don't mean to be difficult, but you don't seem to be drawing a distinction between what you WANT the SX to do, and what the SX is actually doing.

Thus you say "My SX is Recieve Only".· Does that mean you are using the SX just to recieve?· Or that you WANT the SX to recieve and transmit, and it is not transmitting?

The internal oscillator of the SX is NOT set at the factory -- it is intended that the programming device figure out what the "IRCTRIM" bits are supposed to be to get the += 8% accuracy.· When you specify IRC_CAL IRC_4MHZ, then the SX-Key goes through a calibration procedure to set the IRCTRIM bits for 4 Mhz.

"Normal" external oscillator programs typically say "IRC_CAL IRC_SLOW" to set the IRCTRIM bits to their lowest value, since the internal oscillator is not being used, and the time-consuming calibration procedure is not needed.

Hope this helps.

P.S. and I see now you are NOT using SX/B, you are programming only in assembly, and you ARE using interrupts to recieve data.· Do you still want to send data?



Post Edited (allanlane5) : 4/1/2005 4:26:48 PM GMT

william chan

Dear Allan,

Thank you for your time.

Yes, I use only Assembly codes, my SX only needs to receive data and I am using Internal OSC, trying to trim to 4Mhz.
I use interrupts to receive b'cos that is most accurate and it will not get interrupted while receiving.

I understand and know all the trimming process that you are trying to tell me.
My only complain is that in WinXP, the closest frequency is not selected by the SXKey IDE most of the time. Thats all.

Thanks.

allanlane5

It IS possible to set the IRCTRIM bits by assigning directly to a configuration fuse register -- but this is not recommended. I think I finally understand that your problem is that apparently the IDE and SX-Key are not setting the IRCTRIM bits properly under WinXP. They should, of course, when using the IRC_CAL IRC_4MHZ -- but in your experience apparently they are not.

Is there some other way -- like a counter, or toggling a bit -- that you can try to verify the calibration is really off? Throwing interrupt driven bit-banged RS-232 in there really increases the complexity and number of things that could be wrong, and makes troubleshooting very difficult.

william chan

Dear Allan,

Your suggestion is a very good idea.
I will try to measure the interrupt time by pin toggling using the Parallax scope later today.
I hope to post results later.

pjv

Whats all this whining about uncertainty of the precise frequency of the internal 4MHz oscillator??

Unless I'm missing something.........I believe you are tackling the problem from the wrong direction.

Instead of placing all your concern over the accuracy and stability of the oscillator, why not make the receiving software UART adaptive to the bit time it is actually receiving? Surely this is not too tough to figure out. With a 4MHz clock, at 1200 bits per second there are a whopping 3333 instructions per bit, and at 2400 there are 1666. Even at 9600 bps there are 416 instructions per bit, still plenty to make a bit rate adaptive UART, unless the micro is maxed out doing other things.

At 1200 baud ??????..... Really guys; put on your thinkin' hats and figure it out...., it's not that tough!!! Every level transition is an opportunity to adjust the timing for the next data sample and next edge detection.

Peter (pjv)

Bean

Peter,
That is exactly what I meant in the other post when I said.

"
If you are receiving data, you could possibly sync to the incoming pulses (maybe that's what your already doing). I would think that would require some kind of special prefix be sent that had a known pattern of highs and lows, so you know how many interrupt times each bit is taking. At 8% error you will be off by half a bit-time after receiving 6 bits. 6x.08=.48
"

Only I assumed the data HAD to be received in an interrupt routine.
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video Display Module" Available Now.

www.sxvm.com

"A problem well defined, is a problem·half solved."
·

allanlane5

In theory, you must be able to recieve a 'null' byte -- all zeros. Thus you get a start-bit, 8 bit-times of zero, and a stop bit. To what are you going to resync?

I assume you mean you can synchronize to the start bit, which is a typical technique. And it should work, too, unless your 4 Mhz clock is off by more than 10%. In which case your mid-bit region drifts and drifts until you sample one bit twice.

That's what William is suspecting -- that the 4 Mhz config bit settings are being mis-set, so that he hardly ever gets a 4 Mhz clock +- 8% -- he gets some other odd-ball frequency +- 8%.

Personally, I don't think it's likely that the SX-Key is mis-setting the clock. It's more likely he has a problem with his interrupt-driven serial recieve routine. But either could be the case, so we fault-isolate until we find out what it is.

Bean

You actually measure how many clocks the start bit lasts. Then you can time the reset from that.
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video Display Module" Available Now.

www.sxvm.com

"A problem well defined, is a problem·half solved."
·

pjv

Hi Allan;

I hear what you are saying, but I think one can focus on an appropriate software solution rather than blaming an unpredictable oscillator; the device is what it is, so get inventive, and deal with it !

It is reasonable to expect that after booting, at least some data other than nulls will be received; otherwise what was the point of receiving data at all.

Therefore, sometime after booting, which we will assume to be at a time random to the serial data appearing, samples will be taken at some default initial interval, and an edge will be detected; presumably (but not neccessarily) the leading edge of a start bit. If one then calculates the time for the bit0 data sample to be taken approximately halfway into the bit, AND also estimates when the transition to bit1 MIGHT occur, and takes several samples prior to and subsequent to that possible event, so as to catch that edge should it occur. IF, and ONLY IF an edge was present during those edge samples, then one can use the timing of that edge to adjust the overall sample clock for the next bit, as well as the following edge detection samples. One repeats this process for every bit, and adjusts the sample clock interval accordingly.

The implication here is that immediately after booting the oscillator may be far from the ideal frequency, and IF the first characters received are nulls, then adjustment could be prone to error. If at any subsequent time more reasonable characters are received, that is, with transitions near the middle or the beginning of the stream, then the adjustment would become corrected, and all subsequent characters, nulls or otherwise, would be received correctly.

This procedure also permits the receiving UART to "track" the incoming data, should the sending oscillator drift over time. And, naturally also if its own internal 4MHz ages or changes with voltage or temperature. A further bonus is that a transmitting UART's bit rate could also be based on timing derived from such a "tracking" clock.

All this takes only a little ingenuity; an SX, even at only 4 MHz, has plenty of horsepower to execute the programmer's innovative thinking;
A clock tracking data receiver project at 10 Megabits per second using a 50 MHz SX comes to mind.......

Have fun with this one.....it's very do-able

Peter (pjv)

pjv

Hi Bean;

What Allan is driving at is that you don't know how long the "start" of the stream is until some other edge is detected; possibly as late as the beginning edge of the stop bit. With a "way-off" oscillator this would cause unpredictable sampling. My suggestion is to adjust anytime (in fact every time) edges are detected, regardless if there be one or more bits between the edges. At some point durations of single bits will be detected, and these will form the basis of all further clocking.

Cheers,

Peter

william chan

Hi all,

I now have proof that the SXKey selects the wrong freq after calibrating for 4Mhz.
Please see the attachment image. It selects 3.99 Mhz when it should have selected the 4.00 Mhz freq.

Another interesting thing I have found is,
setting IRC_CAL to IRC_SLOW can strangely make the oscillation go faster than either IRC_4MHZ or IRC_FAST
This has been tested on 3 separate SX Chips using the Parallax USB Scope reading a toggling pin on every interrupt.
This proves once and for all that the SXKey selects the wrong freq to program into the SX Chip.

Using the scope, I was able to adjust the interrupt time as close as possible to 52.25us by changing the Cycles per Interrupt value.
After doing this, the serial receive from PC's work well at 4800 baud !
Some chips even work at 9600 !

On the subject of freq tolerances, some chips gave at interrupt time of 60us. ( with IRC_CAL set to IRC_4MHZ on WinXP)
That calculates to 60 - 52.25 = 7.7us difference, which is out by 14.8% which is too large.
That is why the communications was not working, even at 600 baud.
I believe the large tolerance seen is still due to the wrong calibrated freq being selected.

The idea of self adjusting SX is interesting and radical, but I may need to press a button to inform the SX of "Calibration Time"

PJMonty

William,

While it may look like "proof" that the wrong calibration value is being programmed, it's not. You had asked earlier (in the original thread about this) what order the programming is done. Well, I finally had time to go into the code tonight and double check. It's goes like this:

1 - Perform calibration
2 - Erase chip
3 - Program fuse settings (which contains the calibration value)
4 - Program code space
5 - If calibration performed, show the user what got programmed (the dialog)

As you can see, the very first thing that gets programmed in is the calibration setting. In addition, before you get concerned about the strange order of the calibration results on the dialog, you should understand that the calibration tests are performed out of order rather than sequentially. Chip Gracey (who wrote the original code) did this to optimize the time it takes to perform the calibration, but it has the side effect of creating a funny looking dialog.

As for it choosing 3.99 versus 4.00, you are simply seeing the results of some float to string conversion issues. After the SXKey perfroms the eight calibration tests, it steps through the results of each one and calculates which one has the smallest error. In other words, which one will put it closest to 4 MHz. Now, when it displays the results, it truncates the answer into a whole number followed by only two significant digits.

In your case, even though the answer (when truncated to only two digits) was 3.99, the fact is that when carried out to all the actual significant digits, that calibration setting was a smaller value than the 4.00 setting. Notice also that there are two 3.99 settings and two 4.00 settings. This is not because the the SXKey screwed things up, but rather because the actual values, when going past the first two decimal places, probably looked something like this:

3.9990 (displayed as 3.99)
3.9997 (displayed as 3.99)
4.0047 (displayed as 4.00)
4.0048 (displayed as 4.00)

Do you see how those values, when truncated (and not rounded) down to only two decimal places would give the wrong impression about what was programmed in? Also, can you see how something that displays as 3.99 could actually be closer than something that displays as 4.00? Bear in mind that the dialog that comes up is really just a visual confirmation that the calibration took place.

Finally, let's just pretend that the SXKey actually did put in 3.99 instead of 4.00. Well, since that represents an error of basically 1%, it's not going to be the thing that causes your code to fail.

With regards to your experiment that shows the slow calibration being faster than the fast setting, this turns out to be true. Due to a minor coding error that goes back to at least version 1.33 (before I got involved), the values for fastest and slowest got transposed. However, this is a non-issue since they are intended merely to hardcode either the first or last of the eight possible calibration settings, and have never been able to provide any actual known speed. The key advantage to using them is that you don't have to go through the calibration step each time you program if you choose one of these. I'm not sure why both are provided when either one would have sufficed.

Now, I'm going to get back to working on the software so it can get released sooner rather than later.

Thanks, PeterM