This is a response letter to the notice just received that the Improv project is being warpped up. Only trivially editied to fit the context of the mailinglist. (inital reply was sent privately)
I am sorry to see the Improv project being wrapped up but fully understand and do not come as a surprise given the discussions over last months.
Just not sure I agree on the conclusions expressed in this letter however, claiming that "The Free software community does not seem ready at this point to make a concerted stand on the pressing issue of hardware freedom". The issues that have dragged this project down has very little to do with free software as such, or even the community at large.
EOMA68 have been dragged down mostly by lack of resources, being founded as a garage project run on pocket money and begging, resulting in endless delays and unfavorable compromises, plus numerous issues in people relations. And in addition starting at the wrong end of the table trying to make a standard for hardware without first being familiar with hardware designs and considerations. Resulting in a project trying to make a leap before it knew how to crawl or even less walk, with a very high level of uncertainty as result. It will probably get there in the end, but getting there takes a lot of time and experience.
As for Improv, by the time it entered (the hardware) it provided nothing unique that developers could not find elsewhere. Also most people in my humble opinion already had given up on EOMA68 as a serious initiative due to the numerous problems that project had already seen. I still back the basic ideas of EOMA68, but not sure about the current realization of it, aiming purely at low end market in interface specifications. Also, it has to be realized that any such specification do have a fairly limited lifespan and needs to be revised regularly, which somewhat nullifies the benefits.
A project like EOMA68 trying to break many new grounds needs early adopters willing to spend both money and time on getting things finalized, and I am fully convinced that early adopters are not the ones looking for the low-end range specifications. And with such project having a lifespan covering several years (not months like average Tablet project) interface specifications need to be such that it can be suitable for wide adoption in a two to three years time when enought is in place and tested, not yesterday.
For the sake of software development Improv isn't really needed, and was not needed at the time of launch. There is and was fully OSHW solutions available that covers the hardware functionality of Improv (minus the exchangeable "CPU module" part). In particular I am thinking of Olimex Olinuxino A20 MICRO (and it's related cousins), giving the same performance specifications as the selected EOMA68-A20 module, but with much richer hardware interfacing capabilities and of course 100% OSHW, by a established manufacturer who works with believes in OSHW.
I have much more to say on the subject, but enough for tonight. Feel free to contact me if you want me to elaborate further.
Regarding refund of my Improv "investment". Don't sweat over it. I'd rather see you focus on moving forward than how to cover the refunds. Failures are all natural path of moving forward and learning.
Regards Henrik
On Thu, 2014-06-26 at 03:50 +0200, Henrik Nordström wrote:
This is
SAD.
So many things wrong in various positions being taken by all the players in that post.
There is enough resources and money to see the EOMA68 or something like it to completion (meaning batch production ready). And then it can go kickstarter to go commercial if anyone wants to.
Quite a few distros have been made on the Cubieboard awaiting release that will run on EOMA68. It would be good if KDE plasma can be working on EOMA68 and a touch LCD. Or better still, cubieboard and touch LCD because that can transfer to EOMA with just a few minor changes, whilst in parallel Mr. Cubie (Tom) reaps some benefits from Plasma/touch LCD working. Any ideas anyone for costs to make it happen? (Paypal ready question!)
tor 2014-06-26 klockan 08:59 +0000 skrev joem:
Quite a few distros have been made on the Cubieboard awaiting release that will run on EOMA68. It would be good if KDE plasma can be working on EOMA68 and a touch LCD. Or better still, cubieboard and touch LCD because that can transfer to EOMA with just a few minor changes, whilst in parallel Mr. Cubie (Tom)
Tom is no longer involved in Cubietech afaik.
In personally I prefer Olimex boards for development. A little bigger, but all open and more I/O exposed. Plus a much wider range of boards available depending on your needs.
reaps some benefits from Plasma/touch LCD working. Any ideas anyone for costs to make it happen? (Paypal ready question!)
If it can run ontop of Android MALI drivers then not much should be missing.
The state for non-Android GNU/Linux MALI drivers is a bit of a mess unfortunately. Getting this in production shape requires cooperation of Allwinner and maybe ARM as well.
LIMA is doing good progress, but will likely take a while before it's capable of running Plasma.
Regards Henrik
On Thu, 2014-06-26 at 18:13 +0200, Henrik Nordström wrote:
tor 2014-06-26 klockan 08:59 +0000 skrev joem:
Quite a few distros have been made on the Cubieboard awaiting release that will run on EOMA68. It would be good if KDE plasma can be working on EOMA68 and a touch LCD. Or better still, cubieboard and touch LCD because that can transfer to EOMA with just a few minor changes, whilst in parallel Mr. Cubie (Tom)
Tom is no longer involved in Cubietech afaik.
In personally I prefer Olimex boards for development. A little bigger, but all open and more I/O exposed. Plus a much wider range of boards available depending on your needs.
Thank you - will look into evaluating one.
reaps some benefits from Plasma/touch LCD working. Any ideas anyone for costs to make it happen? (Paypal ready question!)
If it can run ontop of Android MALI drivers then not much should be missing.
The state for non-Android GNU/Linux MALI drivers is a bit of a mess unfortunately. Getting this in production shape requires cooperation of Allwinner and maybe ARM as well.
LIMA is doing good progress, but will likely take a while before it's capable of running Plasma.
Its an utter shame the current plan is to let all this drag on.
The mass market for which the EOMA and touch display, and plasma will sell billions of, and which the trolls here have missed during their fierce holy wars of late is fitted to this product: https://www.youtube.com/watch?v=Sj0CozzsDEY
Personally I don't mind calling Luke, Aaron, Allwinner, ARM and everyone a troll until this problem is repaired. Reading all the stuff posted, they have zero understanding of what they are missing out on.
Still, I got to the stage where Gambas is working on LCD with EOMA68 / Cubieboard and if I find enough time, the touch LCD will work. The gambas GUI software will have to provide what plasma hasn't yet delivered.
The sliding screen effects could probably get implemented by Gambas. If we ask the Gambas community for a graphical control that can do that effect, it would probably get built in.
Luke: I got the latest board costed up and its <$50 per EOMA with 2GB (not going split resources at this stage to make the 1GB). But it comes with a lead balloon MOQ of 2000 for the PCMCIA case because they are only made in Taiwan.
On Fri, Jun 27, 2014 at 8:11 AM, joem joem@martindale-electric.co.uk wrote:
Luke: I got the latest board costed up and its <$50 per EOMA with 2GB (not going split resources at this stage to make the 1GB).
samples testing. we cannot go to production levels without sample testing, 5pcs.
But it comes with a lead balloon MOQ of 2000 for the PCMCIA case because they are only made in Taiwan.
litkconn is not taiwanese. the factory's in guangdong.
On Fri, 2014-06-27 at 09:26 +0100, Luke Kenneth Casson Leighton wrote:
On Fri, Jun 27, 2014 at 8:11 AM, joem joem@martindale-electric.co.uk wrote:
Luke: I got the latest board costed up and its <$50 per EOMA with 2GB (not going split resources at this stage to make the 1GB).
samples testing. we cannot go to production levels without sample testing, 5pcs.
It costs factories between USD1000 to USD2000 to try to organise something like this. I normally place order for between 10 and 20 pieces to meet these expenses.
I check with them for best quantity.
But it comes with a lead balloon MOQ of 2000 for the PCMCIA case because they are only made in Taiwan.
litkconn is not taiwanese. the factory's in guangdong.
Thank you, I run that past them again.
,
On Fri, Jun 27, 2014 at 9:51 AM, joem joem@martindale-electric.co.uk wrote:
On Fri, 2014-06-27 at 09:26 +0100, Luke Kenneth Casson Leighton wrote:
On Fri, Jun 27, 2014 at 8:11 AM, joem joem@martindale-electric.co.uk wrote:
Luke: I got the latest board costed up and its <$50 per EOMA with 2GB (not going split resources at this stage to make the 1GB).
samples testing. we cannot go to production levels without sample testing, 5pcs.
It costs factories between USD1000 to USD2000 to try to organise something like this. I normally place order for between 10 and 20 pieces to meet these expenses.
I check with them for best quantity.
that gives between 10 to 20 people to get units to... which may or may not work. i want roughly a 30:70% mix of 1gbyte and 2gbyte of samples - it's just in case the 2gbyte doesn't work.
But it comes with a lead balloon MOQ of 2000 for the PCMCIA case because they are only made in Taiwan.
litkconn is not taiwanese. the factory's in guangdong.
Thank you, I run that past them again.
the connector is from litkconn, it's on the BOM, so why did they go to the trouble of finding a manufacturer with whom we have absolutely no relationship?? i mean, it's good to know that there are still companies out there not just litkconn, but the chances are that they would order completely and utterly the wrong PCMCIA connector at totally the wrong height.
been through this already with litkconn, selected the right part, even designed the PCB and chose the PCB thickness to be *precisely* inside the litkconn housing.
so litkconn already know exactly which part - it's their part number 68F. price for case, plastic and connector should be around $1.50. that's plastic with the middle cut out. if we get over 2k orders we can get the punch made with them for $6k to make the proper holes.
l.
On Fri, Jun 27, 2014 at 12:13 AM, Henrik Nordström henrik@henriknordstrom.net wrote:
tor 2014-06-26 klockan 08:59 +0000 skrev joem:
Quite a few distros have been made on the Cubieboard awaiting release that will run on EOMA68. It would be good if KDE plasma can be working on EOMA68 and a touch LCD. Or better still, cubieboard and touch LCD because that can transfer to EOMA with just a few minor changes, whilst in parallel Mr. Cubie (Tom)
Tom is no longer involved in Cubietech afaik.
Confirmed.
In personally I prefer Olimex boards for development. A little bigger, but all open and more I/O exposed. Plus a much wider range of boards available depending on your needs.
reaps some benefits from Plasma/touch LCD working. Any ideas anyone for costs to make it happen? (Paypal ready question!)
If it can run ontop of Android MALI drivers then not much should be missing.
The state for non-Android GNU/Linux MALI drivers is a bit of a mess unfortunately. Getting this in production shape requires cooperation of Allwinner and maybe ARM as well.
LIMA is doing good progress, but will likely take a while before it's capable of running Plasma.
Regards Henrik
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 Thu, Jun 26, 2014 at 9:59 AM, joem joem@martindale-electric.co.uk wrote:
On Thu, 2014-06-26 at 03:50 +0200, Henrik Nordström wrote:
This is
SAD.
So many things wrong in various positions being taken by all the players in that post.
don't sweat it. silver lining.
There is enough resources and money to see the EOMA68 or something like it to completion (meaning batch production ready). And then it can go kickstarter to go commercial if anyone wants to.
ack. you got those PADS files, can you get them quoted up? pick any decent PCB manufacturer. 5PCs MicroDesktop, 5PCs EOMA68-A20, 2 with 2Gb RAM, 3 with 1Gb RAM.
l.
On Thu, Jun 26, 2014 at 2:50 AM, Henrik Nordström henrik@henriknordstrom.net wrote:
This is a response letter to the notice just received that the Improv project is being warpped up. Only trivially editied to fit the context of the mailinglist. (inital reply was sent privately)
Just not sure I agree on the conclusions expressed in this letter however, claiming that "The Free software community does not seem ready at this point to make a concerted stand on the pressing issue of hardware freedom".
that's actually very sensible i think to say because it either a) wakes people up or b) makes them think "hang on is it true??"
people relations. And in addition starting at the wrong end of the table trying to make a standard for hardware without first being familiar with hardware designs and considerations. Resulting in a project trying to make a leap before it knew how to crawl or even less walk, with a very high level of uncertainty as result. It will probably get there in the end, but getting there takes a lot of time and experience.
and you know what? i'm actually relieved, because this is supposed to be a decade-long standard. if we'd had the funding, we would have gone ahead, the EOMA68 standard would have SATA and it would have about one SoC available per two years *or less*.
the changes i've made since it started open it up to 23or more SoCs *per year*. i am also considering - reluctantly - reserving the 5.0mm card height for 1280x800 capable SoCs and the 3.3mm card height for 1920x1080 SoCs (over the 24-pin RGB/TTL that is)
As for Improv, by the time it entered (the hardware) it provided nothing unique that developers could not find elsewhere. Also most people in my humble opinion already had given up on EOMA68 as a serious initiative due to the numerous problems that project had already seen. I still back the basic ideas of EOMA68, but not sure about the current realization of it, aiming purely at low end market in interface specifications.
but henrik, this is entirely entirely missing the point. the entire point for end-users is that you buy 1 CPU Card and share them across products, saving 30 to 40% for doing so *and* having consistent user applications and data across all products.
Also, it has to be realized that any such specification do have a fairly limited lifespan and needs to be revised regularly, which somewhat nullifies the benefits.
no. the interfaces were picked because they have all been around for over a decade, and they are anticipated to be around and in mass-production use for at least another decade.
do you see USB being retired in the next 10 years? (serious question)
with over 2,000 active LCD panels on panellook.com do you see RGB/TTL being retired in the next 10 years?
likewise I2C, likewise GPIO, likewise SD/MMC, likewise SPI, likewise UART, likewise ethernet.
if one of them was e.g. Firewire i would say there was a problem.
For the sake of software development Improv isn't really needed, and was not needed at the time of launch. There is and was fully OSHW solutions available that covers the hardware functionality of Improv (minus the exchangeable "CPU module" part). In particular I am thinking of Olimex Olinuxino A20 MICRO (and it's related cousins), giving the same performance specifications as the selected EOMA68-A20 module, but with much richer hardware interfacing capabilities and of course 100% OSHW, by a established manufacturer who works with believes in OSHW.
... except doesn't take a stand on GPL violations, and distributes illegal copyright-violating product, but _apart_ from that they "believe in OSHW", yes.
no i am fully aware that the CPU Cards have "less interfaces" quotes. that is entirely deliberate, as the interfaces had to be:
* lowest-common-denominator * hardware-level upwardly self-negotiating (faster rates over more wires) * decade-long lifespans
then the base-board uses e.g. Embedded Controllers to "fan out" the missing functionality in a way that is *guaranteed* to be available *regardless* of the SoC in the CPU Card.
in this way we can ensure that even the lowliest SoC (for example the IC1T which is barely struggling to meet the absolute minimum of EOMA68 requirements) stands a chance.
if we had put e.g. CSI or TS on, or eDP or MIPI, then only the absolute absolute top-end SoCs could be included, and even then some of *those* would be excluded simply because they were so specialist that they did not have the interfaces available.
look at the example of SATA. i wanted it - everyone wanted it - but in the end it had to go, because it's not lowest-common-denominator (and USB3-to-SATA ICs can do a good enough replacement job).
I have much more to say on the subject, but enough for tonight. Feel free to contact me if you want me to elaborate further.
Regarding refund of my Improv "investment". Don't sweat over it.
you need to tell the improv team that, not me. remember, they were just a 3rd party client, so we were waiting for the cash order. all the money is held by that 3rd party. so you need to tell *them*, not me, ok?
I'd rather see you focus on moving forward than how to cover the refunds. Failures are all natural path of moving forward and learning.
true. ain't quitting.
2014-06-26 22:47 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
i am also considering - reluctantly - reserving the 5.0mm card height for 1280x800 capable SoCs and the 3.3mm card height for 1920x1080 SoCs (over the 24-pin RGB/TTL that is)
I do not understand this well. Why you would do this separation?
no. the interfaces were picked because they have all been around for over a decade, and they are anticipated to be around and in mass-production use for at least another decade.
do you see USB being retired in the next 10 years? (serious question)
with over 2,000 active LCD panels on panellook.com do you see RGB/TTL being retired in the next 10 years?
likewise I2C, likewise GPIO, likewise SD/MMC, likewise SPI, likewise UART, likewise ethernet.
I agree with you. Perhaps my only doubt is that I think that in 5 years all new screens will MIPI.
Thanks.
2014-06-26 22:47 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
i am also considering - reluctantly - reserving the 5.0mm card height for 1280x800 capable SoCs and the 3.3mm card height for 1920x1080 SoCs (over the 24-pin RGB/TTL that is)
I do not understand this well. Why you would do this separation?
Thanks.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 26/06/14 21:47, Luke Kenneth Casson Leighton wrote:
For the sake of software development Improv isn't really needed, and was not needed at the time of launch. There is and was fully OSHW solutions available that covers the hardware functionality of Improv (minus the exchangeable "CPU module" part). In particular I am thinking of Olimex Olinuxino A20 MICRO (and it's related cousins), giving the same performance specifications as the selected EOMA68-A20 module, but with much richer hardware interfacing capabilities and of course 100% OSHW, by a established manufacturer who works with believes in OSHW.
... except doesn't take a stand on GPL violations, and distributes illegal copyright-violating product, but _apart_ from that they "believe in OSHW", yes.
so what, the kernel(s) or the software stack or drivers,firmware or etc have GPL violated code in them? Is it for things like video acceleration? if so, urrgh hypocrites. thats tyipical of the open source mind set :( . Admittedly I've been trying to decide (for weeks) on weather I get the LIME board for a version of a diy pockect computer :\
On Thu, Jun 26, 2014 at 11:57 PM, Alexander Stephen Thomas Ross maillist_arm-netbook@aross.me wrote:
so what, the kernel(s) or the software stack or drivers,firmware or etc have GPL violated code in them?
the bootloader.
fre 2014-06-27 klockan 09:16 +0100 skrev Luke Kenneth Casson Leighton:
On Thu, Jun 26, 2014 at 11:57 PM, Alexander Stephen Thomas Ross maillist_arm-netbook@aross.me wrote:
so what, the kernel(s) or the software stack or drivers,firmware or etc have GPL violated code in them?
the bootloader.
That's a very thin case. The bulk of all the bootloader sources are published. Sure, AW is not so good in publishing current sources, but there is not really any more bootloader sources for A20 that we have interest in at this stage. (thanks to you btw for getting confirmation on GPL status of the A20 SDK version).
If you had said NAND drivers then I maybe might agree with you as they holding back later NAND driver sources may impact interoperability with free software, but not on the bootloader. We are way past that stage.
Regards Henrik
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm surprised it's the bootloader. I hate to distract but you face giving a bit more info/history? thanks
tor 2014-06-26 klockan 21:47 +0100 skrev Luke Kenneth Casson Leighton:
and you know what? i'm actually relieved, because this is supposed to be a decade-long standard. if we'd had the funding, we would have gone ahead, the EOMA68 standard would have SATA and it would have about one SoC available per two years *or less*.
Agreed.
the changes i've made since it started open it up to 23or more SoCs *per year*. i am also considering - reluctantly - reserving the 5.0mm card height for 1280x800 capable SoCs and the 3.3mm card height for 1920x1080 SoCs (over the 24-pin RGB/TTL that is)
Why? I don't get it.
For 1920x1080+ LVDS / DSI / eDP is much better suited interfaces imho. Unfortunately all (including RGB/TLL, but except eDP) is plauged by configuration issues and vendor extension dependencies which makes then somewhat troublesome for EOMA.
As for Improv, by the time it entered (the hardware) it provided nothing unique that developers could not find elsewhere. Also most people in my humble opinion already had given up on EOMA68 as a serious initiative due to the numerous problems that project had already seen. I still back the basic ideas of EOMA68, but not sure about the current realization of it, aiming purely at low end market in interface specifications.
but henrik, this is entirely entirely missing the point. the entire point for end-users is that you buy 1 CPU Card and share them across products, saving 30 to 40% for doing so *and* having consistent user applications and data across all products.
No I am not missing the point at all.
My point is that Improv is a development platform. EOMA68 is at this point in time a niche product. The combination of the two makes an extremely small market for Improv. The primary group that Improv targets have other choices that fulfill their needs better.
EOMA68 needs something like Improv.
The majority of the users Improv targets do not need EOMA68 or even benefit from it.
Also, it has to be realized that any such specification do have a fairly limited lifespan and needs to be revised regularly, which somewhat nullifies the benefits.
no. the interfaces were picked because they have all been around for over a decade, and they are anticipated to be around and in mass-production use for at least another decade.
Agreed that the selected interfaces is going away any time soon, but these specifications forces the lower end of the spectrum, which also makes it an uninteresting path for the tech-sawy people you need to get the whole thing flying.
do you see USB being retired in the next 10 years? (serious question)
No. But RGB/TTL is likely fading quickly as display density increases.
with over 2,000 active LCD panels on panellook.com do you see RGB/TTL being retired in the next 10 years?
Outside the low-end product spectrum yes, obviously.
likewise I2C, likewise GPIO, likewise SD/MMC, likewise SPI, likewise UART, likewise ethernet.
No, but I question our ability to today define which of these is really needed.
... except doesn't take a stand on GPL violations, and distributes illegal copyright-violating product, but _apart_ from that they "believe in OSHW", yes.
It's a hardware company, not a software company. Their software development resources are very limited, and do take these infringements seriously.
no i am fully aware that the CPU Cards have "less interfaces" quotes. that is entirely deliberate, as the interfaces had to be:
And I was not critizing EOMA there.
in this way we can ensure that even the lowliest SoC (for example the IC1T which is barely struggling to meet the absolute minimum of EOMA68 requirements) stands a chance.
Is that at all a desireable goal?
Timewarp two years, would such device have any reuse value at all by then?
Same applies to the other half of EOMA, the base-board (or perhaps better named base-device). The EOMA idea only makes sense if pieces are up to a level that reuse and upgrade makes sense.
Or in other words, any EOMA device designed today need to be designed with the goal of being valuable to reuse in at least 2-3 years time.
Any device manufactured at the lower range of todays standard is very unlikely to have any meaningful value in two to three years in the same consumer group.
if we had put e.g. CSI or TS on, or eDP or MIPI, then only the absolute absolute top-end SoCs could be included,
today yes, unless you accept to throw in a converted chip, which is hard doe to the extreme tight space requirements in the EOMA standards.
look at the example of SATA. i wanted it - everyone wanted it - but in the end it had to go, because it's not lowest-common-denominator (and USB3-to-SATA ICs can do a good enough replacement job).
Heck, even storage over USB2 works well for most practical uses today in the target focus of EOMA.
you need to tell the improv team that, not me. remember, they were just a 3rd party client, so we were waiting for the cash order. all the money is held by that 3rd party. so you need to tell *them*, not me, ok?
And I did. As stated in the first paragraph this message was a public copy of my response to their letter with only minimal edits to fit the mailinglist.
I'd rather see you focus on moving forward than how to cover the refunds. Failures are all natural path of moving forward and learning.
true. ain't quitting.
Neither am I. Just temporarily held up in other completely crazy business and learning a lot more about hardware side of things than I ever thought I would be doing.. and mixed together with free software. But almost entirely outside the scope of this mailinglist even if we did cause noticeable shortage of Beaglebone Blacks on the market..
Regards Henrik
On Fri, Jun 27, 2014 at 12:09 AM, Henrik Nordström henrik@henriknordstrom.net wrote:
tor 2014-06-26 klockan 21:47 +0100 skrev Luke Kenneth Casson Leighton:
and you know what? i'm actually relieved, because this is supposed to be a decade-long standard. if we'd had the funding, we would have gone ahead, the EOMA68 standard would have SATA and it would have about one SoC available per two years *or less*.
Agreed.
the changes i've made since it started open it up to 23or more SoCs *per year*. i am also considering - reluctantly - reserving the 5.0mm card height for 1280x800 capable SoCs and the 3.3mm card height for 1920x1080 SoCs (over the 24-pin RGB/TTL that is)
Why? I don't get it.
For 1920x1080+ LVDS / DSI / eDP is much better suited interfaces imho.
.. for which there exist conversion ICs. if however you try to get anything *other* than an RGB/TTL-to-{INSERT-INTERFACE-HERE} IC you run into huge costs and licensing issues.
No. But RGB/TTL is likely fading quickly as display density increases.
... for which there exist conversion ICs.
with over 2,000 active LCD panels on panellook.com do you see RGB/TTL being retired in the next 10 years?
Outside the low-end product spectrum yes, obviously.
and above that low-end product spectrum there exist conversion ICs.
... except doesn't take a stand on GPL violations, and distributes illegal copyright-violating product, but _apart_ from that they "believe in OSHW", yes.
It's a hardware company, not a software company. Their software development resources are very limited, and do take these infringements seriously.
not seriously enough. you know the law. if you cannot comply, you must cease and desist distribution.
or you operate as a criminal cartel.
no i am fully aware that the CPU Cards have "less interfaces" quotes. that is entirely deliberate, as the interfaces had to be:
And I was not critizing EOMA there.
in this way we can ensure that even the lowliest SoC (for example the IC1T which is barely struggling to meet the absolute minimum of EOMA68 requirements) stands a chance.
Is that at all a desireable goal?
Timewarp two years, would such device have any reuse value at all by then?
as a lower-spec'd reusable board for someone else? yes, absolutely. that's the whole point: down-stream the hardware.
Same applies to the other half of EOMA, the base-board (or perhaps better named base-device). The EOMA idea only makes sense if pieces are up to a level that reuse and upgrade makes sense.
Or in other words, any EOMA device designed today need to be designed with the goal of being valuable to reuse in at least 2-3 years time.
Any device manufactured at the lower range of todays standard is very unlikely to have any meaningful value in two to three years in the same consumer group.
i expect the 2nd-hand market on ebay to take care of that.
if we had put e.g. CSI or TS on, or eDP or MIPI, then only the absolute absolute top-end SoCs could be included,
today yes, unless you accept to throw in a converted chip, which is hard doe to the extreme tight space requirements in the EOMA standards.
.... exactly, which is why that problem is moved to the base-board.
it's the base-board where you put the converter ICs.
take a look on chrontel's web site.
tell me how many DVI-to-{INSERTINTERFACE} converter ICs there are.
tell me how many eDP-to-{INSERTINTERFACE} converter ICs there are.
_now_ compare that to how many RGB/TTL-to-{INSERTINTERFACE} converter ICs there are.
ok. too much time being spent. gotta go.
On Fri, Jun 27, 2014 at 12:09 AM, Henrik Nordström henrik@henriknordstrom.net wrote:
the changes i've made since it started open it up to 23or more SoCs *per year*. i am also considering - reluctantly - reserving the 5.0mm card height for 1280x800 capable SoCs and the 3.3mm card height for 1920x1080 SoCs (over the 24-pin RGB/TTL that is)
Why? I don't get it.
For 1920x1080+ LVDS / DSI / eDP is much better suited interfaces imho. Unfortunately all (including RGB/TLL, but except eDP) is plauged by configuration issues and vendor extension dependencies which makes then somewhat troublesome for EOMA.
ok, i have a bit more time, so can explain further. the logic is as follows:
* SoCs are on the market at 1280x800 maximum resolution over RGB/TTL * SoCs are on the market at 2048x2048 @ 30fps max res over RGB/TTL * RGB/TTL is the lowest common denominator and is present on all but the absolute absolute specialist SoCs such as mobile smartphone ones, high-end high-power SoCs (Calxeda, TI etc.) * LVDS is fraught with choice between 1 or 2 channels * RGB/TTL, precisely because it is lowest-common-denominator, may be converted to just about anything with an IC that costs between $1 for a single-channel LVDS to $3.50 or $5 for a 1920x1080 DVI/HDMI and someone recently found an eDP one for $3 which is awesome.
so the cases we want to cover are:
* 320x240 RGB/TTL screen at very low cost (these are all RGB/TTL) * 1024-1280 x 600-1024 screen at reasonable cost (these are all LVDS 1x but a _few_ eDPs are becoming available) * 1440x900 to 1920x1080 at not unreasonable cost (these are usually Dual or Triple LVDS with some now 4-lane eDP and so on)
remember that EOMA interfaces are *mandatory*.
* if you make even LVDS mandatory, you just screwed 2 out of 3 of those options (pick any 2: the 320x240 one is my favourite because you will need an LVDS converter on the SoC *and* a down-converter on the base-board, and you just screwed any chance of having a low cost system!)
* if you make eDP mandatory you just screwed 2 out 3 of those options, the 320x240 is screwed on cost, and 1 out of 2 of the others are screwed on the number of eDP lanes.
also you are royally screwed on the pricing of eDP ICs vs the cost of RGB/TTL-to-LVDS ICs.
* if you make MIPI mandatory it's the same thing
* if you make HDMI mandatory it's *worse* because now you have two $5 ICs _and_ you have a $50,000 up-front HDMI manufacturer's extortion^Wlicense to pay.
* if however you make RGB/TTL mandatory you may:
- use direct RGB/TTL (zero cost) to connect to the 320x240 LCD
- use a $1 RGB/TTL to LVDS IC or a $3 RGB/TTL to MIPI IC for the 1024x600 to 1280x1024 LCDs
- use a $3 to $5 RGB/TTL to LVDS or eDP IC to connect to the 1440x900 and the 1920x1080 LCDs.
so overall it is actually very simple: RGB/TTL is the only remaining logical choice once you have considered all the options from all the angles covering all the products and all SoC families. the cost of the converter ICs is a manageable quantity that is relative to the cost of the LCD it is connecting to and the sale price of the product.
l.
o the cases we want to cover are:
- 320x240 RGB/TTL screen at very low cost (these are all RGB/TTL)
- 1024-1280 x 600-1024 screen at reasonable cost (these are all LVDS 1x but a _few_ eDPs are becoming available)
- 1440x900 to 1920x1080 at not unreasonable cost (these are usually Dual or Triple LVDS with some now 4-lane eDP and so on)
hmmmp.
Yesterday this may have been true. Today the starting point is something like a 7" tablet with retail price of $50 and min 800x600. With tablet guts removed and a HDMI/VGA/Composite input board fitted, that price shrinks to $30 retail.
Also if tablets were a little more open, load an OS that turns the tablet into a USB monitor may be possible = another opportunity for EOMAs to sell in their beeellions.
On Sat, Jun 28, 2014 at 7:29 PM, joem joem@martindale-electric.co.uk wrote:
o the cases we want to cover are:
- 320x240 RGB/TTL screen at very low cost (these are all RGB/TTL)
- 1024-1280 x 600-1024 screen at reasonable cost (these are all LVDS 1x but a _few_ eDPs are becoming available)
- 1440x900 to 1920x1080 at not unreasonable cost (these are usually Dual or Triple LVDS with some now 4-lane eDP and so on)
hmmmp.
Yesterday this may have been true. Today the starting point is something like a 7" tablet with retail price of $50 and min 800x600. With tablet guts removed and a HDMI/VGA/Composite input board fitted, that price shrinks to $30 retail.
Also if tablets were a little more open, load an OS that turns the tablet into a USB monitor may be possible = another opportunity for EOMAs to sell in their beeellions.
exactly.. with a pass-through card any device with a screen, touchpanel, mouse, internal hard drive etc basically becomes an extension system for desktop PCs, other devices - anything.
i did a case study where hilariously if you have 2 devices, one CPU Card and one pass-through card it actually doesn't matter what you plug in to what, you still end up with one computer with 2 screens.
l.
On Sat, 2014-06-28 at 20:59 +0100, Luke Kenneth Casson Leighton wrote:
On Sat, Jun 28, 2014 at 7:29 PM, joem joem@martindale-electric.co.uk wrote:
o the cases we want to cover are:
- 320x240 RGB/TTL screen at very low cost (these are all RGB/TTL)
- 1024-1280 x 600-1024 screen at reasonable cost (these are all LVDS 1x but a _few_ eDPs are becoming available)
- 1440x900 to 1920x1080 at not unreasonable cost (these are usually Dual or Triple LVDS with some now 4-lane eDP and so on)
hmmmp.
Yesterday this may have been true. Today the starting point is something like a 7" tablet with retail price of $50 and min 800x600. With tablet guts removed and a HDMI/VGA/Composite input board fitted, that price shrinks to $30 retail.
Also if tablets were a little more open, load an OS that turns the tablet into a USB monitor may be possible = another opportunity for EOMAs to sell in their beeellions.
exactly.. with a pass-through card any device with a screen, touchpanel, mouse, internal hard drive etc basically becomes an extension system for desktop PCs, other devices - anything.
i did a case study where hilariously if you have 2 devices, one CPU Card and one pass-through card it actually doesn't matter what you plug in to what, you still end up with one computer with 2 screens.
There is also a need to CPU + dedicted customized OS that turns the tablet into a graphics computer (e.g. running X window) and taking compressed commands from the USB directly. If it can talk, even more better.
Got the talking bit sorted with Ubuntu, gambas and espeak. Next step is to get gambas into a crude graphics rendering system that takes crude commands like circle(x,y,r). The idea is that an embedded CPU with very little resources, or a headless computer with a USB link can connect to this device and speak out of it / turn it into a monitor without having to have large amounts of graphics processing software or the RAM in the embedded controller.
The ideas are similar to a graphical version of a VT100 terminal, but with more features, open, and ultra simple embedded CPU friendly interface. Suitable for Arduino to little PIC chip.
Dream on I guess :)
On Mon, Jun 30, 2014 at 12:58 AM, joem joem@martindale-electric.co.uk wrote:
There is also a need to CPU + dedicted customized OS that turns the tablet into a graphics computer (e.g. running X window) and taking compressed commands from the USB directly.
weelll... the first easily-achievable way to do that is to use any SoC with USB-OTG. the other way is using a DisplayLink IC. but, both ways _do_ need some amounts of RAM otherwise you severely saturate the USB bus and/or overload the main processor. DisplayLink's first IC does very basic 2D primitives (line, rectangle, image) which is a half-way compromise. the second (which is USB3) i don't know exactly what they do.
... yes been thinking quite a lot how to do this, joe :)
l.
On Mon, 2014-06-30 at 03:39 +0100, Luke Kenneth Casson Leighton wrote:
On Mon, Jun 30, 2014 at 12:58 AM, joem joem@martindale-electric.co.uk wrote:
There is also a need to CPU + dedicted customized OS that turns the tablet into a graphics computer (e.g. running X window) and taking compressed commands from the USB directly.
weelll... the first easily-achievable way to do that is to use any SoC with USB-OTG. the other way is using a DisplayLink IC. but, both ways _do_ need some amounts of RAM otherwise you severely saturate the USB bus and/or overload the main processor. DisplayLink's first IC does very basic 2D primitives (line, rectangle, image) which is a half-way compromise. the second (which is USB3) i don't know exactly what they do.
... yes been thinking quite a lot how to do this, joe :)
OK - stretch to next level:
With storage being cheap ($4 for 16GB flash) its reasonable to start a project to let the users of this type of 'terminal' to upload their graphics, command sets and limited animations and it would get compressed and incorporated into the 16GB 'distro' (with emphasis on reuse of existing stuff). The user plugs it into the relevant hardware, the hardware sends 32 bit identifier through serial port or USB to locate its command set, and then any further signals are known to the 'terminal' which then does the grunt work to update the terminal with graphics. Even a simple multimeter with embedded CPU could then do a lot of magical functions knowing a serial port can be used to send the presentation of voltage, current, etc. this 'terminal' which will know how to render the graphical screen and make it very interesting. An open source tool by the techies for the techies working with embedded stuff at the coal face to get projects out to the market asap without trying to source custom LCD and bits needed to make it work correctly.
If I could buy a terminal like that, I'd buy 10 terminals today, at cost of $50 each and do my own graphics from re-usable stuff that others have done and/or do my own and upload for incorporation into the 16gb distro.
I'd never have to worry about adding full colour LCDs for all my gadgets again! As an EE, such a terminal would be more valuable to me than any other gadget right now.
Speech is also important - all my gadgets now talk to me if they detect a problem. Speeds up debugging by a factor of a million. The severity level and types of messages are selectable to avoid being bombarded with geek speaking screaming boards.
arm-netbook@lists.phcomp.co.uk
-
Alexander Stephen Thomas Ross -
Henrik Nordström -
joem -
Luke Kenneth Casson Leighton -
Miguel Garcia -
Stefan Monnier -
Tom Cubie