oh that was quick, mike :) --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Jan 8, 2018 at 8:29 AM, mike.valk@gmail.com mike.valk@gmail.com wrote:
https://www.crowdsupply.com/eoma68/micro-desktop/updates/eoma68-a20-2-7-5-ge...
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
does it make sense before mass produce, make i.e 5 pcs and test?
I understand PCB have been tested already, there is Chinese NT coming and most certainly all is ok but still!
On 8 January 2018 at 09:31, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
oh that was quick, mike :)
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Jan 8, 2018 at 8:29 AM, mike.valk@gmail.com mike.valk@gmail.com wrote:
eoma68-a20-2-7-5-gerbers-off-to-factory-thank-you-to- everyone-for-the-sponsorship
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
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
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Jan 8, 2018 at 9:08 AM, Hrvoje Lasic lasich@gmail.com wrote:
does it make sense before mass produce, make i.e 5 pcs and test?
question. would it be better to make 1000, only to discover that there's a fatal undetected design flaw?
I understand PCB have been tested already,
2.7.4 - which is COMPLETELY different layout from 2.7.5 - has been tested.
2.7.5 has not.
even one track wrong - especially if it is in the middle layers - can result in a fatal error. that's ONE change!!
on the original DS113 board from 4(!) years ago, the person doing the layout FAILED to run DRC before sending it to production. he had laid a track that crossed over a pad. it was a pretty damn obvious mistake.
we paid USD 10,000 to that team.
l.
agree on your points.
did you ever think about in investing in small PNP machine (or just small oven plus some hand tools), like being able to produce small batch in house and test it qucikly?
do you have any idea how reliable www.openpnp.org project is currently, for example to meet your specs on board with soem available hardware?
On 8 January 2018 at 10:15, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Jan 8, 2018 at 9:08 AM, Hrvoje Lasic lasich@gmail.com wrote:
does it make sense before mass produce, make i.e 5 pcs and test?
question. would it be better to make 1000, only to discover that there's a fatal undetected design flaw?
I understand PCB have been tested already,
2.7.4 - which is COMPLETELY different layout from 2.7.5 - has been tested.
2.7.5 has not.
even one track wrong - especially if it is in the middle layers - can result in a fatal error. that's ONE change!!
on the original DS113 board from 4(!) years ago, the person doing the layout FAILED to run DRC before sending it to production. he had laid a track that crossed over a pad. it was a pretty damn obvious mistake.
we paid USD 10,000 to that team.
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, Jan 8, 2018 at 9:32 AM, Hrvoje Lasic lasich@gmail.com wrote:
agree on your points.
did you ever think about in investing in small PNP machine (or just small oven plus some hand tools), like being able to produce small batch in house and test it qucikly?
yehyeh, i did - at one point. although mike only charges abouuut... USD $300-400 for assembly. plus... i need to have a stable base otherwise i am disassembling equipment and shipping it overseas.
last year i borrowed someone's equipment, i managed to do two of the RK3288 boards. RAM ICs $12 each (QTY 4 so that's... $48 in RAM ICs...), 650-pin 0.5mm pitch BGA processor $12.... you get that wrong it's f*****g expensive.
by contrast whomever mike uses, apart from not filling in the huge 3mm hole under the AXP209 (i've now changed that to a hatch-pattern of about 15 small vias), i haven't actually had a board failure except where the USB-OTG and Micro-HDMI connectors had to be hand-soldered.
do you have any idea how reliable www.openpnp.org project is currently, for example to meet your specs on board with soem available hardware?
i did investigate openpnp - the critical thing if you are going to make one of those is, the rod across to the other side to keep the 2 belts in sync is **NOT** optional. the distance (span) is too great (600mm) for a single belt to reliablly keep the head position (H style) steady by driving only ONE side of the horizontal part of the "H". you MUST put the rod across so that the motor drives BOTH sides of the horizontal cross bar EQUALLY.
here's the thing: if i was intending to manufacture boards "from home", no problem. set up a nice business, stay in one plaaaace, become a home-grown electronics factory, maybe in 10 years have a nice retirement fund. it's a nice thought, isn't it? :) but i'm not going there... that's not my life's purpose.
l.
On 8 January 2018 at 11:06, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Mon, Jan 8, 2018 at 9:32 AM, Hrvoje Lasic lasich@gmail.com wrote:
agree on your points.
did you ever think about in investing in small PNP machine (or just small oven plus some hand tools), like being able to produce small batch in
house
and test it qucikly?
yehyeh, i did - at one point. although mike only charges abouuut... USD $300-400 for assembly. plus... i need to have a stable base otherwise i am disassembling equipment and shipping it overseas.
last year i borrowed someone's equipment, i managed to do two of the RK3288 boards. RAM ICs $12 each (QTY 4 so that's... $48 in RAM ICs...), 650-pin 0.5mm pitch BGA processor $12.... you get that wrong it's f*****g expensive.
by contrast whomever mike uses, apart from not filling in the huge 3mm hole under the AXP209 (i've now changed that to a hatch-pattern of about 15 small vias), i haven't actually had a board failure except where the USB-OTG and Micro-HDMI connectors had to be hand-soldered.
do you have any idea how reliable www.openpnp.org project is currently,
for
example to meet your specs on board with soem available hardware?
i did investigate openpnp - the critical thing if you are going to make one of those is, the rod across to the other side to keep the 2 belts in sync is **NOT** optional. the distance (span) is too great (600mm) for a single belt to reliablly keep the head position (H style) steady by driving only ONE side of the horizontal part of the "H". you MUST put the rod across so that the motor drives BOTH sides of the horizontal cross bar EQUALLY.
here's the thing: if i was intending to manufacture boards "from home", no problem. set up a nice business, stay in one plaaaace, become a home-grown electronics factory, maybe in 10 years have a nice retirement fund. it's a nice thought, isn't it? :) but i'm not going there... that's not my life's purpose.
l.
Agree, but I am more thinking in getting through lets say between 10 and couple of hundred board production. If you have 1000 pcs and stable pcb most likely you will order that in China.
But that point that really kicks from zero to 1000 is critical as well as fast prototyping.
But from perspective of your current project maybe not an issue as you need to produce it in qty, also later hopefully 1000 pcs may be not issue.
But if you are small, starting business producing 100 pcs in house looks like good option.
On Mon, Jan 8, 2018 at 10:41 AM, Hrvoje Lasic lasich@gmail.com wrote:
But if you are small, starting business producing 100 pcs in house looks like good option.
yehyeh absolutely. i am however extremely lucky with mike, he will tolerate 100 pcs orders.
l.
On Mon, Jan 8, 2018 at 4:32 AM, Hrvoje Lasic lasich@gmail.com wrote:
did you ever think about in investing in small PNP machine (or just small oven plus some hand tools), like being able to produce small batch in house and test it qucikly?
No, this would be a horrible idea, I speak from experience here. If the end-product had a few parts (Arduino-ish, BOM < 30 parts), if the smallest passives were 0603's and if the smallest IC's were SSOP's, then yea it MIGHT be doable. But the EOMA68 board has BGA's and (I'm guessing) 0402's and likely some 0201's? The yield rate in a DIY situation would be prohibitive. It is actually cheaper to pay the labor rates and NRE's to a professional that has a process that's dialed in, and a line of machines that aren't toys.
do you have any idea how reliable www.openpnp.org project is currently, for example to meet your specs on board with soem available hardware?
I know the author of that program personally, I hired him and paid him to work on that program for a few months as we tried to make a small desktop machine that could do solder paste application and reflow in addition to pick and place.
OpenPnP works, but that's not the issue. Stencil printing issues and reflow issues would still make the yield horrible. Cheap manual stencil printers lead to issues like tombstoning. Cheap reflows don't get the heat even, which means that certain parts of the board don't get fully soldered. There's a reason that the professional machines are several meters long with various temperature zones and there's a reason that they take a bit of effort to setup correctly. Even if he got some surplus machinery and an area to set it up (including ducting for the exhaust and three-phase AC hookup), there's still the issue of nailing down the actual process, there's just so much to go wrong and that's why so many companies leave that sort of stuff to other companies that are better situated to deal with those kind of problems.
It's not exactly easy for me to say this either, because my dream was to make a machine for projects like EOMA68; to make the development cycle cheaper and quicker. I failed in that regard, and honestly nobody out there has really nailed it to the point where you could start churning out single board computers with BGA's an tiny parts and get close to 100% yields, in a DIY setup. It's sad but that's the reality that we live in.
For the record, while I vehemently disagree with LKCL on other matters like 3D printing and funding via bitcoin mining, I do completely agree with his decision to get a few boards produced and tested before doing a complete run. Even with all the review, there are still plenty of possibilities for show-stoppers.
The only suggestion that I would make -- and it's a big one -- is to send Mike (at the factory) a full test rig that is capable of verifying that an EOMA68 card works properly. This is an essential step of every production run, and I'm honestly surprised that in the update LKCL is planning on doing that himself. which pushes the schedule out to the right by another 3 days. This test rig would merely be a little board that the card plugs into, with HDMI monitor, keyboard, and some testing software to test the memory (Memtest86+), hard drive, peripherals, etc. Once production is going, the factory will need to be testing them anyway before they leave, this would be a good opportunity to test them, yet I saw nothing about that in any of the updates or email traffic. Even if this is something that LKCL personally does not have time to work on, surely someone in the forum could take on this task. So how were you planning on approaching the factory testing? If you've got it all figured out, then why isn't it going to be used for the next immediate run? And if you've not had time to get to it at all yet, why not let someone on the mailing list work on it? I can certainly give a lot of advice in this department. Hardware and software testing of embedded modules is not only what I do at my day job, I had a lot of experience while living in Shenzhen in how to make test fixtures for embedded products. I've got advice on how to make them bilingual so that they can actually be used in the factory by non-English speaking test technicians, and lots of other advice. Just let me know.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Jan 8, 2018 at 2:28 PM, Neil Jansen njansen1@gmail.com wrote:
On Mon, Jan 8, 2018 at 4:32 AM, Hrvoje Lasic lasich@gmail.com wrote:
did you ever think about in investing in small PNP machine (or just small oven plus some hand tools), like being able to produce small batch in house and test it qucikly?
No, this would be a horrible idea, I speak from experience here. If the end-product had a few parts (Arduino-ish, BOM < 30 parts), if the smallest passives were 0603's and if the smallest IC's were SSOP's, then yea it MIGHT be doable. But the EOMA68 board has BGA's and (I'm guessing) 0402's and likely some 0201's?
deliberately no 0201s. you can't pick them up.
do you have any idea how reliable www.openpnp.org project is currently, for example to meet your specs on board with soem available hardware?
I know the author of that program personally, I hired him and paid him to work on that program for a few months as we tried to make a small desktop machine that could do solder paste application and reflow in addition to pick and place.
cool!
It's not exactly easy for me to say this either, because my dream was to make a machine for projects like EOMA68; to make the development cycle cheaper and quicker. I failed in that regard, and honestly nobody out there has really nailed it to the point where you could start churning out single board computers with BGA's an tiny parts and get close to 100% yields, in a DIY setup. It's sad but that's the reality that we live in.
the whole point of doing the computer cards is that the base units - the Housings - *can* be done with 0603 and 0805 components, on 2 layer PCBs.
For the record, while I vehemently disagree with LKCL on other matters like 3D printing and funding via bitcoin mining,
well, if you have any ideas which stand a chance of fulfilling the goals that have been set i'd like to hear them. i didn't hear from anyone when i asked, several times, for help with sponsorship, contracts or anything else, so i had to make my own decisions. urgently.
if people don't like that, tough: they should have responded sooner. i can't wait for people: i have to actually make *decisions*.
I do completely agree with his decision to get a few boards produced and tested before doing a complete run. Even with all the review, there are still plenty of possibilities for show-stoppers.
the 2.7.4 board is the fallback. it'll be... without an HDMI interface. that's just the way it'll be.
The only suggestion that I would make -- and it's a big one -- is to send Mike (at the factory) a full test rig that is capable of verifying that an EOMA68 card works properly.
yehyeh. i'll have to go over to shenzhen to get one set up, and work with his engineers to make it really, _really_ easy to fit the Cards - and Micro-Desktops - into the rig. fixed (locked-down) cables, rails / slides to put the PCBs in so that the connectors go straight in, that sort of thing.
the less time the better.
This is an essential step of every production run, and I'm honestly surprised that in the update LKCL is planning on doing that himself. which pushes the schedule out to the right by another 3 days. This test rig would merely be a little board that the card plugs into, with HDMI monitor, keyboard, and some testing software to test the memory (Memtest86+), hard drive, peripherals, etc. Once production is going, the factory will need to be testing them anyway before they leave, this would be a good opportunity to test them, yet I saw nothing about that in any of the updates or email traffic.
i've mentioned it... half a dozen times over the past... 18-24 months. in several updates and several times on the mailing list.
Even if this is something that LKCL personally does not have time to work on, surely someone in the forum could take on this task.
that would be really handy.
So how were you planning on approaching the factory testing? If you've got it all figured out, then why isn't it going to be used for the next immediate run?
because i do the testing here, one at a time, here. take micro-sd card, take the PCMCIA header i've wired a 5V USB connector to and a UART, plug it in and go. otherwise i have to pay mike or one of mike's engineers to do it.
And if you've not had time to get to it at all yet, why not let someone on the mailing list work on it?
nobody's offered!
I can certainly give a lot of advice in this department. Hardware and software testing of embedded modules is not only what I do at my day job, I had a lot of experience while living in Shenzhen in how to make test fixtures for embedded products. I've got advice on how to make them bilingual so that they can actually be used in the factory by non-English speaking test technicians, and lots of other advice. Just let me know.
coool.
well, the guy who mike employs, he's extremely good at making mechanical rigs and stamps and so on. he can easily put together something that ensures that the workers don't damage the boards during testing as the PCB will go into the rig "in only one physical way and with one physical move".
software-wise i need something that does nothing more complex than mount stuff on a micro-sd card, show boot messages on both screens, and maybe has 2 keyboards plugged in (one into each USB socket) so that they can bash some keys and see that crud comes up on-screen for each.
going beyond that... testing I2C, UART and the GPIO.... *sigh*... that involves writing some software.
l.
On Mon, Jan 8, 2018 at 9:57 AM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
the whole point of doing the computer cards is that the base units - the Housings - *can* be done with 0603 and 0805 components, on 2 layer PCBs.
Does the current housing design break EVERYTHING out? Or only the more important signals?
if people don't like that, tough: they should have responded sooner.
I've got zero skin in the game, I'm not a backer of your campaign. So yea, don't kill yourself over my opinion of how you're managing this. The intention of saying that wasn't to derail the thread into bickering and arguing, but just to point out that I call 'em like I see 'em. While I think you're wrong on many important points, I'll gladly point out when you're doing something right but others are questioning you. That's OK. Running a business is subjective, and you can't make everyone happy. As long as the discussion is civil and open, it's all good.
yehyeh. i'll have to go over to shenzhen to get one set up, and work with his engineers to make it really, _really_ easy to fit the Cards - and Micro-Desktops - into the rig. fixed (locked-down) cables, rails / slides to put the PCBs in so that the connectors go straight in, that sort of thing.
If you're in Shenzhen, there are a few of the markets that have booths where they'll make you an entire mechanical test rig, with pogo pins, DESTACO clamps, LCD screens, buttons, locks, slides, ports, you name it... Just give them a drawing (CAD or otherwise) and come back in a few days. The prices are unbelievably cheap. Compared to my hourly rate, they're basically free.
nobody's offered!
Why not ask the community directly, via the mailing list, and/or the next update? If you say that it's really important and that your time is better spent doing other important facets of the project, that might be what it takes for someone to step forward.
I do feel sympathy because back when I ran an open-source hardware company with a mailing list, and I never got the community support that I needed, unless I begged and pleaded. Everyone was happy to sit around and fire off emails and replies about how I was doing everything wrong, but nobody wanted to do any actual work. I think the word in the USA is 'peanut gallery'. I couldn't trust them any farther than I could throw them, when it came to doing real work. In the open-source hardware world, everyone gets entitled and wants you to give, give, give, and nobody really stops and thinks about what they can give back (other than their opinions and criticisms of course). So yea. It's an expectation management problem for sure. But still it's worth asking. You never know. We had a few guys really step up and deliver.. it was like 0.5% of our list size but hey I'll take what I can get.
well, the guy who mike employs, he's extremely good at making mechanical rigs and stamps and so on. he can easily put together something that ensures that the workers don't damage the boards during testing as the PCB will go into the rig "in only one physical way and with one physical move".
software-wise i need something that does nothing more complex than mount stuff on a micro-sd card, show boot messages on both screens, and maybe has 2 keyboards plugged in (one into each USB socket) so that they can bash some keys and see that crud comes up on-screen for each.
going beyond that... testing I2C, UART and the GPIO.... *sigh*... that involves writing some software.
Sounds like you need a test plan document, in the form of a wiki page or HTML page on your website that documents exactly what you need to test, and how you plan to test it. While I'm way too busy with back-taxes and overtime at work to actually write the code at the moment, I could certainly help put together a test plan document. That's well within my skill set for sure. If you'd like we could start a new thread to discuss. If I did find some time to write a bit of code, it would be Python because that's what I know best, and that might actually work well for a top-level testing interface, because it supports Unicode, and the Qt GUI bindings (PyQt5) would allow switchable translations. As long as the low-level testing code could be called from commandline using existing tools, then the Python environment is really just a test executive that calls the actual test code. Using the built-in Python unittesting framework would a good way to go here. It doesn't produce a test report document at the end, but it will tell you whether everything passed or failed. As far as testing I2C, UART, GPIO, that's all very very doable! Wraparound tests and fixtures and a bit of code is all you need there. But first let's get a plan together! Shall I start a new thread?
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Jan 8, 2018 at 3:32 PM, Neil Jansen njansen1@gmail.com wrote:
On Mon, Jan 8, 2018 at 9:57 AM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
the whole point of doing the computer cards is that the base units - the Housings - *can* be done with 0603 and 0805 components, on 2 layer PCBs.
Does the current housing design break EVERYTHING out?
the microdesktop 1.7 brings everything out. as it's only 68 pins, 24 of which are RGB/TTL, 4 are power, 8 are unused USB3, 7 are for micro-sd and 4 are for USB2, there's actually not a lot left.
Running a business is subjective,
this isn't a business. even the EOMA68 Certification process i will put under a CIC (which is... _sort-of_ a "business" except not really).
under the rules of Certification Marks i'm *not allowed* to quotes profit quotes or do anything that could be considered to be quotes competing quotes with quotes businesses quotes. several people have actually already asked me, "um if i make a housing what's to stop you from putting me out of business by making it yourself" and it's real simple: Certification *inherently* prohibits that.
and you can't make everyone happy. As long as the discussion is civil and open, it's all good.
yehyeh. i'll have to go over to shenzhen to get one set up, and work with his engineers to make it really, _really_ easy to fit the Cards - and Micro-Desktops - into the rig. fixed (locked-down) cables, rails / slides to put the PCBs in so that the connectors go straight in, that sort of thing.
If you're in Shenzhen, there are a few of the markets that have booths where they'll make you an entire mechanical test rig, with pogo pins, DESTACO clamps, LCD screens, buttons, locks, slides, ports, you name it... Just give them a drawing (CAD or otherwise) and come back in a few days. The prices are unbelievably cheap. Compared to my hourly rate, they're basically free.
:)
that's the sort of thing that mike's in-house engineer does.
nobody's offered!
Why not ask the community directly, via the mailing list, and/or the next update?
i have!! about six times!
If you say that it's really important and that your time is better spent doing other important facets of the project, that might be what it takes for someone to step forward.
I do feel sympathy because back when I ran an open-source hardware company with a mailing list, and I never got the community support that I needed, unless I begged and pleaded. Everyone was happy to sit around and fire off emails and replies about how I was doing everything wrong, but nobody wanted to do any actual work.
well, that can begin to change when there's hardware in peoples' hands.
well, the guy who mike employs, he's extremely good at making mechanical rigs and stamps and so on. he can easily put together something that ensures that the workers don't damage the boards during testing as the PCB will go into the rig "in only one physical way and with one physical move".
software-wise i need something that does nothing more complex than mount stuff on a micro-sd card, show boot messages on both screens, and maybe has 2 keyboards plugged in (one into each USB socket) so that they can bash some keys and see that crud comes up on-screen for each.
going beyond that... testing I2C, UART and the GPIO.... *sigh*... that involves writing some software.
Sounds like you need a test plan document, in the form of a wiki page or HTML page on your website that documents exactly what you need to test, and how you plan to test it. While I'm way too busy with back-taxes and overtime at work to actually write the code at the moment, I could certainly help put together a test plan document.
that would be awesome. http://rhombus-tech.net/allwinner_a10/testing/ would be a good start.
That's well within my skill set for sure. If you'd like we could start a new thread to discuss. If I did find some time to write a bit of code, it would be Python because that's what I know best, and that might actually work well for a top-level testing interface, because it supports Unicode, and the Qt GUI bindings (PyQt5) would allow switchable translations. As long as the low-level testing code could be called from commandline using existing tools, then the Python environment is really just a test executive that calls the actual test code. Using the built-in Python unittesting framework would a good way to go here. It doesn't produce a test report document at the end, but it will tell you whether everything passed or failed. As far as testing I2C, UART, GPIO, that's all very very doable! Wraparound tests and fixtures and a bit of code is all you need there. But first let's get a plan together! Shall I start a new thread?
sure. great idea.
l.
On Mon, Jan 8, 2018 at 10:47 AM, Luke Kenneth Casson Leighton <lkcl@lkcl.net
wrote:
the microdesktop 1.7 brings everything out. as it's only 68 pins, 24 of which are RGB/TTL, 4 are power, 8 are unused USB3, 7 are for micro-sd and 4 are for USB2, there's actually not a lot left.
that's the sort of thing that mike's in-house engineer does.
OK then, (A) is there a timetable for when he plans on having such a fixture ready? and (B) Do you have drawings for the fixture that you intend to give to him? Or do you need help with the design? Yes, in this case, I'm offering mechanical fixture design help if needed.
i have!! about six times!
I've been on the mailing list since May of 2017 and I don't recall seeing any direct calls for help in that department. Not saying that you haven't, but I'm just saying that although I've read all the posts and all of the updates since that date, I've not seen a call for help in that area, because if I did, I probably would have stepped up and volunteered. New people join all the time, and even more people lurk, so consider asking again.
well, that can begin to change when there's hardware in peoples' hands.
Very, very true.
that would be awesome. http://rhombus-tech.net/allwinner_a10/testing/ would be a good start.
That's a great start.
[...] Shall I start a new thread?
sure. great idea.
Will start one now.
On Mon, Jan 8, 2018 at 4:07 PM, Neil Jansen njansen1@gmail.com wrote:
OK then, (A) is there a timetable for when he plans on having such a fixture ready?
he isn't planning, i am. any time in the next... 4 months is fine. nothing could ever really be "planned" because there was no point [with a previously unknown and unknowable time on the critical path].
and (B) Do you have drawings for the fixture that you intend to give to him?
no. i met mike a year ago in shenzhen and discussed the need for a test rig, not the actual details *of* a test rig.
Or do you need help with the design? Yes, in this case, I'm offering mechanical fixture design help if needed.
hmm.... i tell you what [and importantly, why] - i feel it would be best to let mike's guy come up with something based on a "requirements specification". that way he feels "needed and trusted" if you know what i mean.
if he ballses it up on the other hand... :)
i have!! about six times!
I've been on the mailing list since May of 2017 and I don't recall seeing any direct calls for help in that department.
the list's being going since... 2011.
Not saying that you haven't, but I'm just saying that although I've read all the posts and all of the updates since that date, I've not seen a call for help in that area, because if I did, I probably would have stepped up and volunteered. New people join all the time, and even more people lurk, so consider asking again.
i forgot about that. whoops :)
l.
On Jan 8, 2018, at 08:47, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Mon, Jan 8, 2018 at 3:32 PM, Neil Jansen njansen1@gmail.com wrote:
Does the current housing design break EVERYTHING out?
the microdesktop 1.7 brings everything out. as it's only 68 pins, 24 of which are RGB/TTL, 4 are power, 8 are unused USB3, 7 are for micro-sd and 4 are for USB2, there's actually not a lot left.
68 - (24 + 4 + 8 + 7 + 4) = 68 - 47 = 21 What are the remaining 21 pins?
On Tue, Jan 9, 2018 at 6:37 PM, Richard Wilbur richard.wilbur@gmail.com wrote:
68 - (24 + 4 + 8 + 7 + 4) = 68 - 47 = 21 What are the remaining 21 pins?
https://elinux.org/Embedded_Open_Modular_Architecture/EOMA68/Hardware#Pinout...
http://hands.com/~lkcl/eoma/microdesktop/microdesktop_v1_7.pdf
On Jan 8, 2018, at 07:57, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Mon, Jan 8, 2018 at 2:28 PM, Neil Jansen njansen1@gmail.com wrote: I do completely agree with his decision to get a few boards produced and tested before doing a complete run. Even with all the review, there are still plenty of possibilities for show-stoppers.
the 2.7.4 board is the fallback. it'll be... without an HDMI interface. that's just the way it'll be.
One downside of the 2.7.4 board at this point is the changes in capacitor pricing that have been ameliorated only on version 2.7.5. Here's hoping the 2.7.5 board works!
[…]
software-wise i need something that does nothing more complex than mount stuff on a micro-sd card, show boot messages on both screens, and maybe has 2 keyboards plugged in (one into each USB socket) so that they can bash some keys and see that crud comes up on-screen for each.
going beyond that... testing I2C, UART and the GPIO.... *sigh*... that involves writing some software.
I'd be happy to write some test software for I2C, UART, GPIO, etc. I've worked on drivers for those interfaces on embedded machines in the past. I also have experience creating and implementing software and hardware test designs. One example, I modified my employer's PCI VGA BIOS to test the card at boot which significantly streamlined testing of our cards. Another example, in order to test a design I created I2C driver and test code to demonstrate feasibility on a prototype and then incorporated it into production code in the BIOS and driver.
Happy to collaborate on board bring up as well. I've worked on bringing up in-house boards for two employers: PCI graphics cards (for which we used oscilloscope and completed someone else's programmable logic design), embedded computers in different modules of high-speed wireless communications links (tools used: spectrum analyzer, oscilloscope, logic analyzer, PCI bus analyzer, MPEG protocol analysis software, processor In-Circuit Emulator, serial terminal).
If you've got that covered, I'm happy playing the role of the ally you can describe the problem to and who, through listening to your description, helps you see the solution!
Sincerely, Richard
On Mon, Jan 8, 2018 at 9:22 PM, Richard Wilbur richard.wilbur@gmail.com wrote:
One downside of the 2.7.4 board at this point is the changes in capacitor pricing that have been ameliorated only on version 2.7.5. Here's hoping the 2.7.5 board works!
darn yeah i'd forgotten about the implications of the price-hike. whoops.
[…]
software-wise i need something that does nothing more complex than mount stuff on a micro-sd card, show boot messages on both screens, and maybe has 2 keyboards plugged in (one into each USB socket) so that they can bash some keys and see that crud comes up on-screen for each.
going beyond that... testing I2C, UART and the GPIO.... *sigh*... that involves writing some software.
I'd be happy to write some test software for I2C, UART, GPIO, etc. I've worked on drivers for those interfaces on embedded machines in the past. I also have experience creating and implementing software and hardware test designs. One example, I modified my employer's PCI VGA BIOS to test the card at boot which significantly streamlined testing of our cards. Another example, in order to test a design I created I2C driver and test code to demonstrate feasibility on a prototype and then incorporated it into production code in the BIOS and driver.
nice! well, this would be a lot simple: scan the I2C bus (lmsensors debian package), see if a peripheral at address 0x51 comes up, if it does _great_. it's a few lines of shell script.
UART: if i add a USB-to-UART adapter onto a "test" microdesktop unit, if there's output on the console and it's not garbage, that's good enough.
the GPIO... yes, that's where some coding comes in. there's actually only a few pins spare, they're all on the 14-pin header of the microdesktop board. except for two which are intended for bit-banging a separate I2C driver for VGA "EDID" detection....
Happy to collaborate on board bring up as well.
great.
I've worked on bringing up in-house boards for two employers: PCI graphics cards (for which we used oscilloscope and completed someone else's programmable logic design), embedded computers in different modules of high-speed wireless communications links (tools used: spectrum analyzer, oscilloscope, logic analyzer, PCI bus analyzer, MPEG protocol analysis software, processor In-Circuit Emulator, serial terminal).
ooo fuuun :)
honestly the board's pretty "mature" and a lot simpler than that. no PCI, no PCIe, it's all SD/MMC, UART, USB, I2C, SPI, RGB/TTL, that sort of thing, where all of those have all worked in previous boards, no reason why they shouldn't work in the 2.7.5 version (except i tidied up the USB lines a bit... never keen on altering stuff that works... ah well).
on the actual board itself, it's so tightly integrated (and also quite simple) that it tends to be an all-or-nothing. does power work, measure the voltages, yes no. ok does plugging in USB-OTG only have it show up on "lsusb" yes no. yes ok great let's load the FEL, does _that_ work, yes no, yes ok great, now does loading u-boot directly into DDR3 RAM work, yes, no.
the FEL (u-boot-spl) loader has a nice debug feature of displaying a few lines of early UART. so that's a really good way to tell if the A20's alive.
from there i can compile u-boot to look for a particular micro-sd card slot, which it will scan, and show debug messages "SD card detected" and so on. i can do commands which list the partitions and so on.
it's pretty straghtforward: anything not working shows up really quickly and easily.
If you've got that covered, I'm happy playing the role of the ally you can describe the problem to and who, through listening to your description, helps you see the solution!
appreciated.
... y'know... when we get to the RISC-V 64-bit SoC then that's going to be a lot trickier. aside from anything it will be necessary to do the DDR3 layout from scratch. i can't stand doing DDR3 layouts, they're... blegh :) get it wrong and yeah you reaaaly need a logic analyzer...
oh. i have an RK3288 board that could use your help. i only got one of the DDR3 lanes up and running.
l.
On Mon, Jan 8, 2018 at 11:24 PM, Richard Wilbur richard.wilbur@gmail.com wrote:
It all sounds like fun! What can I help with first?
well... perhaps... something simple like.. a simple program that tests GPIO, assuming that say 4 hard-wires are connected between 8 GPIOs in pairs, turning one into an input and the other an output, then setting 0 and 1 and seeing if it's read correctly... then inverting each pair (out becomes in, in becomes out) and re-running the test.
something in either c or python that uses the sunxi-3.4 gpio driver: https://github.com/linux-sunxi/linux-sunxi/blob/stage/sunxi-3.4/drivers/gpio...
that _should_ be exposed as /dev/gpio which should in turn appear in either /sys or /proc... it should be a standard interface, with a standard way to set which banks are activated... you might have to do some digging.
l.
On Jan 8, 2018, at 17:23, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Mon, Jan 8, 2018 at 11:24 PM, Richard Wilbur richard.wilbur@gmail.com wrote:
It all sounds like fun! What can I help with first?
well... perhaps... something simple like.. a simple program that tests GPIO, assuming that say 4 hard-wires are connected between 8 GPIOs in pairs, turning one into an input and the other an output, then setting 0 and 1 and seeing if it's read correctly... then inverting each pair (out becomes in, in becomes out) and re-running the test.
I'd recommend resistors instead of wires. Something like 10KΩ because then if they are accidentally misconnected, Vcc(5V?) to ground would only amount to 0.5mA which is unlikely to stress anything unduly. What kind of logic are these GPIO pins? (CMOS, TTL, etc.)
something in either c or python that uses the sunxi-3.4 gpio driver: https://github.com/linux-sunxi/linux-sunxi/blob/stage/sunxi-3.4/drivers/gpio...
that _should_ be exposed as /dev/gpio which should in turn appear in either /sys or /proc... it should be a standard interface, with a standard way to set which banks are activated... you might have to do some digging.
So there are 4 pairs or 8 GPIO lines to test? (I thought we had 14 lines dedicated to GPIO and two more that were going to be used as I2C for VGA? Are only 8 easy to test?) I'll assume I either get the connected pairs via an environment variable, the command line, or a file (filename passed on command line).
Last time I asked these questions I succeeded in hiding them in the middle of a bunch of other text.
On Jan 9, 2018, at 06:26, Richard Wilbur richard.wilbur@gmail.com wrote:
What kind of logic are these GPIO pins? (CMOS, TTL, etc.)
The type of logic determines the input and output voltage and current source and sink characteristics (both capabilities and expectations). Do you have the Allwinner documentation for the A20--specifically for the GPIO pins?
So there are 4 pairs or 8 GPIO lines to test? (I thought we had more lines dedicated to GPIO and two more that were going to be used as I2C for VGA? Are only 8 easy to test?)
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Fri, Jan 12, 2018 at 11:37 PM, Richard Wilbur richard.wilbur@gmail.com wrote:
Last time I asked these questions I succeeded in hiding them in the middle of a bunch of other text.
On Jan 9, 2018, at 06:26, Richard Wilbur richard.wilbur@gmail.com wrote:
What kind of logic are these GPIO pins? (CMOS, TTL, etc.)
The type of logic determines the input and output voltage and current source and sink characteristics (both capabilities and expectations). Do you have the Allwinner documentation for the A20--specifically for the GPIO pins?
ok google "allwinner a20 datasheet" or better "allwinner a20 reference manual" you'll find it.
So there are 4 pairs or 8 GPIO lines to test? (I thought we had more lines dedicated to GPIO and two more that were going to be used as I2C for VGA? Are only 8 easy to test?)
the choice - on the Microdesktop PCB - to arbitrarily utilise two of the GPIO pins as bit-banged I2C - is entirely one that is legitimate yet has absolutely nothing to do with the EOMA68 specification, *other* than, "It Is Permitted" under the EOMA68 specification to make such decisions.
the choice - on the Microdesktop PCB - to arbitrarily utilise those two GPIO pins as bit-banged I2C - is done because the termination impedance for VGA EDID is, according to the specification, somewhere around 10 kOhms, whereas the normal I2C termination resistance is usually somewhere around 2.2kOhms.
i felt therefore that it was important *not* to have the VGA I2C lines connected to the EOMA68 I2C bus.
these decisions have *nothing to do with the EOMA68 specification*, they are simply "permitted under the EOMA68 specification" if that makes sense.
l.
I am sorry if any of my comments came across with any flavour of criticism. I meant none towards anyone but myself.
Thank you for the pointer to the Allwinner A20 documentation. I didn't know how easily available it was.
I was just wondering whether there were more GPIO lines we could test (by hook or by crook). My goal is the best test coverage.
No complaints about the EOMA specification or your design decisions on the microdesktop case.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sat, Jan 13, 2018 at 10:05 PM, Richard Wilbur richard.wilbur@gmail.com wrote:
I am sorry if any of my comments came across with any flavour of criticism. I meant none towards anyone but myself.
nono, sorry, richard, i was up very late. and am again today. kept it very short.
Thank you for the pointer to the Allwinner A20 documentation. I didn't know how easily available it was.
it can be a pain to find if you don't know the keywords
I was just wondering whether there were more GPIO lines we could test (by hook or by crook). My goal is the best test coverage.
i also have to think how to minimise testing time, as it will be chargeable by the minute. either that or i do it... get *everything* shipped to my apartment.... oooo i always wanted an ultra-low-power beowulf clusterrrr... ooooo :)
No complaints about the EOMA specification or your design decisions on the microdesktop case.
relief.
btw jonathon, please do keep the momentum going, it's important. damn hard work, i've gone through several reviews like this, over the past 5 years, and four of them resulted in major changes. it's very *very* late in the day now so it's necessary to be extra-extra careful.
l.
On Jan 13, 2018, at 15:11, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Sat, Jan 13, 2018 at 10:05 PM, Richard Wilbur richard.wilbur@gmail.com wrote:
I was just wondering whether there were more GPIO lines we could test (by hook or by crook). My goal is the best test coverage.
i also have to think how to minimise testing time, as it will be chargeable by the minute. either that or i do it... get *everything* shipped to my apartment.... oooo i always wanted an ultra-low-power beowulf clusterrrr... ooooo :)
From what I've seen, I think we can automate a lot of this so it takes
a second or two per card. I expect our tall tentpole (the thing that's holding everything up) will be booting the card. Do you know how long it takes the bootloader to come up from power on? How long does it take GNU/Linux to get to user login after that?
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sun, Jan 14, 2018 at 7:50 AM, Richard Wilbur richard.wilbur@gmail.com wrote:
On Jan 13, 2018, at 15:11, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Sat, Jan 13, 2018 at 10:05 PM, Richard Wilbur richard.wilbur@gmail.com wrote:
I was just wondering whether there were more GPIO lines we could test (by hook or by crook). My goal is the best test coverage.
i also have to think how to minimise testing time, as it will be chargeable by the minute. either that or i do it... get *everything* shipped to my apartment.... oooo i always wanted an ultra-low-power beowulf clusterrrr... ooooo :)
From what I've seen, I think we can automate a lot of this so it takes a second or two per card.
it'll be a bit longer than that :)
I expect our tall tentpole (the thing that's holding everything up) will be booting the card. Do you know how long it takes the bootloader to come up from power on?
it's about 1-2 seconds :) there's a 3 second automated delay for "user-input" which can be switched off.
How long does it take GNU/Linux to get to user login after that?
initialisation of the linux kernel depends very much on which kernel modules are compiled-in and which are modules, but let's say around 4-7 seconds. there is quite a lot of "delay" built-in, such as waiting for sd-cards to initialise, or waiting for this to initialise,waiting for that etc.
from /sbin/init to a full GUI is about another.... 10-15 seconds.
l.
On 18.1.8 16:9, Luke Kenneth Casson Leighton wrote:
On ~, [called month 1, day]~ 8, 2018 at 9:22 PM, Richard Wilbur richard.wilbur@gmail.com wrote:
One downside of the 2.7.4 board at this point is the changes in capacitor pricing that have been ameliorated only on version 2.7.5. Here's hoping the 2.7.5 board works!
darn yeah i'd forgotten about the implications of the price-hike. whoops.
So, if 2.7.5 is found to have a problem, then it might be cheaper to solve that, than to "fall back" to 2.7.4?
On Mon, Jan 29, 2018 at 3:28 AM, chadvellacott@sasktel.net wrote:
So, if 2.7.5 is found to have a problem, then it might be cheaper to solve that, than to "fall back" to 2.7.4?
i finally managed to pin mike down for long enough to get some estimates for the capacitors - we estimated it is around $2.50 where it was around $0.50 last year. i previously thought it would be $5 to $8.
l.
arm-netbook@lists.phcomp.co.uk
-
chadvellacott＠sasktel.net -
Hrvoje Lasic -
Luke Kenneth Casson Leighton -
mike.valk＠gmail.com -
Neil Jansen -
Richard Wilbur