Re: [Arm-netbook] update to EOMA68 specification [was Re: 5" LCD resolution 800x480 working for EOMA but color problems may exist because of miswire]
this is not a miswire. the specification has now changed to reflect what cannot now be changed. l.
On Sun, Nov 10, 2013 at 1:15 PM, luke.leighton luke.leighton@gmail.com wrote:
On Tue, Nov 5, 2013 at 12:43 AM, joem joem@martindale-electric.co.uk wrote:
Hi,
5" LCD resolution 800x480 working for EOMA. Details here http://www.gplsquared.com/eoma_boot/eoma_boot.html#eoma_with_5inch_lcd These displays are about $16 from Aliexpress: http://www.aliexpress.com/item/5inch-5-TFT-LCD-LCM-RGB-800-480-Display-TOUCH...
I still notice a problem with color - Red and Blue appear to be swapped.
ok. the specification's going to have to change. we cannot modify the CPU Card, so the spec has to be changed to match the card. what a pain.
l.
:this is not a miswire. the specification has now changed to reflect :what cannot now be changed.
5" LCD resolution 800x480 working for EOMA. Details here http://www.gplsquared.com/eoma_boot/eoma_boot.html#eoma_with_5inch_lcd These displays are about $16 from Aliexpress: http://www.aliexpress.com/item/5inch-5-TFT-LCD-LCM-RGB-800-480-Display-TOUCH...
I still notice a problem with color - Red and Blue appear to be swapped.
ok. the specification's going to have to change. we cannot modify the CPU Card, so the spec has to be changed to match the card. what a pain.
Hmmmppp...... The is another outstanding issue that needs resolving before the next batch goes into production - this time to do with the RS232 RX line. When connected, the entire board is able to power up through the RX line. The cubieboard1,2 and iteaduino plus and EOMA-A20 boards all have same defect because I assume all of them were designed and tested by the same engineering team from Wits with no peer review input onto the process.
If you are doing another batch, make sure the CPU board RX line doesn't power up the entire board through that line. They need to put a serial resistor in series or a FET pair to sufficiently isolate the RX line. The same note applies to anyone else using designs that originated with Allwinner/Wits.
On Sun, Nov 10, 2013 at 4:19 PM, joem joem@martindale-electric.co.uk wrote:
:this is not a miswire. the specification has now changed to reflect :what cannot now be changed.
5" LCD resolution 800x480 working for EOMA. Details here http://www.gplsquared.com/eoma_boot/eoma_boot.html#eoma_with_5inch_lcd These displays are about $16 from Aliexpress: http://www.aliexpress.com/item/5inch-5-TFT-LCD-LCM-RGB-800-480-Display-TOUCH...
I still notice a problem with color - Red and Blue appear to be swapped.
ok. the specification's going to have to change. we cannot modify the CPU Card, so the spec has to be changed to match the card. what a pain.
Hmmmppp...... The is another outstanding issue that needs resolving before the next batch goes into production - this time to do with the RS232 RX line. When connected, the entire board is able to power up through the RX line. The cubieboard1,2 and iteaduino plus and EOMA-A20 boards all have same defect because I assume all of them were designed and tested by the same engineering team from Wits with no peer review input onto the process.
... well, the schematics for the EVB and also the schematics for the GPL-licensed EOMA68-A10/20 CPU Card have been publicly available for nearly two years. unfortunately we've not had you around until recently joe... *rueful*...
If you are doing another batch, make sure the CPU board RX line doesn't power up the entire board through that line.
not going to happen, for exactly the same reason that the RGB/TTL lines are not going to be modified: it's too late. the PCB design went out to the factory over two months ago when the first 30 samples were made, and the gerbers cannot now be changed. a) it would make the factories nervous (no way we're doing that) b) someone needs to come up with another $2k (or so) to do another round of samples c) we would need to delay production (no way we're doing that, not right before christmas) d) the PCB factory is *far* too busy to redo the gerbers right just before christmas production.
so - no. no changes to the CPU Card.
instead, the spec therefore has to reflect that and require that the I/O boards add in suitable compensating circuitry instead. none of the I/O boards have gone into production yet, so that's the only remaining place where the flexibility and changes can go.
l.
Hmmmppp...... The is another outstanding issue that needs resolving before the next batch goes into production - this time to do with the RS232 RX line. When connected, the entire board is able to power up through the RX line. The cubieboard1,2 and iteaduino plus and EOMA-A20 boards all have same defect because I assume all of them were designed and tested by the same engineering team from Wits with no peer review input onto the process.
| ... well, the schematics for the EVB and also the schematics for the |GPL-licensed EOMA68-A10/20 CPU Card have been publicly available for |nearly two years. unfortunately we've not had you around until |recently joe... *rueful*...
If you are doing another batch, make sure the CPU board RX line doesn't power up the entire board through that line.
| not going to happen, for exactly the same reason that the RGB/TTL |lines are not going to be modified: it's too late. the PCB design |went out to the factory over two months ago when the first 30 samples |were made, and the gerbers cannot now be changed. a) it would make |the factories nervous (no way we're doing that) b) someone needs to
Don't believe in such things. Most good factories are only too glad to help down to the wire. I've changed stuff after 1st day of production. The most likely thing they do is charge a little extra or amortize it into the next production run. Good companies know it is all part of the deal when first starting up production.
|come up with another $2k (or so) to do another round of samples c) we |would need to delay production (no way we're doing that, not right |before christmas) d) the PCB factory is *far* too busy to redo the |gerbers right just before christmas production. | | so - no. no changes to the CPU Card.
If its gone to production, it not end of world. Just more revisions are due next batch. The revision to fix RX line problem will likely be transparent to end user.
| instead, the spec therefore has to reflect that and require that the |I/O boards add in suitable compensating circuitry instead. none of |the I/O boards have gone into production yet, so that's the only |remaining place where the flexibility and changes can go.
That perfectly OK - as the end user doesn't loose anything.
Learn from this - always make in batches of 10 to iron out problems. And keep making them until done. Also have them for sale for anyone that wants alpha hardware. Most hardened developers only want the alpha hardware. You can always refund them if it don't work, or send them free working hardware to compensate them later.
On Sun, Nov 10, 2013 at 8:16 PM, joem joem@martindale-electric.co.uk wrote:
Hmmmppp...... The is another outstanding issue that needs resolving before the next batch goes into production - this time to do with the RS232 RX line. When connected, the entire board is able to power up through the RX line. The cubieboard1,2 and iteaduino plus and EOMA-A20 boards all have same defect because I assume all of them were designed and tested by the same engineering team from Wits with no peer review input onto the process.
| ... well, the schematics for the EVB and also the schematics for the |GPL-licensed EOMA68-A10/20 CPU Card have been publicly available for |nearly two years. unfortunately we've not had you around until |recently joe... *rueful*...
If you are doing another batch, make sure the CPU board RX line doesn't power up the entire board through that line.
| not going to happen, for exactly the same reason that the RGB/TTL |lines are not going to be modified: it's too late. the PCB design |went out to the factory over two months ago when the first 30 samples |were made, and the gerbers cannot now be changed. a) it would make |the factories nervous (no way we're doing that) b) someone needs to
Don't believe in such things. Most good factories are only too glad to help down to the wire. I've changed stuff after 1st day of production.
joe you're not listening. the scale of the production facilities we're dealing with is enormous. at their *current* capacity our client is capable of making *TWENTY MILLION* CPU Cards PER WEEK. there is flat-out absolutely zero chance that we will be telling them "sorry we made a mistake, we have to change what we're delivering". our reputation would be immediately destroyed.
| so - no. no changes to the CPU Card.
If its gone to production, it not end of world.
joe - you're not listening. this is the first CPU Card. it's a MODULAR system. it's too late. there will be no changes.
if however this was a single-board system you would be absolutely right. it would be perfectly reasonable to just go and redesign the next release of the PCB.
... but this isn't a single-board system, is it?
Just more revisions are due next batch. The revision to fix RX line problem will likely be transparent to end user.
no it will not. think it through. there's due to be a batch of 2500 CPU Cards followed by another batch of 10k. these two batches are the ones that cannot be modified.
what then happens if any one of those 12500 CPU Cards is plugged into an I/O board that doesn't have the RX line-protection?
the venn diagram is as follows:
cpu card Rx-fixed IO board Rx-fixed combination OK n n N y n Y n y Y y y Y
can you see, using karnaugh mapping, that "fixing the CPU Card" is completely and totally irrelevant? the CPU Cards *have* to go out without UART-RX being fixed [for reasons already stated]. the I/O Boards therefore *have* to go out with UART-RX hardware fixes.
therefore "fixing the CPU Card" *afterwards* is not only completely irrelevant but is also *dangerous* because it will give I/O board developers the false impression that they do not need to take care of the problem.
and if that ever happens they're f*****d.
so it has to be the way that i've said it has to be, for the reasons that i've already stated that it has to be. i've looked at all the options: this is the only option. therefore we go with it.
Learn from this - always make in batches of 10 to iron out problems.
the circumstances are different. 30 samples or 10 samples, it doesn't make any difference: one of those went to our client. due to the number of fuck-ups that have already occurred (from using Wits Tech) there was absolutely no way unless it was yet another serious fuckup that we could say "i'm sorry, we have to make some minor changes".
if we did not have such large clients, or if we did not have a modular system, matters would be entirely different.
so - there's a solution: that's what we go with for the next 10 years. end of story.
l.
"luke.leighton" luke.leighton@gmail.com writes: ...
instead, the spec therefore has to reflect that and require that the I/O boards add in suitable compensating circuitry instead. none of the I/O boards have gone into production yet, so that's the only remaining place where the flexibility and changes can go.
It strikes me that the I/O board is actually the right place for that protective circuitry anyway.
Putting such circuitry on the CPU card consumes space where space is at a premium, and for applications where the RS232 is superfluous, you would be forced to pay for components you don't need.
Now that it's defined as going on the I/O board, people that don't need RS232 can simply leave those pins unconnected and they'll have fulfilled the requirements to protect the pin from power.
Cheers, Phil.
P.S. It just occurred to me that even where it had been decided not to bother with RS232 on a device, if one discovered a need to access it one could have a pass-through board that would stick out of the side of the device, and have a socket for a CPU card, and expose the RS232 lines (via relevant protection as per standard), with all other connections going to the PCMCIA plug at the other end of the card.
On Mon, Nov 11, 2013 at 12:19 AM, joem joem@martindale-electric.co.uk wrote:
:this is not a miswire. the specification has now changed to reflect :what cannot now be changed.
5" LCD resolution 800x480 working for EOMA. Details here http://www.gplsquared.com/eoma_boot/eoma_boot.html#eoma_with_5inch_lcd These displays are about $16 from Aliexpress: http://www.aliexpress.com/item/5inch-5-TFT-LCD-LCM-RGB-800-480-Display-TOUCH...
I still notice a problem with color - Red and Blue appear to be swapped.
ok. the specification's going to have to change. we cannot modify the CPU Card, so the spec has to be changed to match the card. what a pain.
Hmmmppp...... The is another outstanding issue that needs resolving before the next batch goes into production - this time to do with the RS232 RX line. When connected, the entire board is able to power up through the RX line. The cubieboard1,2 and iteaduino plus and EOMA-A20 boards all have same defect because I assume all of them were designed and tested by the same engineering team from Wits with no peer review input onto the process.
The cubieboard1,2 are not designed by wits. All the allwinner boards including wits are following the allwinner reference design.
If you are doing another batch, make sure the CPU board RX line doesn't power up the entire board through that line. They need to put a serial resistor in series or a FET pair to sufficiently isolate the RX line. The same note applies to anyone else using designs that originated with Allwinner/Wits.
we also have the RX line powering the board problem on our rk3188 board. we use this ttl to use cable http://store.r0ck.me/products/ttl-to-usb-serial-cable and found that the serial port of 3188 is damaged when plugging and unplugging the power quickly. Further investigation we found that the ttl to usb cable is 5V and the voltage on rx can be as high as 4V. No problem using this cable on A10/A20 but the voltage tolerance for 3188 is less since it's 28nm made.
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, 2013-11-11 at 12:43 +0800, Tom Cubie wrote:
On Mon, Nov 11, 2013 at 12:19 AM, joem joem@martindale-electric.co.uk wrote:
:this is not a miswire. the specification has now changed to reflect :what cannot now be changed.
5" LCD resolution 800x480 working for EOMA. Details here http://www.gplsquared.com/eoma_boot/eoma_boot.html#eoma_with_5inch_lcd These displays are about $16 from Aliexpress: http://www.aliexpress.com/item/5inch-5-TFT-LCD-LCM-RGB-800-480-Display-TOUCH...
I still notice a problem with color - Red and Blue appear to be swapped.
ok. the specification's going to have to change. we cannot modify the CPU Card, so the spec has to be changed to match the card. what a pain.
Hmmmppp...... The is another outstanding issue that needs resolving before the next batch goes into production - this time to do with the RS232 RX line. When connected, the entire board is able to power up through the RX line. The cubieboard1,2 and iteaduino plus and EOMA-A20 boards all have same defect because I assume all of them were designed and tested by the same engineering team from Wits with no peer review input onto the process.
The cubieboard1,2 are not designed by wits. All the allwinner boards including wits are following the allwinner reference design.
Hmm.. MK802 also infected - so I guess everyone is infected.
I put up suggestion for UART-RX repair - EOMAs and boards where internal 3.3V is accessible: http://www.gplsquared.com/eoma_boot/eoma_boot.html#uart_repair
Turl in freenode #linux-sunxi suggests olimex solve it with their later boards.
If you are doing another batch, make sure the CPU board RX line doesn't power up the entire board through that line. They need to put a serial resistor in series or a FET pair to sufficiently isolate the RX line. The same note applies to anyone else using designs that originated with Allwinner/Wits.
we also have the RX line powering the board problem on our rk3188 board. we use this ttl to use cable http://store.r0ck.me/products/ttl-to-usb-serial-cable and found that the serial port of 3188 is damaged when plugging and unplugging the power quickly. Further investigation we found that the ttl to usb cable is 5V and the voltage on rx can be as high as 4V. No problem using this cable on A10/A20 but the voltage tolerance for 3188 is less since it's 28nm made.
On Mon, Nov 11, 2013 at 11:07 AM, joem joem@martindale-electric.co.uk wrote:
On Mon, 2013-11-11 at 12:43 +0800, Tom Cubie wrote:
On Mon, Nov 11, 2013 at 12:19 AM, joem joem@martindale-electric.co.uk wrote:
:this is not a miswire. the specification has now changed to reflect :what cannot now be changed.
5" LCD resolution 800x480 working for EOMA. Details here http://www.gplsquared.com/eoma_boot/eoma_boot.html#eoma_with_5inch_lcd These displays are about $16 from Aliexpress: http://www.aliexpress.com/item/5inch-5-TFT-LCD-LCM-RGB-800-480-Display-TOUCH...
I still notice a problem with color - Red and Blue appear to be swapped.
ok. the specification's going to have to change. we cannot modify the CPU Card, so the spec has to be changed to match the card. what a pain.
Hmmmppp...... The is another outstanding issue that needs resolving before the next batch goes into production - this time to do with the RS232 RX line. When connected, the entire board is able to power up through the RX line. The cubieboard1,2 and iteaduino plus and EOMA-A20 boards all have same defect because I assume all of them were designed and tested by the same engineering team from Wits with no peer review input onto the process.
The cubieboard1,2 are not designed by wits. All the allwinner boards including wits are following the allwinner reference design.
Hmm.. MK802 also infected - so I guess everyone is infected.
yes. and the iMX6 is also damageable, and a hell of a lot of other SoCs.
I put up suggestion for UART-RX repair - EOMAs and boards where internal 3.3V is accessible: http://www.gplsquared.com/eoma_boot/eoma_boot.html#uart_repair
oo - magic: a circuit diagram. joe if it's ok i'm going to add that image to the elinux.org wiki ok?
l.
Hmm.. MK802 also infected - so I guess everyone is infected.
yes. and the iMX6 is also damageable, and a hell of a lot of other SoCs.
I put up suggestion for UART-RX repair - EOMAs and boards where internal 3.3V is accessible: http://www.gplsquared.com/eoma_boot/eoma_boot.html#uart_repair
oo - magic: a circuit diagram. joe if it's ok i'm going to add that image to the elinux.org wiki ok?
Yes please - 100% open sourced :)
arm-netbook@lists.phcomp.co.uk
-
joem -
luke.leighton -
Philip Hands -
Tom Cubie