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:

Message-ID: On Thu, Mar 1, 2018 at 5:10 PM, Christopher Havel wrote: > 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. You make very good points about connector fatigue. I was planning to leave everything connected and only install/remove the EOMA68 card from the micro-desktop case. That works as long as we don't need to test hot-plugging anything. To my knowledge we figured the hot-plug capability would likely be conferred by the applicable standard and thus were designing a basic functionality test. (Incidentally I have a dead VAIO laptop in which the power jack center pin broke. I really need to get that ordered and replaced.;>) From laserhawk64 at gmail.com Fri Mar 2 00:23:31 2018 From: laserhawk64 at gmail.com (Christopher Havel) Date: Thu, 1 Mar 2018 19:23:31 -0500 Subject: [Arm-netbook] Testing: GPIO In-Reply-To: References:

Message-ID: Be careful... it was the replacing of the two ports on that old VGN-S360 that killed it... VAIOs are well known in repair circles for dying of heatstroke from even the slightest rework (and I was duly warned)... if it's a modular jack (on a cable, so no soldering), you'll be fine. If you need an iron... buy a board, not a port. Trust me. On Mar 1, 2018 7:20 PM, "Richard Wilbur" wrote: > On Thu, Mar 1, 2018 at 5:10 PM, Christopher Havel > wrote: > > 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. > > You make very good points about connector fatigue. I was planning to > leave everything connected and only install/remove the EOMA68 card > from the micro-desktop case. That works as long as we don't need to > test hot-plugging anything. To my knowledge we figured the hot-plug > capability would likely be conferred by the applicable standard and > thus were designing a basic functionality test. > > (Incidentally I have a dead VAIO laptop in which the power jack center > pin broke. I really need to get that ordered and replaced.;>) > > _______________________________________________ > 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 lkcl at lkcl.net Fri Mar 2 01:57:20 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 2 Mar 2018 01:57:20 +0000 Subject: [Arm-netbook] Testing: GPIO In-Reply-To: References:

Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Mar 2, 2018 at 12:10 AM, Christopher Havel wrote: > Posting from my phone while making dinner, so forgive that it's a top-post > plz. done but not for using the phone instead of enjoying dinner! :) > Testing via the micro desktop works as long as you've got a known good > micro desktop and your ports haven't won through. two separate tests strictly speaking needed, one is of Card(s), the other is of Micro-Desktop(s), one way to do that: known-good MD tests cards. known-good Card tests MDs. l. From lkcl at lkcl.net Fri Mar 2 03:30:14 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 2 Mar 2018 03:30:14 +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 9:46 PM, Richard Wilbur wrote: > 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. yep, pretty much... with one slight fly in the ointment: the SCL and SDA lines are straight GPIO and will need a bit-banging I2C linux kernel driver. once that's configured, doing i2cdetect _should_ be enough to test the circuit, although scanning the data and running read-edid on it would be awesome and amazing: it would mean being able to *really* do proper VESA detection. l. From lkcl at lkcl.net Fri Mar 2 03:31:31 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 2 Mar 2018 03:31:31 +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 10: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 reason i brought those out is just in case someone decided they wanted to use them as plain GPIO. > The other option to accommodate all our GPIO goodness would be to > replace J5 (2x10 header) with a 2x11 or 2x12 header yep. > 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). yes. l. From lkcl at lkcl.net Fri Mar 2 03:40:01 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 2 Mar 2018 03:40:01 +0000 Subject: [Arm-netbook] Testing: GPIO In-Reply-To: References:

Message-ID: On Thu, Mar 1, 2018 at 10:42 PM, Richard Wilbur wrote: > Luke, have you tested the D/A circuit on the micro-desktop board? yep it works great up to 1024x768. i haven't yet been able to get it to sync at anything greater than that, because you have to manually convert the signals into A20 timings... and of course if you can't read the EDID data you don't know *exactly* what the settings are in the first place for any given monitor. 1024x768, being a common VESA standard, has worked consistently on every monitor i've tried. > 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. sigh yeah i thought about that... using buffer ICs with a "hold", and linking up the clock line to it.... never got round to it. i'd prefer to just skip the entire circuit and use a TFP410 (or maybe it's a TFP401a), or a Chrontel RGB/TTL to VGA converter IC. CH7036 i think it is. >> 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.) yyup. exactly. remember, you can't do more than one interface on any given set of pins, so i had to pick one (RGB/TTL or LVDS or MIPI or eDP), that then means you have to have a conversion IC in-place on the Card if a particular SoC doesn't *have* that interface... and many of the lower-cost SoCs don't because they're not part of the MIPI or DisplayPort cartel(s).... ... and even if you had LVDS, the cost on the other side (Housing side) of having an LVDS-to-RGB/TTL converter is so high relative to the cost of the LCD itself that companies would rebel and not bother with the standard at all. so, bizarrely, RGB/TTL, by being both "free" and also unencumbered by patents *and* by being lowest-common-denominator, wins out on all fronts. except for the fact that you need a 125mhz clock-rate for 1920x1080 at 60fps, which is a bit... high. but hey. l. From lkcl at lkcl.net Fri Mar 2 10:07:06 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 2 Mar 2018 10:07:06 +0000 Subject: [Arm-netbook] Testing: GPIO In-Reply-To: References:

Message-ID: btw i'm tempted to suggest treating the SPI pins as straight GPIO. if they can do 0 and 1 (input and output) then they're not short-circuited and/or disconnected and that's... good enough. l. From richard.wilbur at gmail.com Fri Mar 2 21:20:17 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 2 Mar 2018 14:20:17 -0700 Subject: [Arm-netbook] Testing: GPIO In-Reply-To: References: