From richard.wilbur at gmail.com Thu Mar 1 20:33:30 2018
From: richard.wilbur at gmail.com (Richard Wilbur)
Date: Thu, 1 Mar 2018 13:33:30 -0700
Subject: [Arm-netbook] Testing: GPIO
In-Reply-To:
References:
Message-ID:
On Wed, Feb 28, 2018 at 2:41 PM, Luke Kenneth Casson Leighton
wrote:
> On Wed, Feb 28, 2018 at 9:09 PM, Richard Wilbur
> wrote:
>> After realizing that you mentioned all 8 GPIO lines were on the 20-pin
>> expansion header J5 in the microdesktop case, I consulted the
>> microdesktop schematic for clues.
>>
>> I suspect the UART and EOMA I2C pins should be left to those functions.
>
> yehyeh. UART implicitly tested "if console works it's probably
> good" and I2C with a bus scan, i2c-utils, if 0x51 EEPROM shows up,
> it's good.
>
>> I have added tables to the "Testing"[*] page under the "GPIO" section
>> with my nominations for which pins to test and their mapping back to
>> A20 register bits.
>
> awesome. it'll have to be done manually for now,
Are you suggesting that the testing "will have to be done manually"?
What is the time frame of "for now"?
I'm trying to figure out which pins of the expansion header we want to
test, which pins of the processor those correspond to, and thus which
registers and bits of those registers we need to manipulate. That
determines how I need to interact with the GPIO driver.
>> Luke, does this match your understanding of the GPIO pins to test?
>
> yep - GPIO_19,20,21 missing.
In the following table (created while I was trying to figure out which
GPIO were connected in the EOMA standard) you will see that EOMA nets
GPIO(18)/EINT3, GPIO(19), GPIO(20), and GPIO(21) are not connected on
the microdesktop schematic v1.7 from J14. Thus they are at J14 but
not available anywhere else in the microdesktop v1.7.
1342 Fri 23 Feb 2018:
EOMA A20 DS113 microdesktop
Net Name ball register CON15 pin J14 pin
PWM B19 PI3 43 22 GPIO(10)
EINT0 A6 PH0 63 32 GPIO(11)
EINT1 B6 PH1 17 9 GPIO(16)
EINT2 B2 PH14 44 56 PWFBOUT GPIO(17)
EINT3 C2 PH18 39 20 NC GPIO(18)
GPIO(19) A1 PH15 40 54 NC
GPIO(20) C1 PH17 41 21 NC
GPIO(21) B1 PH16 42 55 NC
We could obviously create a v1.8 schematic for the microdesktop and
connect these EOMA nets to a header, if desired.
From lkcl at lkcl.net Thu Mar 1 20:50:00 2018
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Thu, 1 Mar 2018 20:50:00 +0000
Subject: [Arm-netbook] Testing: GPIO
In-Reply-To:
References:
Message-ID:
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Mar 1, 2018 at 8:33 PM, Richard Wilbur wrote:
> On Wed, Feb 28, 2018 at 2:41 PM, Luke Kenneth Casson Leighton
> wrote:
>> On Wed, Feb 28, 2018 at 9:09 PM, Richard Wilbur
>> wrote:
>>> After realizing that you mentioned all 8 GPIO lines were on the 20-pin
>>> expansion header J5 in the microdesktop case, I consulted the
>>> microdesktop schematic for clues.
>>>
>>> I suspect the UART and EOMA I2C pins should be left to those functions.
>>
>> yehyeh. UART implicitly tested "if console works it's probably
>> good" and I2C with a bus scan, i2c-utils, if 0x51 EEPROM shows up,
>> it's good.
>>
>>> I have added tables to the "Testing"[*] page under the "GPIO" section
>>> with my nominations for which pins to test and their mapping back to
>>> A20 register bits.
>>
>> awesome. it'll have to be done manually for now,
>
> Are you suggesting that the testing "will have to be done manually"?
the mapping created manually. sorry, i was thinking in terms of
device-tree fragments... which don't exist yet.
> What is the time frame of "for now"?
when testing is required.
> I'm trying to figure out which pins of the expansion header we want to
> test, which pins of the processor those correspond to, and thus which
> registers and bits of those registers we need to manipulate. That
> determines how I need to interact with the GPIO driver.
yehyeh. and determining that interaction "has to be done manually".
if the devicetree fragment existed it would be a much simpler matter.
>>> Luke, does this match your understanding of the GPIO pins to test?
>>
>> yep - GPIO_19,20,21 missing.
>
> In the following table (created while I was trying to figure out which
> GPIO were connected in the EOMA standard) you will see that EOMA nets
> GPIO(18)/EINT3, GPIO(19), GPIO(20), and GPIO(21) are not connected on
> the microdesktop schematic v1.7 from J14. Thus they are at J14 but
> not available anywhere else in the microdesktop v1.7.
yep, forgot that. why the heck did i leave them out?? duur...
> 1342 Fri 23 Feb 2018:
> EOMA A20 DS113 microdesktop
> Net Name ball register CON15 pin J14 pin
> PWM B19 PI3 43 22 GPIO(10)
> EINT0 A6 PH0 63 32 GPIO(11)
> EINT1 B6 PH1 17 9 GPIO(16)
> EINT2 B2 PH14 44 56 PWFBOUT GPIO(17)
> EINT3 C2 PH18 39 20 NC GPIO(18)
> GPIO(19) A1 PH15 40 54 NC
> GPIO(20) C1 PH17 41 21 NC
> GPIO(21) B1 PH16 42 55 NC
>
> We could obviously create a v1.8 schematic for the microdesktop and
> connect these EOMA nets to a header, if desired.
yes. damn. i think it's probably that i didn't update the
micro-desktop schematic when i changed the EOMA68 spec from 24-pin to
18-pin RGB/TTL.
l.
From richard.wilbur at gmail.com Thu Mar 1 21:25:46 2018
From: richard.wilbur at gmail.com (Richard Wilbur)
Date: Thu, 1 Mar 2018 14:25:46 -0700
Subject: [Arm-netbook] Testing: GPIO
In-Reply-To:
References:
Message-ID:
On Thu, Mar 1, 2018 at 1:50 PM, Luke Kenneth Casson Leighton
wrote:
> On Thu, Mar 1, 2018 at 8:33 PM, Richard Wilbur wrote:
>> We could obviously create a v1.8 schematic for the microdesktop and
>> connect these EOMA nets to a header, if desired.
>
> yes. damn. i think it's probably that i didn't update the
> micro-desktop schematic when i changed the EOMA68 spec from 24-pin to
> 18-pin RGB/TTL.
Maybe you didn't update the micro-desktop schematic as much as you
intended to when you changed the EOMA68 spec from 24-pin to 18-pin
RGB/TTL but in v1.7 you did at least connect only the 6 high bits of
each color to the D/A convertors. The new pins are all connected to
useful sub-circuits on the micro-desktop board: SPI (expansion
header), SD0 (SD slot), and PWRON (power switch).
From richard.wilbur at gmail.com Thu Mar 1 21:46:31 2018
From: richard.wilbur at gmail.com (Richard Wilbur)
Date: Thu, 1 Mar 2018 14:46:31 -0700
Subject: [Arm-netbook] Testing: GPIO
In-Reply-To:
References:
Message-ID:
It looks to me like the fastest way to test the GPIO lines connected
on the micro-desktop board to VESA_SCL and VESA_SDA would simply be to
connect a VGA monitor to the micro-desktop and make sure it is
properly detected and a test image looks right on it. This would
leave 6 GPIO lines to test. So we get better test coverage for the
EOMA interface and shorter GPIO test at the same time!
From laserhawk64 at gmail.com Thu Mar 1 21:54:15 2018
From: laserhawk64 at gmail.com (Christopher Havel)
Date: Thu, 1 Mar 2018 16:54:15 -0500
Subject: [Arm-netbook] Testing: GPIO
In-Reply-To:
References:
Message-ID:
Oh LOL.
VGA is analog, and has six wires for color (red signal, red ground, ditto
each for blue and green). It's not /exactly/ serial (serial as I understand
it is inherently digital, which VGA is *ahem* very much not) but the
paradigm sort of fits. RGBTTL is parallel. You have one wire per bit of
color. So that's 18 wires. Plus your sync lines... which may or may not
match VGA signal standards, I'm not sure.
If you actually manage to figure out how to get that hooked up correclty,
let me know ;)
(Hint, it's doable, but you need additional components. There's a cheap
way, and there's an easy way, and they are two *very* different ways...)
Much easier suggestion: get a small LCD. *ANY* small LCD. Like a five or
seven inch display at the largest. Raw panel, no driver board. Get the
datasheet and a compatible connector. (If you source from eBay this is very
easy; those are almost all commodity displays with available datasheets.)
If it's a SMALL DISPLAY it *will* be RGBTTL, 90%+ of the time (I've seen
one exception to this ever and it was in an off-brand portable DVD player).
Wire it up. Wire it to the card connector. Add power. If you get a screen
that works, you've done it right.
From richard.wilbur at gmail.com Thu Mar 1 22:02:04 2018
From: richard.wilbur at gmail.com (Richard Wilbur)
Date: Thu, 1 Mar 2018 15:02:04 -0700
Subject: [Arm-netbook] Testing: GPIO
In-Reply-To:
References:
Message-ID:
If we did decide to roll a v1.8 micro-desktop board, it would afford
us the opportunity to bring two of the presently unconnected GPIO18-21
lines to the expansion header in place of VESA_SCL and VESA_SDA (which
are after all available on pins 15 and 12 of the VGA connector). If
VESA_SCL and VESA_SDA are more useful on the expansion header then, by
all means, forget this suggestion.
The other option to accommodate all our GPIO goodness would be to
replace J5 (2x10 header) with a 2x11 or 2x12 header allowing us to
bring all the GPIO pins to the expansion header (the only difference
being whether we would prefer to retain VESA_SCL and VESA_SDA in the
header).
From laserhawk64 at gmail.com Thu Mar 1 22:05:41 2018
From: laserhawk64 at gmail.com (Christopher Havel)
Date: Thu, 1 Mar 2018 17:05:41 -0500
Subject: [Arm-netbook] Testing: GPIO
In-Reply-To:
References:
Message-ID:
...BTW, those SCL and SDA lines on a VGA connector are for a nifty signal
coming from your monitor. It's called EDID and it's basically how every
modern OS magically knows what to do with the monitor it wants to display
on, regardless of the specs or origin of said monitor.
If you've ever had a cheap VGA cable where all the pins are present on the
connectors but those two lines are disconnected internally, you have
experience with what happens when you eff with those wires. Best to leave
them alone!
On Thu, Mar 1, 2018 at 5:02 PM, Richard Wilbur
wrote:
> If we did decide to roll a v1.8 micro-desktop board, it would afford
> us the opportunity to bring two of the presently unconnected GPIO18-21
> lines to the expansion header in place of VESA_SCL and VESA_SDA (which
> are after all available on pins 15 and 12 of the VGA connector). If
> VESA_SCL and VESA_SDA are more useful on the expansion header then, by
> all means, forget this suggestion.
>
> The other option to accommodate all our GPIO goodness would be to
> replace J5 (2x10 header) with a 2x11 or 2x12 header allowing us to
> bring all the GPIO pins to the expansion header (the only difference
> being whether we would prefer to retain VESA_SCL and VESA_SDA in the
> header).
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk
>
From richard.wilbur at gmail.com Thu Mar 1 22:42:02 2018
From: richard.wilbur at gmail.com (Richard Wilbur)
Date: Thu, 1 Mar 2018 15:42:02 -0700
Subject: [Arm-netbook] Testing: GPIO
In-Reply-To:
References:
Message-ID:
On Thu, Mar 1, 2018 at 2:54 PM, Christopher Havel wrote:
> Oh LOL.
>
> VGA is analog, and has six wires for color (red signal, red ground, ditto
> each for blue and green). It's not /exactly/ serial (serial as I understand
> it is inherently digital, which VGA is *ahem* very much not) but the
> paradigm sort of fits. RGBTTL is parallel. You have one wire per bit of
> color. So that's 18 wires. Plus your sync lines... which may or may not
> match VGA signal standards, I'm not sure.
>
> If you actually manage to figure out how to get that hooked up correclty,
> let me know ;)
>
> (Hint, it's doable, but you need additional components. There's a cheap
> way, and there's an easy way, and they are two *very* different ways...)
Looking at the micro-desktop schematic it seems Luke has this issue
well in hand. Christopher have you seen the micro-desktop schematic?
The VGA conversion is on page 3.
Luke, have you tested the D/A circuit on the micro-desktop board?
Only thing I would worry about is the hold time on the data lines. If
the A20 sets up the data quickly (relative to the pixel time) and
holds it until the next setup, we should be in good shape.
> Much easier suggestion: get a small LCD. *ANY* small LCD. Like a five or
> seven inch display at the largest. Raw panel, no driver board. Get the
> datasheet and a compatible connector. (If you source from eBay this is very
> easy; those are almost all commodity displays with available datasheets.)
> If it's a SMALL DISPLAY it *will* be RGBTTL, 90%+ of the time (I've seen
> one exception to this ever and it was in an off-brand portable DVD player).
> Wire it up. Wire it to the card connector. Add power. If you get a screen
> that works, you've done it right.
I think this is why Luke put the display signals on the EOMA68
standard in the RGBTTL format--to simplify the job of connecting to
LCD's. (I'm thinking of the laptop, tablet, gaming console, phone,
etc.)
From richard.wilbur at gmail.com Thu Mar 1 22:50:54 2018
From: richard.wilbur at gmail.com (Richard Wilbur)
Date: Thu, 1 Mar 2018 15:50:54 -0700
Subject: [Arm-netbook] Testing: GPIO
In-Reply-To:
References:
Message-ID:
On Thu, Mar 1, 2018 at 3:05 PM, Christopher Havel wrote:
> ...BTW, those SCL and SDA lines on a VGA connector are for a nifty signal
> coming from your monitor. It's called EDID and it's basically how every
> modern OS magically knows what to do with the monitor it wants to display
> on, regardless of the specs or origin of said monitor.
>
> If you've ever had a cheap VGA cable where all the pins are present on the
> connectors but those two lines are disconnected internally, you have
> experience with what happens when you eff with those wires. Best to leave
> them alone!
Christopher, you are quite correct about the usefullness of
untarnished VESA EDID. Turns out I've worked with it before and
respect its utility with respect to VGA/DVI/HDMI monitors.
We are simply talking about how to test the DS-113 EOMA68-A20
processor cards when they come to the end of the assembly line. In
that regard, our discussion is mainly about how to create a test
jig/fixture that has the most complete coverage of the signals
available on the EOMA68 interface and some of the possible use
scenarios. We also have an interest in time efficiency as a matter of
economy.
From laserhawk64 at gmail.com Thu Mar 1 23:12:24 2018
From: laserhawk64 at gmail.com (Christopher Havel)
Date: Thu, 1 Mar 2018 18:12:24 -0500
Subject: [Arm-netbook] Testing: GPIO
In-Reply-To:
References:
Message-ID:
I /designed/ that circuitry in the micro-desktop. I still have the paper
copy somewhere...
You can also do it with a dedicated DAC chip, which is the
easy-but-expensive way I hinted at.
But we aren't testing /that/ part -- the micro-desktop -- are we? If we're
testing the /card/, the card does not output anything remotely like VGA,
and, therefore, some kind of conversion is necessary in order to attach it
to a VGA cable as was being proposed in the email I replied to about that.
All you really need for this is a laptop PCMCIA or CardBus card cage, an
IDE cable or two, a couple 4051s and toggle switches on a slice of
perfboard, a 9v battery with connector and switch, and a cheap USB logic
analyzer attached to a laptop. You use the 4051s, switched manually, and
powered by the 9v battery, to act as input expanders for the logic
analyzer. Each 4015 turns one channel into eight and requires three "on-on"
switches -- with one "on" wired to +9v, one to ground, and the common to
the chip. You use the IDE cable for the wires ;) If you hook it up so that
you have one 4051 mux per logic analyzer channel, that'll give you 128 (!)
channels to switch with -- most USB logic analyzers, even the super cheap
ones, are 16-channel...
Heck, if you wanted to make the circuit "complicated" -- I could draw up
something that automatically iterated through the channels for you at the
press of a single button, switching at variable speed with a pot, a 555, a
resistor and cap, and a couple 4017s and 4051s. You'd only need /one/
channel for that -- so you could even use an o-scope there. Heck, I could
do it with that circuit and my old, old Tektronix 422...
I'm honestly surprised that this sort of idea hasn't been mentioned yet.
From richard.wilbur at gmail.com Fri Mar 2 00:03:55 2018
From: richard.wilbur at gmail.com (Richard Wilbur)
Date: Thu, 1 Mar 2018 17:03:55 -0700
Subject: [Arm-netbook] Testing: GPIO
In-Reply-To:
References:
Message-ID:
On Thu, Mar 1, 2018 at 4:12 PM, Christopher Havel wrote:
> I /designed/ that circuitry in the micro-desktop. I still have the paper
> copy somewhere...
Very nice!
> You can also do it with a dedicated DAC chip, which is the
> easy-but-expensive way I hinted at.
>
> But we aren't testing /that/ part -- the micro-desktop -- are we? If we're
> testing the /card/, the card does not output anything remotely like VGA,
> and, therefore, some kind of conversion is necessary in order to attach it
> to a VGA cable as was being proposed in the email I replied to about that.
We aren't planning to test the micro-desktop. The planning is for
tests of the card mounted in a micro-desktop case to use as a test
fixture. We are planning to use your good work on the micro-desktop
case to our advantage and connect the VGA cable to the micro-desktop
VGA connector in order to see that the EOMA68 RGBTTL (with EDID) works
as advertised!
> All you really need for this is a laptop PCMCIA or CardBus card cage, an
> IDE cable or two, a couple 4051s and toggle switches on a slice of
> perfboard, a 9v battery with connector and switch, and a cheap USB logic
> analyzer attached to a laptop. You use the 4051s, switched manually, and
> powered by the 9v battery, to act as input expanders for the logic
> analyzer. Each 4015 turns one channel into eight and requires three "on-on"
> switches -- with one "on" wired to +9v, one to ground, and the common to
> the chip. You use the IDE cable for the wires ;) If you hook it up so that
> you have one 4051 mux per logic analyzer channel, that'll give you 128 (!)
> channels to switch with -- most USB logic analyzers, even the super cheap
> ones, are 16-channel...
>
> Heck, if you wanted to make the circuit "complicated" -- I could draw up
> something that automatically iterated through the channels for you at the
> press of a single button, switching at variable speed with a pot, a 555, a
> resistor and cap, and a couple 4017s and 4051s. You'd only need /one/
> channel for that -- so you could even use an o-scope there. Heck, I could
> do it with that circuit and my old, old Tektronix 422...
>
> I'm honestly surprised that this sort of idea hasn't been mentioned yet.
That is a cool way to set up a very wide logic analyzer. We were
planning to use a little specialized hardware and less elbow grease to
make our test fixture:
* USB devices connected to the micro-desktop case USB ports,
* SD peripheral connected to the micro SD slot,
* VGA monitor connected to the VGA connector,
* serial terminal connected to the UART pins in expansion header
From laserhawk64 at gmail.com Fri Mar 2 00:10:15 2018
From: laserhawk64 at gmail.com (Christopher Havel)
Date: Thu, 1 Mar 2018 19:10:15 -0500
Subject: [Arm-netbook] Testing: GPIO
In-Reply-To:
References:
Message-ID:
Posting from my phone while making dinner, so forgive that it's a top-post
plz.
Testing via the micro desktop works as long as you've got a known good
micro desktop and your ports haven't won through. I think the 4051 idea
might be a little better - I've worn out USB ports before, just from using
them - ask me sometime about my mother's old VAIO laptop and how it
ultimately died... the only thing in my test rig to wear out is the card
cage...
But, I'm not in charge, so I'll defer.
On Mar 1, 2018 7:04 PM, "Richard Wilbur" wrote:
> On Thu, Mar 1, 2018 at 4:12 PM, Christopher Havel
> wrote:
> > I /designed/ that circuitry in the micro-desktop. I still have the paper
> > copy somewhere...
>
> Very nice!
>
> > You can also do it with a dedicated DAC chip, which is the
> > easy-but-expensive way I hinted at.
> >
> > But we aren't testing /that/ part -- the micro-desktop -- are we? If
> we're
> > testing the /card/, the card does not output anything remotely like VGA,
> > and, therefore, some kind of conversion is necessary in order to attach
> it
> > to a VGA cable as was being proposed in the email I replied to about
> that.
>
> We aren't planning to test the micro-desktop. The planning is for
> tests of the card mounted in a micro-desktop case to use as a test
> fixture. We are planning to use your good work on the micro-desktop
> case to our advantage and connect the VGA cable to the micro-desktop
> VGA connector in order to see that the EOMA68 RGBTTL (with EDID) works
> as advertised!
>
> > All you really need for this is a laptop PCMCIA or CardBus card cage, an
> > IDE cable or two, a couple 4051s and toggle switches on a slice of
> > perfboard, a 9v battery with connector and switch, and a cheap USB logic
> > analyzer attached to a laptop. You use the 4051s, switched manually, and
> > powered by the 9v battery, to act as input expanders for the logic
> > analyzer. Each 4015 turns one channel into eight and requires three
> "on-on"
> > switches -- with one "on" wired to +9v, one to ground, and the common to
> > the chip. You use the IDE cable for the wires ;) If you hook it up so
> that
> > you have one 4051 mux per logic analyzer channel, that'll give you 128
> (!)
> > channels to switch with -- most USB logic analyzers, even the super cheap
> > ones, are 16-channel...
> >
> > Heck, if you wanted to make the circuit "complicated" -- I could draw up
> > something that automatically iterated through the channels for you at the
> > press of a single button, switching at variable speed with a pot, a 555,
> a
> > resistor and cap, and a couple 4017s and 4051s. You'd only need /one/
> > channel for that -- so you could even use an o-scope there. Heck, I could
> > do it with that circuit and my old, old Tektronix 422...
> >
> > I'm honestly surprised that this sort of idea hasn't been mentioned yet.
>
> That is a cool way to set up a very wide logic analyzer. We were
> planning to use a little specialized hardware and less elbow grease to
> make our test fixture:
> * USB devices connected to the micro-desktop case USB ports,
> * SD peripheral connected to the micro SD slot,
> * VGA monitor connected to the VGA connector,
> * serial terminal connected to the UART pins in expansion header
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk
From richard.wilbur at gmail.com Fri Mar 2 00:19:44 2018
From: richard.wilbur at gmail.com (Richard Wilbur)
Date: Thu, 1 Mar 2018 17:19:44 -0700
Subject: [Arm-netbook] Testing: GPIO
In-Reply-To:
References: