OpenWrt Forum Archive

Topic: (TL-WR703n / GPIO / Misc) AR9331 pinouts?

The content of this topic has been archived between 7 Oct 2014 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

but if that make hard to line them out,is any possible to make a usb2gpio small board?

could do, but I want the flexibility. I will hook the wires up to a female pin header and route that through the case. Then I can experiment on a pin by pin basis. The easy way out would be a I2C expander chip, if that's what you want. I want to add hacked airwick PIRs etc. Call me cheap, but it is fun! wink

robthebrew wrote:

could do, but I want the flexibility. I will hook the wires up to a female pin header and route that through the case. Then I can experiment on a pin by pin basis. The easy way out would be a I2C expander chip, if that's what you want. I want to add hacked airwick PIRs etc. Call me cheap, but it is fun! wink

fun is enought,keep find out them,find all the hidden bastard.

I've read the whole thread for the second time (and the wiki), and still don't understand exactly which gpios are available and how to access them.

For me, with a fairly recent self-build, GPIO8 (USB Power) is working from the command line:

echo 0 > /sys/class/gpio/gpio8/value
echo 1 > /sys/class/gpio/gpio8/value

Also the blue led, GPIO27
echo "1" > /sys/devices/platform/leds-gpio/leds/tp-link:blue:system/brightness
echo "0" > /sys/devices/platform/leds-gpio/leds/tp-link:blue:system/brightness

But writing directly to 27 doesn't work:
echo 1 > /sys/class/gpio/gpio27/value
-ash: can't create /sys/class/gpio/gpio27/value: nonexistent directory

And trying to set up 27 doesn't work:

echo 27 > /sys/class/gpio/export
ash: write error: Device or resource busy

I have these gpio modules installed; what else do I need?

 opkg list_installed | grep gpio
kmod-gpio-button-hotplug - 3.7.2-1
kmod-input-gpio-keys-polled - 3.7.2-1
kmod-leds-gpio - 3.7.2-1

Which gpios not otherwise being used (e.g., for usb power or blue led) are available other than 7 and 29 (and what module do I need to make those and any others available--not specifically for i2c)?

(Last edited by lizby on 15 Feb 2013, 02:45)

27 is in use by the led, which is why you can't access it directly. Uninstall kmod-leds-gpio to get direct access.
The wiki lists the gpios and where they are. 0,6,14,15,29 are all usable.
They all have pull-up/down resistors, so you will need to take that into account, or unsolder the resistors.

Thanks, Rob, for the list and the confirmation.  I had also tried exporting 0, and got the same error message as with 27, and so assumed that I needed some other module.  I've now tried exporting and setting/resetting 7 and 29, and got no errors.

I haven't wired anything up yet, so haven't tested the actual outputs--but I have confidence now.  I'll be using it for a 6-pin dip relay, LH1156, so keeping the existing pulldown resistors will be fine.

Suppose you want to use gpio8 (usb power) to toggle a relay:

echo 1 > /sys/devices/virtual/gpio/gpio8/value
echo 0 > /sys/devices/virtual/gpio/gpio8/value

How do you prevent gpio8 from being turned on during bootup?

Put a pull-down resistor that will fix the voltage level while the GPIO is in tristate or input mode.

The thing I did not record was which resistor (there was one on all the gpios I freed) was pull up and which down.
Squonk's schematic should clarify that.
I use, I made sure that every peripheral started after the router so as not to get undefined outputs, but just leaving the pulldown might be a better and easier way.

Squonk wrote:

Put a pull-down resistor that will fix the voltage level while the GPIO is in tristate or input mode.

That would still not fix the problem, as I see it, of usb power being turned on sometime during the boot process.  I was wondering if anyone knew when and where that was done so that it could be prevented from being turned on.

How to enable control GPIO13-16:
https://forum.openwrt.org/viewtopic.php … 21#p175021
https://forum.openwrt.org/viewtopic.php … 23#p186723 <=this same as upper url only difference sending RAW command

uboot wrote:

    /* Disable clock obs
     * clk_obs1(gpio13/bit8),  clk_obs2(gpio14/bit9), clk_obs3(gpio15/bit10),
     * clk_obs4(gpio16/bit11), clk_obs5(gpio17/bit12)
     * clk_obs0(gpio1/bit19), 6(gpio11/bit20)
     */

(from u-boot/board/ar7240/ap121/ap121.c)

lizby wrote:
Squonk wrote:

Put a pull-down resistor that will fix the voltage level while the GPIO is in tristate or input mode.

That would still not fix the problem, as I see it, of usb power being turned on sometime during the boot process.  I was wondering if anyone knew when and where that was done so that it could be prevented from being turned on.

I didn't know that you were speaking of GPIO8 specifically, as you started this thread looking for all available GPIOs.

In order to remove the automatic USB Power function on GPIO8, you need to edit the file "trunk/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr703n.c" and comment out lines 75-77, then recompile OpenWrt.

Squonk wrote:

In order to remove the automatic USB Power function on GPIO8, you need to edit the file "trunk/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr703n.c" and comment out lines 75-77, then recompile OpenWrt.

Thank you Squonk.  I was hoping there was a rc.d file or similar which could be edited, but commenting out the lines in the C code and recompiling is no big problem.

(Last edited by lizby on 23 Feb 2013, 15:26)

lizby wrote:
Squonk wrote:

In order to remove the automatic USB Power function on GPIO8, you need to edit the file "trunk/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr703n.c" and comment out lines 75-77, then recompile OpenWrt.

Thank you Squonk.  I was hoping there was a rc.d file or similar which could be edited, but commenting out the lines in the C code and recompiling is no big problem.

Unfortunately no, there is no editable config file for that. I hate these hardwired stuff in the board support file... There should be a way to override them without recompiling, I agree.

Thank you for the link!

Yes, the TL-WR703N is heavily based on Atheros AP121 reference design, although there are some differences.

I fully reversed-engineered the board, so the GPIOs are now all well know, please check:
http://squonk42.github.com/TL-WR703N/

(Last edited by Squonk on 24 Feb 2013, 00:32)

any news about jtag ?

Is it possible to convert gpio pins to be second uart via bitbanging? I searched gpio kernel modules and don't see one for uart bitbanging. Or this is just not possible to do?

Maybe a different approach: There are different chips out there to convert SPI or I2C to UART. For example this one already has kernel support: Supported ICs are MAX3107, MAX3108, MAX3109, MAX14830. Each IC contains 128 words each of receive and transmit FIFO that can be controlled through I2C or high-speed SPI.

Did anybody got sd card to work via spi pins on ar9331?

UPDATE: found this tutorial:
http://wiki.openwrt.org/doc/howto/mmc_over_gpio has anybody tried this or ar9331? I'll be using GPIO 20, 21, 22 and 23 for pins...

(Last edited by valentt on 19 Apr 2014, 22:06)

bertc3p0 wrote:
robthebrew wrote:

imperfect, can you elaborate on the SPI contacts?

love your work btw.

IMHO the flash is connected through SPI (MOSI,MISO,CLK,CS0). CS1 is shared with GPIO_0.
Should be all you need to connect another SPI device.

How can I connect another SPI device?

If I use same SPI pins for both SPI devices (MOSI, MISO and CLK) then I use CS0 and CS1 to choose SPI device, right?
But wouldn't that crash device? If I disable CS0 and enable CS1, then external SPI flash memory would be used, but internal wouldn't be available anymore. Wouldn't that cause issues or even crash OpenWrt?!?

I'm SPI newbie so need a bit more explanation how to connect extra SPI based flash to AR9331 while letting internal work as usual.

Thanks!

Squonk wrote:

The AR9331 has only one single hardware serial port, see http://wiki.openwrt.org/toh/tp-link/tl- … 331.pinout for details.

Although you cantry to  bit-bang an UART in software using simple GPIO pins, it will never be very efficient and you will not be able to get high bitrates either.

Not counting for accuracy problems with a non real-time multi-tasking kernel that will add up to some 10s of ms of jitter because of random task switching...

Maybe you can try with an USB<->UART adapter, it really depends on your needs.

Squonk can you please explain how to bit-bang UART via GPIO pins, I can't find this documented anywhere, so more info is much appreciated. Thanks!

valentt wrote:
Squonk wrote:

The AR9331 has only one single hardware serial port, see http://wiki.openwrt.org/toh/tp-link/tl- … 331.pinout for details.

Although you cantry to  bit-bang an UART in software using simple GPIO pins, it will never be very efficient and you will not be able to get high bitrates either.

Not counting for accuracy problems with a non real-time multi-tasking kernel that will add up to some 10s of ms of jitter because of random task switching...

Maybe you can try with an USB<->UART adapter, it really depends on your needs.

Squonk can you please explain how to bit-bang UART via GPIO pins, I can't find this documented anywhere, so more info is much appreciated. Thanks!

First, SPI and UART are both serial interfaces, but they are different:

  • SPI is a synchronous interface, meaning that data transitions are related to a clock signal

  • UART is an asynchronous interface, meaning that there is no explicit synchronization to a clock, but that data transitions can be retrieved if they don't fluctuate too much from the nominal data rate, and only for a limited period of time no longer than a single character

This is why an UART does not need a separate clock signal: it is embedded into the data in the form of a start and stop bit that help the receiver to retrieve the data transition timing, while the SPI has a separate clock.

Having no clock, this in turn explains why the UART doesn't require any master or slave election, unlike the SPI interface, unless there are more than one device willing to talk on the same signals like on the RS485 bus. In this case, this is the global application design that regulates when slaves are speaking in order to avoid collisions.

For the SPI, a device acts as a master, and all other are thus slave devices. Addressing is done by the master using a separate "chip select" signal for each slave device.

The UART uses 2 signals for data, one for transmitting, one for receiving, and of course, you must cross these between 2 devices wink

The SPI uses also 2 signals for data, one for Master Out / Slave In (MOSI) direction, the other for Master In / Slave Out (MISO) direction.

Both interfaces require to serialize bytes to/from a single wire: this operation which must be performed at the highest possible speed is generally done in hardware using shift registers.

Back to the AR9331, it has effectively only one simple hardware UART used by the console, and one SPI interface used by the SPI Flash chip, although it also has 2 "chip select" (CS) signals.Unfortunately, the way it is written currently, the SPI Flash driver is not able to share the SPI access among several chips, unless you deeply modify it sad

As for the UART, it is rather difficult to avoid both the U-Boot bootloader and the Linux kernel from using it to output some messages, making it very difficult to use for another usage.

The only possibility left is to perform the serialization/deserialization in software using normal GPIO pins. This method, called "bit-banging" is difficult to implement for an UART, given that the jitter due to task switching in Linux will not allow to have accurate data transitions. It is much easier for the synchronous SPI interface, as you will drive the clock at your pace, even if it is not very regular. But don't expect the same performances as a hardware shift register, of course!

A good example of software bit-banging the SPI interface on the AR9331 is in the Arduino Yùn "Bridge" library, which does exactly that to interface to the AVR SPI bus using AR9331 GPIO pins.

(Last edited by Squonk on 3 Jul 2014, 21:37)

Sorry, posts 126 to 125 are missing from our archive.