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).
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?
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
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
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 Can't use GPIO 77 with MRAA )
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.