| Author |
Topic |
|
|
stratos
0 Posts |
 Posted - 16 Oct 2006 : 18:31:37
|
| I'm trying to control the data direction for the RS422/COM3 port on the Sphere II. Data seems to be getting out (according to the blip in my scope), but I can't read anything back from my slave device on RTU Modbus. Looks like I need to set GPIO3 to zero to enable RX (and set it to 1 for TX). The question is - where in the kernel code do I do that? I'll scoured through the code in arm/mach-ep93xx and haven't found any place that is obvious. Anybody run into this issue before? Thanks. |
|
|
rwhaley
628 Posts |
Posted - 17 Oct 2006 : 14:58:32
|
According to Russell King (leader of the ARM Linux kernel effort) the enable line should be controlled from the application not the kernel.
This topic has a kernel module example that can be used from your application to control GPIO3. |
 |
|
|
stratos
0 Posts |
Posted - 24 Oct 2006 : 13:34:36
|
Thanks for the reply.
I am going into the serial driver for this change because I need to be sure that the UART has completed transmission before flipping the GPIO line. This would be cumbersome, if not entirely unreliable, if it is done from userland.
Looking through the example code, I see a comment about how ep93xx-gpio.c is for GPIO Port B, 2 through 6.
The Sphere manual states the following re: the RS422 serial port:
"The standard Sphere configuration drives the transceiver's transmit-enable line with EP9315 GPIO3 and leaves the receiver permanently enabled. As a factory option, the receive-enable line can be driven by GPIO3 or independently by GPIO1."
Are these talking about the same GPIO3 pin? I looked in the EP9315 manual and it appears the data direction GPIO pins should be GPIO Port H, not Port B. Am I misinterpreting this information? I only need to control the TX of the RS422 and do not need interrupt capability.
|
|
|
|
rwhaley
628 Posts |
Posted - 24 Oct 2006 : 17:41:13
|
According the Sphere schematic EGPIO3 (which is on what Cirrus calls "Port A") is attached to where it controls the data direction of U14 which buffers the RS422 data lines. So the sphere schematic agrees with the manual.
Perhaps you are confusing the information about the direction of GPIO lines (which is specific to the EP9315) with direction of the RS422 data lines which is in a separate chip (U14). But I don't understand specfically what information you are refering to in the EP9315's manual.
Do you know how your hardware is configured? Did you request a non-standard configuration when you ordered your sphere? |
|
|
|
stratos
0 Posts |
Posted - 26 Oct 2006 : 11:06:50
|
Thanks. You have cleared up my confusion.
On a separate, but related, topic. We just upgraded to the latest 2.6.17 kernel posted on the ADS linux kernels section. While the ttyAM0 serial port works (for the console), I am now not able to write anything out of the other two serial ports - namely the RS422 ttyAM2 port. What new settings do I need to write out of these ports again with this new kernel? Thanks. |
|
|
|
rwhaley
628 Posts |
Posted - 26 Oct 2006 : 11:34:01
|
Thanks for reporting this bug with the serial ports in the latest kernel. We hope to have a new release shortly to fix this problem. We are sorry for any trouble that this causes you, hopefully you can use the old kernel until the fix is available.
|
|
|
|
stratos
0 Posts |
Posted - 26 Oct 2006 : 11:42:32
|
Thanks for getting onto this problem.
When will this fix be released? If it will not be released in the next day or two, can you please share some information in regards to what changes are being planned for this fix (so perhaps we could roll our own interim fix?) The GPIO stuff works with the new kernel, so it would be nice if we didn't have to roll back to the old kernel.
Thanks a bunch! |
|
|
|
rwhaley
628 Posts |
Posted - 26 Oct 2006 : 11:48:07
|
| We are only starting to look at the problem now. Generally speaking this sort of problem is not terribly difficult so I would expect a new kernel to be released within a week. As soon as we have a patch we will post it here. |
|
|
|
rwhaley
628 Posts |
Posted - 26 Oct 2006 : 14:07:13
|
| We found the problem and have a simple workaround, this hw_config.txt file will enable ttyAM1 and ttyAM2. If you are already using a hw_config.txt file to configure your display, then you need to add the 2 new u-boot commands from this file into your existing file. |
|
|
|
stratos
0 Posts |
Posted - 27 Oct 2006 : 17:28:09
|
Thanks. That did the trick.
On yet another related topic - this time HW-related.
As discussed before, the EGPIO3 pin is tied to the RS485 transceiver's TX enable line. However, once we got to that point, we realize that the UART TENn (EP9315 manual p157) is active-low, but is used to assert whenever there's data to send out in that port.
We have modified our kernel to use the TENn line to drive the EGPIO3. Unfortunately, the external transceiver used on the ADS sphere board is expecting the enable to be....drum roll...active high. Sigh.
Is there some miraculous bit that we are not aware of which would make all of this tie together properly? Or is there another custom board configuration that would work for our purposes? |
|
|
|
rwhaley
628 Posts |
Posted - 30 Oct 2006 : 09:46:03
|
There are at least 2 ways you can control the TX enable on the sphere:
1. With the previously discussed kernel module, controlling EGPIO3 directly.
2. By setting TonG (page 156) and then clearing and setting OUT1 (page 582) from software.
Our other boards also work through software control of the TX enable (typcially controlled from the application program - a straighforward (and the prescribed) way to control RS485 ports in ARM linux). |
|
|
| |
Topic |
|
All Forums
Hardware
RS422 Data Direction on Sphere II
Forum Locked
Send Topic to a Friend
Printer Friendly