Controlling SSP2_SCK & PIN12/LCD_D11/UEXT_CS on UEXT

[IWriteCode]

We are using the Olinuxino Maxi board and want to use the UEXT-RS485 module. In order to do so we need to use the SSP2_SCK & PIN12/LCD_D11/UEXT_CS pins on the UEXT connector to control the TX/RX.

Linux version:
Linux olinuxino 3.7.2-2-ARCH #1 PREEMPT Thu Jan 17 07:51:19 UTC 2013 armv5tejl GNU/Linux


To see if we are able to control these pins we hooked up a LED (with resistor) and tried to make it blink.

In order to do so we tried to control these pins using GPIO from /dev/class/gpio/ But it looks like these pins aren't available there. The pins on the GPIO_CON worked fine and let the LED blink. On the pins we need, UEXT.9 & UEXT.10, nothing happens.

So we tried using the gpio_mmap.h ( http://olimex.wordpress.com/2012/09/11/imx233-olinuxino-gpios-faster-and-faster/ ) but that didn't work either. Same results, the LED connected to the GPIO_CON blinked, on UEXT.9 & UEXT.10, nothing happend.

How can we make this work?

[LubOlimex]

Hey IWriteCode,

iMX233-MAXI is compatible with MOD-RS485.

If you have problems controlling SSP2_SCK and PIN12/LCD_D11/UEXT_CS you might configure the RS485 so that it takes SCK and CS from UEXT pins 5 and 6 (I2C) – which means signal lines I2C_SCL and I2C_SDA. This is done by reconfiguring the hardware SMT jumpers named SCL/SCK and #SS/SDA which by default are in SCK and SS positions. You must cut between the default pads and solder-connect the middle pad to the other side(respectively SCL and SDA, 1-2 positions for both).

Please refer to the schematic to see the SCL/SCK and #SS/SDA jumpers clearly: https://www.olimex.com/Products/Modules/Interface/MOD-RS485/resources/MOD-RS485-schematic.pdf

Best regards,
Lub/OLIMEX

[jeroends]

I had no problem using those pins (older kernel version so I'm not shure if it is enabled in the new one). Make shure you use the right gpio name for it, ie. the pin12/lcd_d11/cs ie actually pin 13 on the gpio connector and is called gpio 3 in thze linux system (just to make things simple  )

[jeroends]

I did a simple quick test on a 3.7.1 kernel, worked perfectly. Don't forget to export the gpio pins.
for the Uext chip select this is gpio 3 and for the ssp_sck this is gpio 24.
Try:
echo 3 > /sys/class/gpio/export
echo 24 > /sys/class/gpio/export

Determin the direction:
echo out > /sys/class/gpio/gpio3/direction
echo out > /sys/class/gpio/gpio24/direction

And play with them:
echo 1 > /sys/class/gpio/gpio3/value
echo 0 > /sys/class/gpio/gpio3/value

echo 1 > /sys/class/gpio/gpio24/value
echo 0 > /sys/class/gpio/gpio24/value
etc etc

[Gilles]

I'm trying with the 3.2.2-2 kernel (archlinux) and it's still failing here.

I'm running the following bash script:

echo 3 > /sys/class/gpio/export
echo 24 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio3/direction
echo out > /sys/class/gpio/gpio24/direction
while(true) do
echo 1 > /sys/class/gpio/gpio3/value
echo 1 > /sys/class/gpio/gpio24/value
sleep 1
echo 0 > /sys/class/gpio/gpio3/value
echo  0 > /sys/class/gpio/gpio24/value
sleep 1
done

I have connected a led between the SCK and the GND with a resistor. I would expect the led to be blinking at 0.5 HZ, but it just stays on.

Any idea's what I'm doing wrong?

[Gilles]

I retried the test with an older kernel ("Linux olinuxino 2.6.35.3_OLinuXinoR4 #11 PREEMPT Mon May 21 10:27:52 EEST 2012 armv5tejl GNU/Linux".

In that case it does work. It seems like a problem appeared in the somewhere in the recent kernels, or some module that is enabled in my 3.7.2 kernel is causing this issue.

[Gilles]

I crossrecompiled my own kernel without SPI support, and now the script is working like it should.

It seems like both the SSP2_SCK and UEXT_CS pens are claimed by the SPI driver. Probably a pretty logical choice, but it took me a while to find that out.

[paulo]

Hi,

I am using olinuxino maxi with mod-rs485 to send and receive Modbus commands to other devices.
(Using Linux 2.6.35-8-ARCH+ armv5tejl)
All seams fine including controlling SSP2_SCK & PIN12/LCD_D11/UEXT_CS on UEXT witch I tested with C code (GCC)
except I am having problems with waiting for the Uart to finish sending the chrs (so I can disable transmit).
This is what I am doing:

GPIO_WRITE_PIN(24,1);   // RS485 Write enable
GPIO_WRITE_PIN(3,1);   // RS485 Read disable to avoid echo back
bytes_sent = write(Port, string, len);
tcdrain(Port);   
//usleep(4500);
GPIO_WRITE_PIN(24,0);   // RS485 Write Disable
GPIO_WRITE_PIN(3,0);   // RS485 Read enable

select(Port+1, &fds, NULL, NULL, &timeout);
read(Port, buff, sizeof(buff));       


But on a scope I can see that PIN 24 only gets set to zero about 20 ms after the last chr has been transmited.
I confirmed it is the tcdrain() call that returns very late.
(replacing tcdrain() by the usleep() - found 4500 on the scope to be time to send the test I am using)

So what I need to find out is how to make tcdrain() work (timly) or if there is any alternative to be able to control the RS485 direction pin (would rather not use automatic direction on the RS485).

Any ideas?

Thank in advance,

Paulo