I'm new to Arduino, and as part of a project I've written a small sketch that allows me to use the serial monitor to input a character, have it transmit on the RX connection then transmit back on the TX connection.
The program is working as intended, and I can capture the waveforms, but I have no idea how to decode what I'm seeing.
Are there any resources for this topic?
The attached photo is the captured waveform when I input a 5 into the serial monitor. I just don't see how this bit pattern represents a 5.
And be aware that the serial monitor adds a line-end sequence when you send - you can change this
to no-line-ending if you want just a single ASCII character to be sent.
Thank you everyone, I didn't realize it was being sent as an ASCII character, which has the value of 53, and there is indeed a new line character at the end as well.
Took a while to figure it out, but it makes sense now.
s9acasl:
Thank you everyone, I didn't realize it was being sent as an ASCII character, which has the value of 53, and there is indeed a new line character at the end as well.
Took a while to figure it out, but it makes sense now.
++Karma; // Well done for figuring that out, it's a common misunderstanding here not appreciating the difference between a variable stored as binary and the same number converted to ASCII for transmission to a display or other device.
I used a UART for my senior project at DeVry where I used a very expensive ATE custom metal keyboard bought
from a surplus store (because it looked so cool with multicolored keys) but discovered that all the key codes
were custom and I needed ASCII, so I used the 8-bit parallel output of the keyboard to drive leds and recorded
the binaray bit pattern to get the output code of that key, then looked at the character on the key and looked
up the ASCII code I wanted that key to send. Then I used the 8-bit parallel output to address an EPROM where
I stored the desired ASCII code at that address so when I pressed that key, it read the ASCIi data stored at that
address . Then I connected connected the DATA lines of the EPROM to the parallel input of a UART which
converted the parallel ASCII data to serial ASCII which was my end objective. Worked perfectly. I programmed
all the ASCII codes I wanted for all the keys and wound up with a serial ASCII keyboard I used for the user
input device for a menu on a Monochrome RGB monitor used for my 68000 based project.
I doubt you want to go through all that trouble though but thought I'd throw that out there...
raschemmel:
I used a UART for my senior project at DeVry where I used a very expensive ATE custom metal keyboard bought
from a surplus store (because it looked so cool with multicolored keys) but discovered that all the key codes
were custom and I needed ASCII
"Idle" state is 1. The first bit is a start bit. And there is a "stop bit" at the end.
s10101100S s01010000S
And then, bytes are transmitted least-significant bit first, so you have to reverse them:
Nope. 8bits (one more bit than ascii, which is actually only a 7bit code.)
Keyboards are weird. A USB keyboard generates codes that are NOT ascii, and they get sent to a PC, where they are translated to ANOTHER set of codes that ALSO isn't ASCII, and other levels of code finally will give you ascii code (or maybe that new Unicode stuff.)
The is probably because the IBM PC had its standard keyboard codes, and then Apple and the USB people couldn't possibly have used that when they started actually implementing USB peripherals... Sigh.
The project was in 1995 so I don't remember
the codes but what I DO remember is the number
of address bits for the EPROM was made for an
8-bit microprocessor so I HAD to use 8-bits
generated by each key. Moreover, the connector
on the keyboard had one ground and eight data
pins and the key value was latched so as long
as their was power , you could take a meter and
read the high or low on each pin from right to
left. (and Paul, it was TTL). Is it possible the MSB
was NOT ALWAYS Zero ? Absolutely ?
Can I remember if it was or wasn't ? Absolutely not. I just remember there were 8 data pins and one ground.
That was not an uncommon use of an eprom (or prom), I've seen it used for a state machine where the address input represents the current state and conditional inputs, and the data output the next state, and as a clock generator in an old video display terminal where the address input was a simple binary counter, and the outputs were the clock signals needed to generate the individual pixels, horizontal sweep timing, vertical sweep timing, etc - a rather complex set of wave-forms in the old CRT monitors. The alternative at the time would have been either discrete logic gates or possibly a custom logic chip, since microprocessors were still in their infancy running far to slow to be usable.
At time I asked myself "what takes 8 bits IN and outputs whatever you want ?"
and then I asked myself "If I have 8 bits parallel with the ASCII code, what takes 8 bits parallel and outputs 8 bits SERIAL"
That was not an uncommon use of an eprom (or prom)
Or you could say it was just a memory-mapped keyboard (literally)
