Er, Um.... yeah.
https://bbs.archlinux.org/viewtopic.php … 7#p1419517
I remember when you said that and I checked to make sure that the connections were correct. With anything else I've ever worked with you always connect the Tx of a device with the Rx of the other. In this case the Tx and Rx of the converter are connected respectively to the Tx and Rx of the controller. This is backwards than it should be. I looked and saw I had the converter's Tx and the controller's Rx connected and figured I was good to go.
Mapping should be:
Converter Tx -> Microcontroller Rx
Converter Rx -> Microcontroller Tx
Mapping was:
Converter Tx -> Microcontroller Tx
Converter Rx -> Microcontroller Rx
So I figured out why the converter bridge was not working. I realized that if I shorted the Tx/Rx together on the bridge that the loopback test worked just fine. So I thought, just on a whim what would happen if I shorted the terminals together AND jumped my Rx pin from the controller in a sort-of three terminal node. Turns out, this worked! I sat here for a moment and thought what could be causing this .. I conjured up the notion that perhaps the Rx and Tx connections I was using were swapped. So, I simply swapped the way I was connecting the device and voila, it worked.
Just for reference of others, at least for the bridge that I am using, the mapping looks like this:
Converter Tx -> Microcontroller Tx
Converter Rx -> Microcontroller RxI imagine the silk screens on the PCB were alluding to Tx and Rx connections with respect to how the target device should be wired up, but what a terrible idea.
Er, Um.... yeah.
https://bbs.archlinux.org/viewtopic.php … 7#p1419517
I don't have a USB serial device handy right now, so you will have to do the legwork.
After you attach the device, look it /dev and find the owner and group of the ttyUSB0 node. The owner will be root. The group may be root, or it may be something else. If it is something else, just add your user to that group, log out, and log back in. If the group is root, things get a little more complex. The real solution is to write a udev rule to mount it with a group that normal users can join.
The quick and nasty work around for this is to, after you connect the device, use sudo to chown the device node to your user name.
So I figured out why the converter bridge was not working. I realized that if I shorted the Tx/Rx together on the bridge that the loopback test worked just fine. So I thought, just on a whim what would happen if I shorted the terminals together AND jumped my Rx pin from the controller in a sort-of three terminal node. Turns out, this worked! I sat here for a moment and thought what could be causing this .. I conjured up the notion that perhaps the Rx and Tx connections I was using were swapped. So, I simply swapped the way I was connecting the device and voila, it worked.
Just for reference of others, at least for the bridge that I am using, the mapping looks like this:
Converter Tx -> Microcontroller Tx
Converter Rx -> Microcontroller Rx
I imagine the silk screens on the PCB were alluding to Tx and Rx connections with respect to how the target device should be wired up, but what a terrible idea.
Anyway, to answer your question, the owner of /dev/ttyUSB0 is root and the group is uucp. I think when I installed Arch I exactly followed the suggestion on the wiki to just add myself to Wheel, Power, and something else. the GTKterm program, on the other hand, is root/root for owner/group.
]]>After you attach the device, look it /dev and find the owner and group of the ttyUSB0 node. The owner will be root. The group may be root, or it may be something else. If it is something else, just add your user to that group, log out, and log back in. If the group is root, things get a little more complex. The real solution is to write a udev rule to mount it with a group that normal users can join.
The quick and nasty work around for this is to, after you connect the device, use sudo to chown the device node to your user name.
]]>screen, minicom (both in community) or putty (in the AUR)
Edit: BTW, screen is much much more than a serial terminal. You may want to stay away from that one
Thank you. When I first posted here you made a comment regarding remedying the permissions so I do not have to call sudo each time I want to run a program. Currently, I have to sudo any program that was installed outside the scope of my home directory.
Loopback test works with picocom and nothing is coming through. Must not have been GTKterm. This is turning out to be quite a difficult task.
]]>Edit: BTW, screen is much much more than a serial terminal. You may want to stay away from that one
]]>My last suggestion is to ensure that hardware flow control (or handshake) is off. Other than that, I would need to hang a scope on it.
Indeed, it is. The Mega UART most certainly works considering I programmed it using the Arduino Serial API - so I am confident that side of things is working. It's definitely something wrong with either my GTKterm configuration or the converter device, but I didn't do anything to this thing (the driver was already installed).
All I can say is that the device has a small Tx LED on it that flashes when data is being transmitted. When I type information into the GTKterm window that LED does nothing unless I have the Tx/Rx shorted together on the converter. If Tx/Rx are connected to the appropriate pins on the controller than that "transfer" LED does not flicker when using GTKterm.
Are there any other terminal programs like GTKterm that you may suggest? I would just like to try another one just to ensure this program is not the problem, which is unlikely anyway.
]]>Something is not right with the converter or GTK. Any more ideas on getting GTK setup ?
]]><hopeful>Do you have an oscilloscope? </hopeful>
First, I think you have a mismatched Baud. Check your settings in GtkTerm. It could also be the uController. I know you said you have it set for 9600 Baud, but are you sure? The divisor settings are dependent on your clock frequency. Are you sure you are using the correct divisors for the frequency of your crystal? And are you using a crystal, ceramic oscillator, or external oscillator for your time base?
I did not think the internal RC oscillators were that bad off, so I was using the internal 8MHz (DIV8 = 0 fuse bit). Taking your advice I just refused the AVR and set it to use a 20MHz clock (external crystal oscillator) to no avail. The setting in GTKterm is certainly 9600 baud.Referencing the datasheet for the Atmega328P we have:
Which gives a a UBRR register value of 129 corresponding to normal speed (U2Xn = 0). This is all computed for me at compile-time via this formula:
20,000,000/(16*9600) - 1 = 129.2 ~ 129 truncated.
That the two devices can communicate tells me they both might be using the same wrong Baud.
I was also suspicious of this .. I do not have a trivial way to test this though. Perhaps some workaround using timers is about the best I can do; no oscilloscope here. Doing a quick high-level test I did find something rather interesting though. Both devices are set to run at 9600 baud. One device is operating at 8MHz (internal oscillator) and the other is using an external 20MHz crystal. I am getting UART communication between the devices, but certainly not the characters I'm sending..
The other problem is that I think you have "Local Echo" turned on in GtkTerm. This places the system in "Half Duplex" mode in which data are not expected to be echoed from the Atmel. That you are getting two characters when the pins are shorted tells me you get the local echo and the loopback. Then the loopback is missing, you still get the local echo. Also, make sure you have parity turned off.
GTKterm does not actually show you what you are typing into the terminal. That is, when you type a character then nothing is displayed to the screen. Presumably this character is sent out as you type it. I was under the impression that local echo would just echo what I type to the screen as well as send it out. Thank you for the clarification.
]]>Do you have an oscilloscope?
This is really what I was getting at with the voltmeter - not checking that devices are being supplied the proper volatage, but checking that signals are being sent when/where you expect them to be.
I don't have the fancy stuff - but I have used a cheap radio-shack multimeter to do such checks. If you do have an oscilloscope that's a much better idea ... I'm just "too ghetto" to think of the right ideas first - I think of the dumpster-electronics approaches first.
]]>The other problem is that I think you have "Local Echo" turned on in GtkTerm. This places the system in "Half Duplex" mode in which data are not expected to be echoed from the Atmel. That you are getting two characters when the pins are shorted tells me you get the local echo and the loopback. Then the loopback is missing, you still get the local echo. Also, make sure you have parity turned off.
]]>Do you have a voltmeter?
Of course. The supply use provides approximately 4.5V or so. The controller I use is fine at the operating voltage and presumably since USART is TTL I imagine it to be fine as well. Just to be sure, I used the 5V regulated supply from the converter bridge to drive both MCUs and it still did not work (but the MCUs were communicating just fine between one another as before).
And grounds are connected as they should between my circuit and the converter.
Frankly, the only thing I can begin to thing to do right now is use internal times and determine approximately how long the transfer is taking and compare that to the setup of 9600 baud.
]]>