Serial help with SX

Omnitest

Hi,

I'm very new to the SX and do very little programming. I need a little help with a simple task. I am attempting to use an SX28 to read in a serial string, add a small string to it, and then send it back out. I have been attempting to use the myriad of examples as well as writing a simple SX/B routine and have run into some problems. The problem I am having is that all of the methods I have used read a byte at a time and I would like to read in a whole string before acting upon it and sending it back out.

I have managed to write a simple repeater, but it does it one byte at a time. The inbound string is a fixed length, so if there is a way to receive a fixed number of bytes, store them temprorarily, and then pass them on as a string, that would work. Obviously, I am not a programmer, but I was hoping there would be a simple routine that even I could understand and implement. I know that this is very basic, but I am more of a hardware guy. If there are consulting programmers that could hack this out for me, I would be willing to pay for my lack of talent.

Any points to the right direction would be greatly appreciated.

Thanks,

Troy Ingram
Omni Test Services

Bean

What length is the incoming string ?
If it's less than 16 characters then you can store it in an array.
Post your SX/B single character repeater and I'll help you modifiy it.
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"

www.sxvm.com
·

Robert Schwartz

There is no SX/B command to recieve more than one byte of data at a time(one character in ASCII). You could probably write one in assembly, but it would be pretty hard (I'd imagine). You will have to send and recieve each individual character and sotre them in different byte variable. You can place them in an arry to place them all together. Adding three characters would just be adding 3 more bytes to the array. However, the maximum size for an array is 16 bytes, so 16 characters. You could make two arrays (or more), like word1, word2, etc... to hold more data... You also can't have a "string" really, only byte arrays. This means that you can't pass a string, merely the first character, then the second character and so on.

Omnitest

Bean,

I have attached my (very elementary) code.· It is about as basic as you can get using the SX/B template.· This is just a beginning for me as I was exploring what happens a byte at a time.· I am sure that there are some pretty standard routines for turning bytes into strings, but I am not there yet.

The string is much larger than 16 bytes.· I have pasted a sample below.· The string is coming from a GPS modul and is already TTL level.· I am sending it to a radio module that also is TTL, so I do not have to invert the signal or convert it to RS232.· This is where I get into trouble with the assembly examples.· They invert and I do not need to.

I do not want to waste a great deal of your time, but if there are simple answers here I would appreciate any help you can give.

Serial string - 20:29:04·$PUBX,00,202904.25,3413.220949,N,11822.805406,W,230.535,G3,2.3,2.2,0.009,18.41,-0.010,,1.13,1.45,0.81,7,0,0*69

Thank you for your time,

Troy Ingram

Omni Test Services

Omnitest

Thanks Robert,

I was begining to get that impression. I will start working it out with multiple arrays to see if I can make that work. I know I can do all of this with a stamp, but I'm going for surface mount in my project...

I am also planning on expanding this to write into serial flash with SPI, so I am thinking that the SX is a good conduit for that.

Thanks for your input,

Omnitest

Robert Schwartz

You could input the string byte by byte, saving each byte to an external EEPROM, then concatenate the ending, and read/send the string back through the SX. This would only require one byte to be used up on your SX. That or you will need a whole lot of byte arrays.

Beau Schwabe

Depending on the baud speed, writing to EEPROM might be to slow.....but a 1-bit serial FIFO might work to buffer the incoming serial data
and "play back" the data at a specific interval for processing.

focus.ti.com/lit/ds/symlink/sn74act2229.pdf

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

---

Beau Schwabe - Mask Designer III

National Semiconductor Corporation
(Communication Interface Division)
500 Pinnacle Court, Suite 525
Mail Stop GA1
Norcross,GA 30071

---

Robert Schwartz

Didn't think about that Beau, your probably right about the EEPROM. Also, although t would be overkill,a SX18 would also be able to do the job of relaying signals back and forth from the GPS unit and the main SX. It would recieve the data, store it all and add the extra string(as long as it was 17 or fewer bits), send it to the main SX for processing, and then send out whatever string you would need.

Bean

What is it you need as an output ?
More details please.

You mentioned appending some data to the string. If that's all you need then you don't need to store the whole string.
Just read and send characters until no more come in (timeout) then transmit the appended characters.
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"

www.sxvm.com
·

SteveW

Would it be possible to cheat slightly, and rather than storing and retransmitting the string, simply pass it through, while looking for the end, and then send your bytes out? That would get you out of having to store the data...

Steve

SteveW

Darn -beaten by 2 minutes. Happy 1000th post, though [noparse]:)[/noparse]

Steve

Omnitest

Bean / Steve,

I think you guys have hit upon what sould have been staring me in the face all along. I was concentrating on getting the whole string into memory before passing it along. I will attempt to look for a specific character that is always present at the begining and the end. I can pass eveything between through and append my data string to it. That seems too simple, so I will try it and let you kow how it works out.

Bean, let me say that I am honored to have been part of your 1000th post.

Troy

Bean

Holy cow,
I didn't even realize I was that close to a that landmark. I really can't believe I post 1000 times.
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"

www.sxvm.com
·

Omnitest

Here's the feedback I promised....
With a routine to simply read and pass each byte along, the SX seems to be too slow to keep up with the data stream. It passes through only bits of the entire stream. I am running it at 50MHz and have tried different baud rates. It may be an artifact of inefficient programming, but I am looking at doing this a different route now.

Thank you all for your help.

pjv

Hello Troy;

I think you are abandoning this too quickly. I can say for sure that a 50 MHz SX programmed in assembler can EASILY handle what you need done, that is to pass-thru an incoming bit stream, watch for a specific character(s), and then append some more characters.

All provided that the baud rate be not too high, say less than 1 megabit per second.

What is your incoming data rate?

Peter (pjv)

Omnitest

I did not mean to imply that I am giving up. I just need to study it a bit and try a different method. I am running at 9600 baud. I can not go slower with the GPS/Radio combination that I currently have.

What I intend to do is study the assembly examples more and figure out how not to invert the signal. All of the examples I have invert and this will not work for me. I am short on experience with assembly programming, so I am using the examples to teach myself.

Thanks for your input.

Bean

What the problem is, is that you are probably doing something like:

SERIN blab,blab,blab
SEROUT blab,blab,blab

You cannot do that, because while the SX is busy sending a character is cannot receive newly arriving characters.
You need to just allow the characters to "flow through" on the SAME pin while monitoring the characters. When you receive the last one, then disconnect (or override) the sender and send your own characters on that pin.

If you actual want or need to receive characters on one pin and send them on a different pin, you will need to do the send and receive with an interrupt routine.
If you post your code so far, I will be happy to show you how to write the interrupt routine in SX/B.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"

www.sxvm.com
·

pjv

Hello Troy;

If your examples are programmed in something different than assembly, I can understand your problem. Eventhen is should be quite possible to invert the polarity of the data, but perhaps not for a novice programmer. Most of my work is in assembler, and the inversion is one instruction; trivial.

If you need help, I can help write this code for you. At 9600 baud, it would be a breeze for the SX in assembler.

Cheers,

Peter (pjv)

PJMonty

Troy,

As others have mentioned, the SX is basically bored out of its little CPU skull when being asked to handle data at a mere 9600 baud. With the SX running at 50 MHz, the instruction time is .00000002 seconds. At 9600 baud, a single character is .000104166 seconds. Divide the two (.000104166 seconds per character / .00000002 seconds per SX instruction) and you get 5208. That means that you have up to 5208 instructions that can be run to handle the processing of each character. That's a ton of instructions.

I think you just have some errors in your program that are preventing you from getting the right results. Don't give up on the SX or on the approach of passing along a stream of characters and modifying them on the fly. It'll work as long as you take the time to get it right.

Thanks, PeterM

Omnitest

Using the suggestion from Bean, I think that I have managed some success.· Knowing that the data string has a line feed and return at the end, I read in the string one byte at a time and look for a character 13.· After a short pause, I send my extra characters out the same pin and the go back to reading.· All the while, the data string continues to go out the radio on the same pin without any intervention from the SX.


I have attached the SX/B file here in case anyone wants to critique it and offer any suggestions to clean it up some.

After I got it working, I backed the clock speed all the way down to 4MHz and it still works fine.· Interestingly, it does not work properly with the internal 4MHz oscillator.· I have to use the external clock in the SX-Key to make 4MHz work.· I have left the code for the internal clock in the listing (commented out) in case anyone has a suggesttion.

It is obvious to me that I need to learn a bit about using interrupts to make this type of task a little cleaner.

Thanks to everyone for your help.· I intend to expand this project in the future to add some analog inputs.

Bean

Alright, I'm glad to hear you got it working !
The internal 4MHz is NOT accurate enough for serial communications. I think it's only +/- 8%.
Use a 4MHz resonator and you'll be fine.

Just a couple comments on the code:

You are overstepping the bounds of your X() array. BYTE(6) means the array has elements from 0 to 5. X(6) is really in "nowhere land". Since you don't have any other arrays defined it works okay.

The easy way to get values into the array is with PUT. PUT X(0),"123456"

Other than that it looks great. Congratulation...

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"

www.sxvm.com


Post Edited (Bean) : 3/18/2005 12:13:22 PM GMT

Omnitest

Thanks Bean,

I was looking for an easier way to populate the array. This is obviously the value for my added string. It is really a serial number and will be changed for each unit so I was looking for a way to make it easily changeable. I can use an array up to 16 elemets, right? So that would be x(15) representing elements 0 to 15....

I will be adding an external 4MHz resonator. I want to keep the current draw as low as possible. If I add more processes later and need more speed, I can change the resonator without modifying the board layout.

Thanks for all your help.

Troy

pjv

To PJ Monty;

I believe you are out by a factor of 10 in your calculations; it seemed a little low to me.

At 50 MHz, the SX delivers 50,000 instructions per milli Second, not 5,000.

I see the error crept in due to too many zeros in the 9600 baud CHARACTER time figure which should be 0.000104 seconds per BIT, so 52,080 instructions per 10 bit character.

Peter (pjv)

PJMonty

Peter (PJV)

Duh! Even after reading your post and doing the math over and over, I kept glossing over the bit versus character issue. You're absolutely correct. I was calculating the number of instructions per bit rather than byte. As you say, at ten bits per byte it's 52,083 instructions per character. Frankly my original number seemed a bit low to me, but I since the math "checked out", I assumed it was just a wrong gut feeling on my behalf. I appreciate the heads up.

Thanks, PeterM