I have an application that needs as many pins as possible as simple GPIO pins on the Edison Breakout board. They need to be able to drive TTL circuits or receive inputs from them.
I have started using TBX0108 "level shifters" 3.3V and 5V. What I'm finding on the 5V side is that not all the GPIO pins seem to behave the same. Using setup code like:-
pin = mraa_gpio_init(0);
if (mraa_gpio_dir(pin, MRAA_GPIO_OUT) != MRAA_SUCCESS)
fprintf(stderr, "Can't set MRAA_GPIO pin as output. ");
I get a nice high/low pulse on GPIO J17-pin1, this is not the case on others. For example JP18-pin2.
Pins JP17-7,8 & 9 are labeled open collector. I tried using a 1K pull-up to 3.3v on each but no total swing to TTL high/lows.
The outputs from the SD card pins (J19-12,13,14 and J19-12,13 and 14) seem to lock-up the board on boot-up if connected to these level shifters.
Is there startup code to "cleanout" the CPU so all pins default to plane GPIO's. I suspect Linux is altering some pins.
Alternatively since I know the direction of signals to/from the Edison rather than use the above "level shifters",
can I drive the output from an Edison directly to a TTL input gate? Alternatively via a diode (for safely).
Second can I take inputs to the Edison from a TTL gate via a 1K resistor to drop the voltage.
This is what the Propeller guys use for their 2.3V CPU chip.
Really would appreciate help from experts here as I don't want to burn out a chip testing.
Thanks in advance
>I have started using TBX0108 "level shifters" 3.3V and 5V. What I'm finding on the 5V side
I don't understand you.
One side should be 1.8V, the other 5V. Where do you get 3.3V?
You should deactivate kernel modules for the SD card, etc if you want to use their pins as GPIOs.
Thanks, sorry for the confusion.
I understood that the Edison is working on a 3.3V supply and that while the HIGH 1.3V the range is 0 to 3.3V, just as for TTL the HIGH is ~2.4V but the range is 0-5v.
So for the TBX0108's the Edison side (Vcca) would be 3.3V and the TTL side (Vccb), pin would be 5V
Signals go back and forth in both directions just the voltage level changes. Are you suggestion that Vcca should be only 1.3V? Would need another regulator. I see that the breakout board JP19-pin 2 puts out 1.8 Volts. Would that be usable as a Vcca for say 4 converters.
BTW, I answered my own second question, the 1.3V is not high enough to drive an input to a 74LS04 gate. So scratch that idea, will have to somehow stick to these level converters.
Again answering my own question...
It looks like you can use the breakout board J19-pin2 (V_V1P80) that delivers 1.8V to drive at least 4 of the TBX0108's. When I use this voltage (instead of 3.3V) I had a solid square waveform and solid TTL signals. So for others, for level converters, 1.8V on one side 5 V on the other.
For some reason J18 pin 2 (GP165) is not putting out a proper signal. Is there something special about this pin? On the scope the signal is square like the others but only half the height (<1Volt).</span>
I suspected I burned out that pin and tried another Edison board. Same result. I don't have another breakout board however. Is it possible the "burnout" is originating on the actual breakout board?
Can you point me to a URL that show to deactivate kernel modules for the SD card, etc. if you want to use their pins as GPIOs.
I would need to do this at boot time with something in .profile I assume?
How are you powering the board? I'm wondering if maybe you're demanding too much current from the Breakout board and that's why you're getting that behavior on J18 pin 2. Are you using an external power supply along with the micro USB connection?
Could you please share an image of your connection and of the output of J18 pin 2?
Pablo, I misunderstood the voltage the Edison runs at. Switching the level converters to 1.8 Volts cleans up most of my problems. However it seems that the pins JP19 12, 13, & 14 and JP20 pin 3 are "special". I cannot get the system to boot up if I connect them to the level converters using the Eclipse platform etc. I suspect Linux does something with them before I get to them.
I can now use all the other pins except JP18 pin 2 (GP165). That one is written up as a nothing special a GPIO pin. I cannot get any life out of it - noise. My suspicion is I somehow burned it out. I tried switching the Edison module. No effect. I have another breakout board on order to see if the problem is on my breakout board.
So all in all I have 35 pins to play with. It's going to be tight and I am going to have to do some multiplexing. The application is to run the Edison as a slave CPU on the S100 bus. FYI here is a picture:-
More info at www.S100computers.com
Anyway to only current help I could use is how exactly I could free up the above JP19 pins so they too are simple GPIO pins. Remember the Edison is not booting if I connect them to the level shifter.
If you are just interested in GPIOs you may use a portexpander: http://ww1.microchip.com/downloads/en/DeviceDoc/21952b.pdf http://ww1.microchip.com/downloads/en/DeviceDoc/21952b.pdf
I don't know if and how it is possible to use the SD-Card pins as normal GPIOs. If you want to change the logic levels for an SD-Card you should use a TXS0108 instead of TXB0108.
The TXS0108 supports SD-Cards up to Class 6.
As you already know, these pins are reserved for the SD card driver. You'll need to unload the SDIO kernel module and then recompile if you want to use them as simple GPIOs. However, I believe it is not enough just to unload the kernel module because these pins need to be defined for their new "function" and you'll probably need to develop a patch the image. This requires a lot of work. Flo1991 is a good suggestion, I would suggest you to give it a try.
Thanks again Pablo,
I think I'm getting there. It seems I can get the Edison module to work with enough GPIO pins to do what I need without any modifications. It's tight but workable. I have chosen to use an Atmel 1508 CPLD instead of what Flo1991 suggested. Probably overkill, but its one chip and it gives me great flexibility in terms of circuits in software rather than hardware.
So unused I have unused:-
JP19 pin 14 GP83 (SD data 3)
JP19 pin 13 GP82 (SD data 2)
JP19 pin 12 GP77 (SD card detect low input)
JP20 pin 14 GP81 (SD data 1)
JP3 pin 3 GP134 (UART2 (input)
I cannot seem to "mess" with these pins for Linux startup – and definitely don't want to modify the OS (way past my pay scale!).
Could I get your expert advice on a few further quick questions:-
I see GP77 says "card detect low". Is this a flag for the presence of an SD card, could I pull it high/low and get Linux to ignore the other SD pins on boot-up.
Currently the above pins are wasted for me. I was wondering if I could get smart and somehow squeeze in a SD card interface on the board. If I look at the Intel or SparkFun SD card circuits they have quite a few pins going to the card. SparkFun has:- GP82, GP83, GP79, GP78, GP80, GP81 and GP84.
However when I look at other circuits on the web they use only 4 pins in something called SPI mode. For example here:-
From my above spare pins could I use them to get a the SD card to work in SPI mode – without rearranging the Linux OS. If not what/how many other pins would I have to "give up". Realize this is a difficult hardware/software question -- anybody else please feel free to join in.
Thanks in advance
The Card detect pin is normally connected to a mechanical switch that is pulled up to 1V8 (high at edison) if the switch is open (no SD card detected) and pulled down to 0V -> low if a card is present.
You can see the mechanical contac on this picture on the left side : http://de.rs-online.com/largeimages/F7768306-01.jpg http://de.rs-online.com/largeimages/F7768306-01.jpg
By default this pin is used by the system to detect sd cards, so you have to modify the OS for using it as GPIO.
Refering to the SPI mode it is true that SD-Cards can be used in this mode, but this is slower and not supported by the default OS.
As a conclusion you cannot use any of the SD-Card pin without changing the OS.(see also )
guess I will have to pass on these pins then. Is a pity the default OS does not use one pin as a flag to see if an SD card is attached and if not free up the other pins as GPIO's. Can this be suggested to whoever does upgrades/improvements.
We really appreciate your feedback, we will pass this information/request to the appropriate team so hopefully they'll be able to improve this in future releases.