Need a chip to modify a serial command. Where do I start?
programmergeek
Posts: 2
I have a project I want to do and I am not sure what hardware I need or what I need to get started. These chips might be overkill but if someone can provide some inpur that would be great.
I need to make a black box to modify a serial string. Iam looking at string of 4 digits and the baud rate is 9600.
that outputs will be the same askey II serial string but I need to prefixthat string with a letter to be able to tell where string is comingfrom.
Example:
Input askeyII = 1234 Output askey = A1234
Input = 2345 Output = A2345
I wrote Patallax looking at the Stamp2 Microcontroller Module and they seemed to think the propeller might be betterbecause of the speed was better. I know little about these but Ithink both are overkill, I need to make several of these little boxes.
Thanks ahead of time for your input.
I need to make a black box to modify a serial string. Iam looking at string of 4 digits and the baud rate is 9600.
that outputs will be the same askey II serial string but I need to prefixthat string with a letter to be able to tell where string is comingfrom.
Example:
Input askeyII = 1234 Output askey = A1234
Input = 2345 Output = A2345
I wrote Patallax looking at the Stamp2 Microcontroller Module and they seemed to think the propeller might be betterbecause of the speed was better. I know little about these but Ithink both are overkill, I need to make several of these little boxes.
Thanks ahead of time for your input.
Comments
How many serial lines does this "black box" connect with.
I do something similar in my lab. I have information coming from different equipment and a Prop reads all the data in and formats it nicely with a prefix.
This isn't very hard to do.
Is the serial connection RS-232?
Duane
This is the keypad
http://www.homeauto.com/products/consolestouchscreens/outdoorkeypad.asp
The keypad outputs an askey II string the trouble is we have no idea what keypad it comes from so I want to put a idenifer in frount of the string such as a letter. so I have a little black box behind each keypad.
Any help on what hardware to get that is the cheapest and the code would be a huge help This is my fors microcontroller.
Feel free to email me
jason@programmergeek.com
Sounds like the same thing. If
A Propeller would be a better choice than a Stamp because the Stamp can only do one thing at a time. If it's transmitting serial data, it can't receive serial data and will ignore any sent to it. The Propeller can receive and send at the same time and, if wanted, can modify the received data before handing it over to the transmitting cog.
It was unclear from the documentation (from the site you linked to) how the information is coming from the keypad.
It looks like there is a 12V line.
A brown wire which connects with a green wire, which connects to an "Armed" location on the back of a controller box.
I don't see information (other than baud) on what the two "serial" wires are.
They could be a TTL, RS-232, RS-485 or some other protocol.
Do you have a unit that you could test with an oscilloscope to see what the voltages are on the lines?
The type of signal will determine if you'll need additional chips to allow the keypad to communicate with the Propeller.
As far as hardware goes, I'd suggest a Propeller Proto Board. A QuickStart board is also an option.
If you need to add additional components to interface with the serial connections, you'd probably be better off with the Prop Proto Board.
Do you know if the keypads transmit some sort of terminating character? Many of my devices end a transmission with ASCII 10 and 13 (new line and carriage return). This will be important when it comes time to write the software.
The Prop can handle many serial connections at once. Especially limited to a 9600 baud. 24 incoming lines could be monitored with six cogs leaving two extra to for modifying data and sending data out on a different line (one cog would probably be enough for this).
How many of these keypads do you want to monitor?
Does the serial line coming out of the device need to match the protocol of the incoming data?
Duane
But a Prop will certainly do it also..plus you can get lots of help
here on the forum if you use a Prop.
You need to be able to see the serial data...a scope or analyzer
of some kind will help. You can do it without monitoring the data
but it's always easier to see the data stream.
The voltages of the signals are important and you may need to
convert them, there are cheap chips made just for that purpose.
MAXIM (the chip company not the magazine :-)
As I mentioned in a previous post, it would be good to know what kind of control characters the keypads output.
When I was testing software to combine serial lines in my lab, I had one Propeller board generating simulated output from the various instruments.
I would good to have list of possible data steams from the keypads.
For example here is the data I used.
DAT analyticalBalanceFakeOutput1 byte "+ 123.4567 g ", 13, 10, 0 analyticalBalanceFakeOutput2 byte "+ 10.0006 g ", 13, 10, 0 analyticalBalanceFakeOutput3 byte "+ 0.0000 g ", 13, 10, 0 largeBalanceFakeOutput1 byte "Total ", 10, 13,{ }"Net 0000.00 g", 10, 13,{ }"PCS 000000 ", 10, 13, 0 largeBalanceFakeOutput2 byte "Total ", 10, 13,{ }"Net 1234.55 g", 10, 13,{ }"PCS 000000 ", 10, 13, 0 largeBalanceFakeOutput3 byte "Total ", 10, 13,{ }"Net 0543.25 g", 10, 13,{ }"PCS 000000 ", 10, 13, 0 spectrometerFakeOutput0 byte "450NM 1999. A", 13, 10, 0 spectrometerFakeOutput1 byte "450NM .234 A", 13, 10, 0 spectrometerFakeOutput2 byte "450NM -.000 A", 13, 10, 0 spectrometerFakeOutput3 byte "450NM .000 A", 13, 10, 0 spectrometerFakeOutput4 byte "420NM 1.110 A", 13, 10, 0 spectrometerFakeOutput5 byte "450NM -00.4 T", 13, 10, 0 spectrometerFakeOutput6 byte "450NM 125.2 T", 13, 10, 0 spectrometerFakeOutput7 byte "450NM 00.0 T", 13, 10, 0 spectrometerFakeOutput8 byte "450NM 1999. C", 13, 10, 0 spectrometerFakeOutput9 byte "450NM 0.42 C", 13, 10, 0 spectrometerFakeOutputA byte "450NM 2.10 F", 13, 10, 0 barcodeFakeOutput1 byte "GB123", 13, 0 barcodeFakeOutput2 byte "C002", 13, 0 barcodeFakeOutput3 byte "V014", 13, 0Alternatively the program could ignore all control characters and just use the pound sign ("#") as an end of message marker. I believe from the link you provide the pound sign is to be pressed at the end of a code entry.
Do you want the retransmitted data to have any special headers or end character(s)?
@Other forum members, Jason has offered to pay me a consulting fee for my help. He has generously agreed to have the solution discussed on the forum in hopes it will help others with similar projects. This why answers are more detailed than normal.
Duane
I doubt I'll have internet access for the next few days.
I thought I'd share what I've come up with so far.
MergePad is a program that combines up to seven data streams into one. A letter is added to the beginning of each data set indicating which keypad it is from. The letters are A-G. If the program sends and error message or some other message that isn't from the keypads, it uses "?" as a prefix.
The program uses the same terminating character as the documentation "#".
I've also attached PadSimulator. A program to test the MergePad program.
I haven 't tested the program as thoroughly as I'd like to. I'll do some extra testing when I have some time.
Duane
Edit(3/11/15): Warning, the code attached is an old version. There are likely better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't code similar to what is attached here on my on GitHub, send me a message and I'll make and check for any improved versions of the code.
I've done some more testing. I think the MergePad program is working.
I added some tests to the PadSimulator program.
The first test just outputs simulated button presses on four lines, one line at a time.
Here's the Spin code.
Tbug(string(13, "Simple Test")) Tbug(string(13, "Four data sets from four pads.")) waitcnt(clkfreq * 1 + cnt) repeat outputIndex from 0 to 3 Tbug(string(13, "Output from pad")) TbugTx(prefixList[outputIndex]) Tbug(string(" = ")) localIndex := @padFakeOutput01 + (outputIndex * _KeyPressBufferSize) repeat TbugTx(byte[localIndex])' Send data to terminal window Tx(outputIndex, byte[localIndex]) ' Send data to black box while byte[localIndex++] <> _EndOfMessagePad '"#" waitcnt(clkfreq * 1 + cnt) Tbug(string(13, "End of ", 34, "Four data sets from four pads", 34, " Test.", 13))The statements
Tbug(string(13, "Output from pad")) TbugTx(prefixList[outputIndex])are used to identify which serial line the data is being transmitted on. This identifier is only sent to the terminal window for debugging. It is not included in the transmission.
The array "prefixList" is located in the DAT section.
prefixList byte "ABCDEFG", _BlackBoxMessagePrefixThe output to the terminal window from this section of code is:
Simple Test Four data sets from four pads. Output from padA = 1111# Output from padB = 2222# Output from padC = 3333# Output from padD = 4444# End of "Four data sets from four pads" Test.The output from the Propeller listening to all seven serial lines is:
A1111# B2222# C3333# D4444#I added a carriage return after the end of message character (#) to make it easier to view in the terminal window.
Here's the section of code in MergePad that outputs the data (and adds a carriage return).
PUB MonitorPads | localIndex, localSize, endRxFlag, localErrorFlag, localComIndex repeat repeat localComIndex from _PadA to _Output if rxFlag[localComIndex] <> oldRxFlag[localComIndex] localSize := FlushBuffer(localComIndex) if localSize > 0 Com1.tx(_Output - _SerialPortGroupSize, prefixList[localComIndex]) localIndex := 0 repeat localSize Com1.tx(_Output - _SerialPortGroupSize, tempBuffer[localIndex++]) ' Carriage return added to make terminal window easier to read. ' Remove once finished debugging. TbugTx(13)The above code is the heart of the MergePad program. The serial drivers watch of the end of message characters so this loop just monitors the appropriate rxFlag element to see if a new message has been received. (I personally think this is pretty cool.)
Another test performed by the PadSimulator program is simulating key-presses to all the pads at once. The key-presses of each pad are kept separate. Once an end of message character is received by the MergePad program the entire set of key-presses in displayed (with appropriate prefix).
Here's the test code.
Tbug(string(13, "New test. Interleave input from ")) TbugDec(_Output) Tbug(string(" pads.")) Tbug(string(13, "All ")) TbugDec(_Output) Tbug(string(" serial lines will be used at once.")) Tbug(string(13, "The Black Box will keep the data from each keypad separate.")) Tbug(string(13, "All the characters received on an individual line will be transmitted")) Tbug(string(13, "from the Black Box after an end of message character is")) Tbug(string(13, "received on the individual line. ")) characterIndex := 0 repeat localIndex from 0 to _Output doneFlag[localIndex] := 0 localIndex := @padFakeOutput01 repeat while doneFlag[_Output] < _Output doneFlag[_Output] := 0 ' use to count keypads that are done repeat outputIndex from 0 to _PadG if doneFlag[outputIndex] == 0 ' if zero then this pad hasn't reached end of message character waitcnt(clkfreq / 2 + cnt) ' keep things slow enough to watch. Tbug(string(13, "Output from pad")) TbugTx(prefixList[outputIndex]) Tbug(string(" = ")) TbugTx(byte[localIndex + (outputIndex * _KeyPressBufferSize)])' Send data to terminal window Tx(outputIndex, byte[localIndex + (outputIndex * _KeyPressBufferSize)]) ' Send data to black box if byte[localIndex + (outputIndex * _KeyPressBufferSize)] == _EndOfMessagePad '"#" doneFlag[outputIndex] := 1 else doneFlag[_Output]++ ' add up keypads that are done. localIndex++ ' increment to next character in each keypad string. waitcnt(clkfreq * 2 + cnt) ' keep things slow enough to watch. Tbug(string(13, "End of interleave test.")) Tbug(string(13, "Hopefull the ", 34, "Black Box", 34, " kept the individual")) Tbug(string(13, "keypad data separate."))Here's what is displayed on the terminal window from the PadSimulator Prop.
New test. Interleave input from 7 pads. All 7 serial lines will be used at once. The Black Box will keep the data from each keypad separate. All the characters received on an individual line will be transmitted from the Black Box after an end of message character is received on the individual line. Output from padA = 1 Output from padB = 2 Output from padC = 3 Output from padD = 4 Output from padE = 9 Output from padF = 0 Output from padG = 1 Output from padA = 1 Output from padB = 2 Output from padC = 3 Output from padD = 4 Output from padE = 9 Output from padF = 0 Output from padG = 2 Output from padA = 1 Output from padB = 2 Output from padC = 3 Output from padD = 4 Output from padE = 9 Output from padF = 0 Output from padG = 3 Output from padA = 1 Output from padB = 2 Output from padC = 3 Output from padD = 4 Output from padE = 9 Output from padF = 0 Output from padG = 4 Output from padA = # Output from padB = # Output from padC = # Output from padD = # Output from padE = # Output from padF = # Output from padG = 5 Output from padG = 6 Output from padG = 7 Output from padG = 8 Output from padG = 9 Output from padG = 0 Output from padG = # End of interleave test. Hopefull the "Black Box" kept the individual keypad data separate.As you can see, the PadSimulator is displaying each character as it is transmitted. It is also indicating which serial line is is using by adding the padX statement.
Here's what is displayed by the MergePad program.
A1111# B2222# C3333# D4444# E9999# F0000# G1234567890#Here's the corresponding data contained in the DAT section.
padFakeOutput01 byte "1111#", 0[15] padFakeOutput02 byte "2222#", 0[15] padFakeOutput03 byte "3333#", 0[15] padFakeOutput04 byte "4444#", 0[15] padFakeOutput05 byte "9999#", 0[15] padFakeOutput06 byte "0000#", 0[15] padFakeOutput07 byte "1234567890#", 0[9]The above test was performed at a leisurely pace so the data could be easily watched.
The same test is again performed without the delays.
The last test uses the data in the array "sequence" to determine which serial line to use.
sequence byte "CBAGFEDBBAAEEDDFFGGCC", 0 '' sequence is a list of keypads to simulate. The program '' uses this list with the data below to generate simulated '' input from keypads. '' Each padFakeOutputXX array should have exactly _KeyPressBufferSize '' members. If the keypad data is less than _KeyPressBufferSize '' characters long, then add zeros to pad the array so it is exactly '' _KeyPressBufferSize characters long. ' 1111111111 '01234567890123456789 padFakeOutput00 byte "123*4567#", 0[11] padFakeOutput01 byte "1111#", 0[15] padFakeOutput02 byte "2222#", 0[15] padFakeOutput03 byte "3333#", 0[15] padFakeOutput04 byte "4444#", 0[15] padFakeOutput05 byte "9999#", 0[15] padFakeOutput06 byte "0000#", 0[15] padFakeOutput07 byte "1234567890#", 0[9] padFakeOutput08 byte "4321#", 0[15] ' 1111111111 '01234567890123456789 padFakeOutput09 byte "987*654*3210#", 0[7]The data in the "padFakeOutputXX" is used to generated the simulated key-presses.
I've attached the achives of both programs.
It is still important to determine the hardware you will need to interface the keypads to the Propeller.
One possible problem would be if someone entered a very long series of key-presses without using the end of message character. Each serial line has a 512 byte rx buffer. Key-presses will like be lost if the buffer is filled without an end of message character being received.
Duane
Edit(3/11/15): Warning, the code attached is an old version. There are likely better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't code similar to what is attached here on my on GitHub, send me a message and I'll make and check for any improved versions of the code.