i'm giving serious consideration, even at this late phase, to adding SD/MMC to EOMA68 by way of the GPIO pins as a multiplexing option. this would not have any impact on the EOMA68-A20 CPU Card: in fact, the only reason this can be considered at all is because the pins *happen* to be multiplexed as SD/MMC and GPIO *anyway*.
this would also happen to give EOMA68 an SPI port as well.
the idea came to me because it's something that's been forced on EOMA-26 due to the small number of pins (26) on EOMA-26.
after looking at dozens of SoCs i don't think i've seen a single one these days which *only* has a [non-multiplexed] SD/MMC port. even if there was one that did (at an affordable price), a cross-bar buffer IC would take care of that.
does anyone have any objections, and/or can think of any gotchas which would prevent SD/MMC from being added as a non-optional multiplexed option to EOMA-68?
l.
Sent from my iPhone
On Dec 23, 2013, at 3:48 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
i'm giving serious consideration, even at this late phase, to adding SD/MMC to EOMA68 by way of the GPIO pins as a multiplexing option. this would not have any impact on the EOMA68-A20 CPU Card: in fact, the only reason this can be considered at all is because the pins *happen* to be multiplexed as SD/MMC and GPIO *anyway*.
does anyone have any objections, and/or can think of any gotchas which would prevent SD/MMC from being added as a non-optional multiplexed option to EOMA-68?
How many of the 8 GPIO would essentially be used? (I presume 6?)
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Mon, Dec 23, 2013 at 10:08 PM, Christopher Thomas christopher@firemothindustries.com wrote:
Sent from my iPhone
On Dec 23, 2013, at 3:48 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
i'm giving serious consideration, even at this late phase, to adding SD/MMC to EOMA68 by way of the GPIO pins as a multiplexing option. this would not have any impact on the EOMA68-A20 CPU Card: in fact, the only reason this can be considered at all is because the pins *happen* to be multiplexed as SD/MMC and GPIO *anyway*.
does anyone have any objections, and/or can think of any gotchas which would prevent SD/MMC from being added as a non-optional multiplexed option to EOMA-68?
How many of the 8 GPIO would essentially be used? (I presume 6?)
yes, 6. it's no change - literally - of the EOMA68-A20 CPU Card. the pinouts happen already to be multiplexed to SD/MMC (just at present in "non-EOMA68-compliant" mode). the change would be "it is now mandatory that the following pins be multiplexed on GPIO [1]:
GPIO-0: SD0-D3 GPIO-1: SD0-D2 GPIO-4: SD0-CMD GPIO-5: SD0-CLK GPIO-6: SD0-D0 GPIO-7: SD0-D1
l.
[1] from http://rhombus-tech.net/allwinner_a10/orders/ - the section on "Features". these pins were originally selected because they have a secondary multiplex functional mapping to JTAG, but also because of the *tertiary* multiplex functional mapping to SD/MMC.
On Mon, 2013-12-23 at 22:16 +0000, Luke Kenneth Casson Leighton wrote:
On Mon, Dec 23, 2013 at 10:08 PM, Christopher Thomas christopher@firemothindustries.com wrote:
Sent from my iPhone
On Dec 23, 2013, at 3:48 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
i'm giving serious consideration, even at this late phase, to adding SD/MMC to EOMA68 by way of the GPIO pins as a multiplexing option. this would not have any impact on the EOMA68-A20 CPU Card: in fact, the only reason this can be considered at all is because the pins *happen* to be multiplexed as SD/MMC and GPIO *anyway*.
does anyone have any objections, and/or can think of any gotchas which would prevent SD/MMC from being added as a non-optional multiplexed option to EOMA-68?
How many of the 8 GPIO would essentially be used? (I presume 6?)
yes, 6. it's no change - literally - of the EOMA68-A20 CPU Card. the pinouts happen already to be multiplexed to SD/MMC (just at present in "non-EOMA68-compliant" mode). the change would be "it is now mandatory that the following pins be multiplexed on GPIO [1]:
GPIO-0: SD0-D3 GPIO-1: SD0-D2 GPIO-4: SD0-CMD GPIO-5: SD0-CLK GPIO-6: SD0-D0 GPIO-7: SD0-D1
l.
[1] from http://rhombus-tech.net/allwinner_a10/orders/ - the section on "Features". these pins were originally selected because they have a secondary multiplex functional mapping to JTAG, but also because of the *tertiary* multiplex functional mapping to SD/MMC.
My thoughts were to add an high pin count FPC somewhere to get more pins out than limit the box to 68 pins. This problem is going to hit the box a lot of the time.
(My interest is embedded applications - so higher pin count is more flexibility.)
On Tue, Dec 24, 2013 at 8:21 AM, joem joem@martindale-electric.co.uk wrote:
On Mon, 2013-12-23 at 22:16 +0000, Luke Kenneth Casson Leighton wrote:
On Mon, Dec 23, 2013 at 10:08 PM, Christopher Thomas christopher@firemothindustries.com wrote:
Sent from my iPhone
On Dec 23, 2013, at 3:48 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
i'm giving serious consideration, even at this late phase, to adding SD/MMC to EOMA68 by way of the GPIO pins as a multiplexing option. this would not have any impact on the EOMA68-A20 CPU Card: in fact, the only reason this can be considered at all is because the pins *happen* to be multiplexed as SD/MMC and GPIO *anyway*.
does anyone have any objections, and/or can think of any gotchas which would prevent SD/MMC from being added as a non-optional multiplexed option to EOMA-68?
How many of the 8 GPIO would essentially be used? (I presume 6?)
yes, 6. it's no change - literally - of the EOMA68-A20 CPU Card. the pinouts happen already to be multiplexed to SD/MMC (just at present in "non-EOMA68-compliant" mode). the change would be "it is now mandatory that the following pins be multiplexed on GPIO [1]:
GPIO-0: SD0-D3 GPIO-1: SD0-D2 GPIO-4: SD0-CMD GPIO-5: SD0-CLK GPIO-6: SD0-D0 GPIO-7: SD0-D1
l.
[1] from http://rhombus-tech.net/allwinner_a10/orders/ - the section on "Features". these pins were originally selected because they have a secondary multiplex functional mapping to JTAG, but also because of the *tertiary* multiplex functional mapping to SD/MMC.
My thoughts were to add an high pin count FPC somewhere to get more pins out than limit the box to 68 pins.
next revision. we need to sell units first. or someone needs to provide the $10k NREs to be able to have the first EOMA68-A20 CPU card layout completely redesigned. but even then, an FPC is not going to be part of the EOMA68 specification because the EOMA68 specification is a mass-volume specification where the units are sold with a sealed metal shield around them.
l.
My thoughts were to add an high pin count FPC somewhere to get more pins out than limit the box to 68 pins.
next revision. we need to sell units first. or someone needs to provide the $10k NREs to be able to have the first EOMA68-A20 CPU card layout completely redesigned. but even then, an FPC is not going to be part of the EOMA68 specification because the EOMA68 specification is a mass-volume specification where the units are sold with a sealed metal shield around them.
What I notice was that the HDMI end has a gap that will allow an FPC flat cable to be fitted through the gap. Careful design needed though - tight squeeze to get access to the ears of the FPC connector to allow cable to be connected and disconnected without having to open the case.
The alternative is an FPC positioned at 90 degrees which forces the case to be opened for fitting. A flexible PCB with 90 degree tracks would be the way to connect into the EOMA, and only embedded engineer would do it.
A third alternative is to have the PCMCIA case made with a laser cut slot to allow the FPC cable to be connected. But that goes against the idea of a well sealed box.
joe could you please keep this discussion on topic and limit it to what the subject line says, thank you. regarding what you've suggested: that will involve at least $6k NREs for the tooling. it also will not be part of the EOMA68 standard. an individual board however in non-EOMA68-compliance mode could have this done.
now - do you have any input at all on what the subject-line is about? much appreciated.
l.
On Tue, Dec 24, 2013 at 12:07 PM, joem joem@martindale-electric.co.uk wrote:
My thoughts were to add an high pin count FPC somewhere to get more pins out than limit the box to 68 pins.
next revision. we need to sell units first. or someone needs to provide the $10k NREs to be able to have the first EOMA68-A20 CPU card layout completely redesigned. but even then, an FPC is not going to be part of the EOMA68 specification because the EOMA68 specification is a mass-volume specification where the units are sold with a sealed metal shield around them.
What I notice was that the HDMI end has a gap that will allow an FPC flat cable to be fitted through the gap. Careful design needed though - tight squeeze to get access to the ears of the FPC connector to allow cable to be connected and disconnected without having to open the case.
The alternative is an FPC positioned at 90 degrees which forces the case to be opened for fitting. A flexible PCB with 90 degree tracks would be the way to connect into the EOMA, and only embedded engineer would do it.
A third alternative is to have the PCMCIA case made with a laser cut slot to allow the FPC cable to be connected. But that goes against the idea of a well sealed box.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Tue, Dec 24, 2013 at 1:33 PM, joem joem@martindale-electric.co.uk wrote:
now - do you have any input at all on what the subject-line is about? much appreciated.
Anything that improves the overall number of pins, even multiplexed is a good thing.
thanks joe. now the only thing to resolve is whether the A20's SD/MMC can do SPI. it's in the spec [of SD/MMC] but i really need proper confirmation. then it will be possible to say that the EOMA68 specification supports SD/MMC and SPI.
l.
arm-netbook@lists.phcomp.co.uk
-
Christopher Thomas -
joem -
Luke Kenneth Casson Leighton