Com ST7-PC

[philippe_cardi]

Posted on February 08, 2006 at 05:02

Com ST7-PC

[pete3]

Posted on January 31, 2006 at 10:21

Orlando,

You mention further up that you are using 9600 baud but your code comment indicates 4800. I would check your oscillator and work out the frequency you are communicating at.

[philippe_cardi]

Posted on January 31, 2006 at 16:37

Hello,

1) I tried all the baud rate of the computer, and I never had good results. 2) I made a graphic interface in java which I tested using 2 computers, and it worked well, so I do not think that this is the source of my problem. This is why I think that the problems are due to the MAX232 or the programmation of the ST7. 3) I changed into input floating ports as Luter said but it didn't work either. This is why I'm asking you what MAX232 you are using and if my code is correct. The really weird thing is that you all seem to say that it's easy to do this, but I can't manage to make it work, so I'm really lost... Thank you all. Orlando

[pete3]

Posted on February 01, 2006 at 04:44

Do you have access to an oscilloscope? Try sending a single byte to and from your PC and check the bit times and message contents. I found the prescalars on the ST7 somewhat confusing and resorted to using a custom one which I checked on a scope.

[philippe_cardi]

Posted on February 01, 2006 at 07:14

Hello,

peterwrigley, could you tell me how you configured your computer and your ST7? Did you use a graphic interface or the hyperterminal? If you used the hyperterminal, could you tell me how to use it? Thanks Orlando

[pete3]

Posted on February 01, 2006 at 08:06

Here we have a few licenses for H.A.C.K. Consulting (great name) Serial Device Tester which allows you to set the options through a graphical environment.

http://www.hackconsulting.com/SDTestInfo.html

has an evaluation version. Go through the Comm Port > Settings menu. Much easier than messing around with HyperTerminal! On the ST7, you have to calculate your baud rate prescalar based on desired comm speed and oscillator frequency. For instance I use 38400bps on a 16MHz crystal. The micro takes 2 clock cycles per instruction and the UART has a built-in divide-by-16. I need a prescalar of 13 to achieve my target bitrate (((16M/2)/16)/13). First I used the extended register then realised there's a ''13'' option on the micro, which I now use. If you're not sure what you're set up for, load a value in and measure the pulse width on a ''0x55'' transmission value (01010101). This will give you the bit time. You can then alter your prescalar accordingly. I used asynchronous transmission as you don't have to connect all the RS232 lines. Don't use parity or more than one start bit at first, you can add that when you know the basics are right.

[philippe_cardi]

Posted on February 01, 2006 at 17:43

I'm going to try this software to see if I have the same results as the ones I have with my interface.

Do you know a software which allows me to receive the signals? Because the oscilloscope that I have is very omd... Another question : if I send 00001111 all the time am I supposed to have a periodic signal? Thank you Orlando

[pete3]

Posted on February 02, 2006 at 05:50

Orlando,

You will have a start bit before data transmission which will usually appear as a '1' in the bit stream. Unless you are using an intelligent RS232 chip (I'd be surprised if you are) this will appear in the TTL bitstream from the transceiver. That's why I recommended 0x55- even with a start bit you'll see a periodic waveform. With the start bit, the unencoded bit stream including start bit and one stop bit will appear as 1000011110 which is periodic. A parity bit will change that even more. The RS232 standard including pinouts and so on can be found at:

http://www.camiresearch.com/Data_Com_Basics/RS232_standard.html

You *might* be able to find drivers for your soundcard to make it operate as a low-frequency scope on the microphone input, but I would advise against it as quality is usually low. If your baud rate, parity etc. are set correctly, the program I recommended will display the incoming data. Otherwise the aliasing between the transmitting and receiving frequency will usually appear as a string of 0xff or similar (another reason to use a transmission sequence with no 'f' characters). I'd just try to get your scope working.

[sylv1laurent]

Posted on February 02, 2006 at 15:36

Hello,

if you want to do a periodic signal, write ''U'' ($55 hexa). This caracter is totaly periodic. bye

[philippe_cardi]

Posted on February 02, 2006 at 18:23

Hello everyone,

Thank you peterwrigley, I have been able to watch the signals on my old scope (very good idea the 0x55 ;) ). My graphic interface is working perfectly, but the ST7 is sending, for instance, 5600bds instead 38400bds. Is it because I'm not using a quartz? My clock is the standard one at 8MHz. If I need to use a quartz (I have some quartz at 8MHz) is there a specific way of programming? Thanks again Orlando

[pete3]

Posted on February 03, 2006 at 05:13

The problem is mostly likely due to a difference between the prescalar you require for the 38k4 bitrate you are looking for and the value which has been programmed. A quartz crystal will give you more accurate timing and I strongly recommend you use one. One chip we are considering using at work has an onboard RC oscillator with a 32kHz nominal frequency - but it's +/- 30%! Absolutely no use for anything other than a *very* rough 'go to sleep for a while' command.

Check through your calculations and make sure there isn't a mistake- writing a single bit wrong could cause the problem you are experiencing. Remember you have up to a 5% acceptable difference between desired frequency and a frequency the PC will accept (on newer PCs anyway). My set frequency is 38,461Hz but the PC still recognises it as a 38k4 connection. Read back through my previous post on this topic (posted 01-02-2006 at 12:36). Sorry, when I said your 0x0f qould be periodic I meant it would repeat as you send more and more data bytes to the target, not that it would be a periodic 0x0f but something different when you take into account start, stop and parity bits. Also check you do not have hardware watchdog activation on, or alternatively that you feed it regularly. If the watchdog activates partway through your communications the chip will reset and the rest of your data will be lost!