3_bit
Member
- Joined
- Nov 29, 2012
- Messages
- 212
I have an odd feeling this guy will one day be a moderator here.
ANYWAYS
It does seem like a good choice from what I can tell.
Pandora 2 with EOMA-68 CPU Card
- Thread starter lkcl
- Start date
ANYWAYS
It does seem like a good choice from what I can tell.
C
CocoCreekFisherman
Guest
^ a legend.
naaaaah
i have shed-loads of other things i'm doing. Exophase
Nothing good will ever come of Exophase.
Not sure how I missed this the first time around but stumbled on it after looking for info on the mailing list..
Saving money is good but Pandora 2 is not going to be in a race to the bottom. A10 barely offers anything over the current DM3730 Pandoras. Yeah the memory's faster but it's DDR3 which is to be avoided for a small mobile device. Pandora 2 really needs more than one core, this enables so many basic improvements. At the same time, single threaded performance is absolutely critical and going to 2x or 4x 1GHz Cortex-A7s is also not a good option. I have a good feeling emulators like PCSX-reARMed would perform worse on an A20 than they currently do on a DM3730. JZ4760 would be even worse. iMX6 is better but who knows when that'll be ready? Still pretty underwhelming for a 2013/2014 device.
Yeah, there could be upgrades in the future, but it's not like you guys are open to anything.. there's this huge emphasis on very cheap and as open source as possible. Not good if Pandora 2 is tied to that. Now they could do their own board using this form factor. But the problem is that the form factor itself has a lot of problems for a Pandora-like device.
The footprint is just too big. Keep in mind that Pandora 2 needs a keyboard, which takes a lot of board space. Too much space is wasted by having to use four DDR3 chips instead of one PoP and having the big connector headers, in addition to a layout that's not really that aggressively space optimized overall. Another major problem is what's put on the connectors themselves.. Using PCMIA and just bringing out a big parallel LCD, touchscreen, handful of GPIOs, power, SATA, and ethernet (latter two Pandora 2 probably won't need) is too little. There needs to be more GPIOs, something to interface a keyboard controller with, audio, USB, etc. For that I see there are more headers on the board but that's really not good for a low profile design and adds pointless costs and more points for error, last thing Pandora 2 needs is more custom ribbon cables. And Pandora users want full SD (two of them) and full USB, so as far as hard parts go that has to be brought off too. I don't know if the STM32F sound solution is going to a 3.5" header but that doesn't really matter as there's no way PWM audio is going to cut it for Pandora users, so it'd just have to be popped off.
Still don't really understand what the STM32F is supposed to be good for. Maybe Allwinner's chips are missing a lot of things that other SoCs have but most of the feature list for the code there can be handled on a typical SoC and/or PMIC. Normally decent SoCs can handle several SD/MMC, USB, and camera. PMICs can do battery management and some have keyboard facilities (Pandora's does). As I discussed on gp23x using it for sound is a terrible idea. I think using a Cortex-M series microcontroller could be useful for nub controllers (as far as I can tell you don't expose any analog I/Os on the board so Pandora 2 couldn't use yours for that) but paying over $2 for the chip is overkill. You can get what you need in a < $0.50 Cortex-M0 microcontroller with limited amounts of RAM and flash.
Not sure what this microcontroller's role is in camera for your board anyway, it's not like it can provide any high speed interfaces for it...
Saving money is good but Pandora 2 is not going to be in a race to the bottom. A10 barely offers anything over the current DM3730 Pandoras. Yeah the memory's faster but it's DDR3 which is to be avoided for a small mobile device. Pandora 2 really needs more than one core, this enables so many basic improvements. At the same time, single threaded performance is absolutely critical and going to 2x or 4x 1GHz Cortex-A7s is also not a good option. I have a good feeling emulators like PCSX-reARMed would perform worse on an A20 than they currently do on a DM3730. JZ4760 would be even worse. iMX6 is better but who knows when that'll be ready? Still pretty underwhelming for a 2013/2014 device.
Yeah, there could be upgrades in the future, but it's not like you guys are open to anything.. there's this huge emphasis on very cheap and as open source as possible. Not good if Pandora 2 is tied to that. Now they could do their own board using this form factor. But the problem is that the form factor itself has a lot of problems for a Pandora-like device.
The footprint is just too big. Keep in mind that Pandora 2 needs a keyboard, which takes a lot of board space. Too much space is wasted by having to use four DDR3 chips instead of one PoP and having the big connector headers, in addition to a layout that's not really that aggressively space optimized overall. Another major problem is what's put on the connectors themselves.. Using PCMIA and just bringing out a big parallel LCD, touchscreen, handful of GPIOs, power, SATA, and ethernet (latter two Pandora 2 probably won't need) is too little. There needs to be more GPIOs, something to interface a keyboard controller with, audio, USB, etc. For that I see there are more headers on the board but that's really not good for a low profile design and adds pointless costs and more points for error, last thing Pandora 2 needs is more custom ribbon cables. And Pandora users want full SD (two of them) and full USB, so as far as hard parts go that has to be brought off too. I don't know if the STM32F sound solution is going to a 3.5" header but that doesn't really matter as there's no way PWM audio is going to cut it for Pandora users, so it'd just have to be popped off.
Still don't really understand what the STM32F is supposed to be good for. Maybe Allwinner's chips are missing a lot of things that other SoCs have but most of the feature list for the code there can be handled on a typical SoC and/or PMIC. Normally decent SoCs can handle several SD/MMC, USB, and camera. PMICs can do battery management and some have keyboard facilities (Pandora's does). As I discussed on gp23x using it for sound is a terrible idea. I think using a Cortex-M series microcontroller could be useful for nub controllers (as far as I can tell you don't expose any analog I/Os on the board so Pandora 2 couldn't use yours for that) but paying over $2 for the chip is overkill. You can get what you need in a < $0.50 Cortex-M0 microcontroller with limited amounts of RAM and flash.
Not sure what this microcontroller's role is in camera for your board anyway, it's not like it can provide any high speed interfaces for it...
Last edited by a moderator:
So, Mr. Exo, from a professional stand point, how much processing power would Pandora 2 need to make emulating NDS, and some windows 95 era programs a walk in a park?
If pandora can some how play starcraft on 1.2ghz, will a 2 ghz dual core cortex a15, which will be released soon enough, be enough for more advanced games like Diablo 2 or age of empires 2?
I'm no expert. so excuse me if I'm completely wrong and smells like a cheesy prick. I think since Apple has made so many rocky mistakes, and Microsoft is desperately trying to be like Apple in every feasible and nonsensical way. Android is likely to grow even bigger, and google may release android for laptops and desktops. So, for future extensibility, Android performance maybe really important for p2.
Wouldn't quad-core processors be nice things to have for running the space age pickled-angry-bird-cupcake android 15? It seems to me that every new ARM processors coming out are along this line.
Also, do you think by having a high resolution super webcam will attract any potential customers? It shouldn't be too expensive, since every thing from smart phones to certain breed of cats are coming with those. If future Android and Linux would utilize the camera more, maybe we should have one just in case.
monstercameron
Well-Known Member
unless you are h/w accelerating it that could be a massive load on the cpu...
Not sure how I missed this the first time around but stumbled on it after looking for info on the mailing list..
good to hear from you.
Saving money is good but Pandora 2 is not going to be in a race to the bottom. A10 barely offers anything over the current DM3730 Pandoras.
exophase, exophase, you've missed the point. the CPU card is *upgradeable*. if you can get hold of an Exynos 5 or an Intel Atom ValleyView 22nm SoC then you can upgrade the product... *WITHOUT* a PCB respin.
focussing on the fact that the very first CPU card will have an A10 processor is entirely missing the point. if you want a DM3730 CPU Card then that's doable. as is anything. and from experience i know that if i have the EVB schematics including PCB layout it's possible to get to sampling of a new CPU Card in about *four weeks*. one week for me to create the initial layout, two weeks for an experienced engineer to finish it off, and one week to print and populate the PCB.
the jz4760 is what ingenic was prepared to give me - i asked, and received the PCB files in under 3 hours (!) which is amazing. i'd picked it because i believed it would make a good FSF-Endorseable CPU Card (for another project). if the jz4780 looks like it's something that would work for Pandora2, let me know, give me a prediction of order quantities and i'll go talk to them.
basically - pick your processor and come talk to me ok?!
Yeah, there could be upgrades in the future, but it's not like you guys are open to anything.. there's this huge emphasis on very cheap and as open source as possible.
where the heck did you get that impression from?? where did you see it quoted that we wish to limit our sales opportunities? please tell me so that i can post on whatever forum that is or modify the words so that it's clear that the EOMA initiative is open to *all*!
you may be mistaking "mass-volume" for "low quality, low speed". that's not the case! i'm chasing a guy who has access to the Exynos5, to see if he'd like to do an EOMA-68 CPU Card using that processor. i'm chasing intel for access to ValleyView 22nm.
we're about providing *value* - not "absolute-rock-bottom prices to the absolute exclusion of all else".
The footprint is just too big. Keep in mind that Pandora 2 needs a keyboard, which takes a lot of board space. Too much space is wasted by having to use four DDR3 chips instead of one PoP and having the big connector headers, in addition to a layout that's not really that aggressively space optimized overall.
have you got access to PCB layout software? give it a shot - i started an experimental layout here: http://hands.com/~lkcl/eoma/pandora2/
the other alternative is EOMA-CF which is.... 3mm high by 43mm x 31mm something like that (i.e. it's Compact Flash!) - however we would need to pay for tooling here so have left it until we've got sales coming in of products and cards based on EOMA-68.
There needs to be more GPIOs, something to interface a keyboard controller with, audio, USB, etc
that's what the STM32F is for. look closely at the schematics (PDF at the above URL) - you'll see that from the Flying Squirrel there's a 60-pin connector which i just put all the spare unused STM32F pins over from that. there's enough GPIO on the STM32F to sink a battleship. Analog, PWM, Digital - they're pretty awesome little processors.
in other words, the STM32F is a smart way to get all the I/O. and, actually, it's amazingly cost-effective! for $2.36 in 10k volumes you get an audio controller, camera controller, keyboard controller, mouse controller, battery management and power controller.... if you've looked up the cost of the equivalent ICs you'll find they come to about $8 to $10!
but, yes, if you know of a great Cortex M0 that would do a similar job then that's fantastic! i picked the STM32F merely because the Flying Squirrel needed a camera, and there's a guy who's done an LGPLv3 library that talks directly (no camera controller! the STM32F *is* the camera controller!) to the camera: https://github.com/adamgreig/followingrobot
also, there are variants of the STM32F that will do I2S. so you could wire up a decent MAXIM CODEC if you wanted to. i think they're the 120mhz variants, so they cost a little bit more. ST Microelectronics have an application note on using these faster STM32Fs for *decent* audio. the only reason i picked PWM is because it looked "good enough" for a tablet, and i was running out of pins also, i wanted to experiment to see if it was possible, as a way to get the pricing down.
you don't *have* to do it that way - it's just one option.
other comments: NO CUSTOM RIBBON CABLES NEEDED. apart from anything that would mean opening up the EOMA-68 card and also being critically dependent on a specific CPU Card's I/O and internal arrangements, which entirely defeats the object of the exercise. if you're going to do that then you might as well not bother with EOMA-68 at all.
Not sure what this microcontroller's role is in camera for your board anyway, it's not like it can provide any high speed interfaces for it...
yep, it can. the 72mhz STM32F can do up to VGA camera resolution using DMA read/write on 16 of its GPIO pins: that's enough to cover the 8-bit data path from standard CSI cameras and doing the hsync and vsync etc. any more than that and you're pushing your luck, but if you don't need a camera then you don't need the STM32F and that $0.50 Cortex M3 you mentioned would do the job.
also the STM32F (or a Cortex M3) has analog GPIO, so the objection over analog GPIO not being in EOMA-68 goes away at very little extra cost for quite a lot of extra benefit in the future.
also the STM32F 100-pin variant has SD/MMC, the data path is 4-bit wide and i believe it runs at 25mhz. it's DMA-driven so there's no bit-banging going on. so that's your 2nd SD/MMC card: the other one is on every single one of the EOMA-68 CPU Cards we've designed so far and so it's probably going to be there on all but the aaaabsolutely lowest-budget cards [in the future]. that one will be running at the speed that the 1 (or 2ghz) CPU can run at, for example i believe the A10 it's a UHC Class 3 4-bit-wide and on the iMX6 i believe it's a 110mhz 8-bit (SD MMC v4 or something).
but, if you really want an EOMA-68 CPU Card with 2 SD/MMC Cards, let's talk. the SoCs typically have 2 or 3 SD/MMC interfaces: i'm sure we could design something, but it'll need the tooling paid for to design the casework as you're not going to get 2 Micro-SD Cards plus USB-OTG and Micro-HDMI into a 40mm x 3mm space at the end of the connector. so it'd have to go somewhere in the middle of the PCB, meaning that it'd need to be top-loading and therefore a cut-out made in the PCMCIA casework; that'd need paying for.
Maybe Allwinner's chips are missing a lot of things that other SoCs have but most of the feature list for the code there can be handled on a typical SoC and/or PMIC.
please stop focussing on allwinner. allwinner's SoCs are just the first in a decade-long roadmap that will see us going to 14nm and beyond, with oct-core SoCs and beyond and more that any of us couldn't possibly predict on timescales but will enjoy having access to... *without* a redesign.
if you prefer not to use STM32F or Cortex M0 or use the PMIC i chose which happened i believe to be the best choice for a 7in tablet then it's always possible to do the various functions as discrete components - USB or I2C devices. there's an I2C "keyboard scanner" chip that i found recently, which has gone into the sparkfun 8x8 LED driver product. you can always get hold of USB AC97 ICs. you can always get hold of USB Camera ICs that have on-board compression that will give you more than VGA resolution. etc. etc. but they cost!!
and my take on it is that because you are adding value at the future-upgradeability level, that that extra cost is WORTH IT, both from a design perspective as well as from an end-user perspective.
from a design perspective: think about how much hassle it turned out to be to design and implement the OpenPandora 1. do you *really* want that hassle again, having to redo an 8 to 10 layer PCB in another 2 years or possibly even 18 months because the SoC you chose for the OpenPandora 2 is *already* out-of-date 6 months into the sales cycle?
from an end-user perspective: people who buy an EOMA-68 Pandora might not wish to be dependent on the design decisions made by the Pandora Team! they might be happy with a budget CPU Card. they might be happy with the fastest most expensive CPU Card that's available on the market. there might be a group of them willing to get together and do a kickstarter for you to pay for the design of the fastest most expensive CPU Card around, knowing full well that it can be done *quickly* and can go straight into their EOMA-68 Pandora *WITHOUT* you having to go through the hassle of redesigning the entire product, or them ripping the thing apart, unscrewing it, re-assembling it just to replace the PCB (like the GTA04)
so there is a lot more value in EOMA-68 than first appears, and you *DON'T* have to make compromises on quality to get the advantages.
l.
good to hear from you.Saving money is good but Pandora 2 is not going to be in a race to the bottom. A10 barely offers anything over the current DM3730 Pandoras.
exophase, exophase, you've missed the point. the CPU card is *upgradeable*. if you can get hold of an Exynos 5 or an Intel Atom ValleyView 22nm SoC then you can upgrade the product... *WITHOUT* a PCB respin.
focussing on the fact that the very first CPU card will have an A10 processor is entirely missing the point. if you want a DM3730 CPU Card then that's doable. as is anything. and from experience i know that if i have the EVB schematics including PCB layout it's possible to get to sampling of a new CPU Card in about *four weeks*. one week for me to create the initial layout, two weeks for an experienced engineer to finish it off, and one week to print and populate the PCB.
the jz4760 is what ingenic was prepared to give me - i asked, and received the PCB files in under 3 hours (!) which is amazing. i'd picked it because i believed it would make a good FSF-Endorseable CPU Card (for another project). if the jz4780 looks like it's something that would work for Pandora2, let me know, give me a prediction of order quantities and i'll go talk to them.
basically - pick your processor and come talk to me ok?!
Yeah, there could be upgrades in the future, but it's not like you guys are open to anything.. there's this huge emphasis on very cheap and as open source as possible.
where the heck did you get that impression from?? where did you see it quoted that we wish to limit our sales opportunities? please tell me so that i can post on whatever forum that is or modify the words so that it's clear that the EOMA initiative is open to *all*!
you may be mistaking "mass-volume" for "low quality, low speed". that's not the case! i'm chasing a guy who has access to the Exynos5, to see if he'd like to do an EOMA-68 CPU Card using that processor. i'm chasing intel for access to ValleyView 22nm.
we're about providing *value* - not "absolute-rock-bottom prices to the absolute exclusion of all else".
The footprint is just too big. Keep in mind that Pandora 2 needs a keyboard, which takes a lot of board space. Too much space is wasted by having to use four DDR3 chips instead of one PoP and having the big connector headers, in addition to a layout that's not really that aggressively space optimized overall.
have you got access to PCB layout software? give it a shot - i started an experimental layout here: http://hands.com/~lkcl/eoma/pandora2/
the other alternative is EOMA-CF which is.... 3mm high by 43mm x 31mm something like that (i.e. it's Compact Flash!) - however we would need to pay for tooling here so have left it until we've got sales coming in of products and cards based on EOMA-68.
There needs to be more GPIOs, something to interface a keyboard controller with, audio, USB, etc
that's what the STM32F is for. look closely at the schematics (PDF at the above URL) - you'll see that from the Flying Squirrel there's a 60-pin connector which i just put all the spare unused STM32F pins over from that. there's enough GPIO on the STM32F to sink a battleship. Analog, PWM, Digital - they're pretty awesome little processors.
in other words, the STM32F is a smart way to get all the I/O. and, actually, it's amazingly cost-effective! for $2.36 in 10k volumes you get an audio controller, camera controller, keyboard controller, mouse controller, battery management and power controller.... if you've looked up the cost of the equivalent ICs you'll find they come to about $8 to $10!
but, yes, if you know of a great Cortex M0 that would do a similar job then that's fantastic! i picked the STM32F merely because the Flying Squirrel needed a camera, and there's a guy who's done an LGPLv3 library that talks directly (no camera controller! the STM32F *is* the camera controller!) to the camera: https://github.com/adamgreig/followingrobot
also, there are variants of the STM32F that will do I2S. so you could wire up a decent MAXIM CODEC if you wanted to. i think they're the 120mhz variants, so they cost a little bit more. ST Microelectronics have an application note on using these faster STM32Fs for *decent* audio. the only reason i picked PWM is because it looked "good enough" for a tablet, and i was running out of pins
also, i wanted to experiment to see if it was possible, as a way to get the pricing down.you don't *have* to do it that way - it's just one option.
other comments: NO CUSTOM RIBBON CABLES NEEDED. apart from anything that would mean opening up the EOMA-68 card and also being critically dependent on a specific CPU Card's I/O and internal arrangements, which entirely defeats the object of the exercise. if you're going to do that then you might as well not bother with EOMA-68 at all.
Not sure what this microcontroller's role is in camera for your board anyway, it's not like it can provide any high speed interfaces for it...
yep, it can. the 72mhz STM32F can do up to VGA camera resolution using DMA read/write on 16 of its GPIO pins: that's enough to cover the 8-bit data path from standard CSI cameras and doing the hsync and vsync etc. any more than that and you're pushing your luck, but if you don't need a camera then you don't need the STM32F and that $0.50 Cortex M3 you mentioned would do the job.
also the STM32F (or a Cortex M3) has analog GPIO, so the objection over analog GPIO not being in EOMA-68 goes away at very little extra cost for quite a lot of extra benefit in the future.
also the STM32F 100-pin variant has SD/MMC, the data path is 4-bit wide and i believe it runs at 25mhz. it's DMA-driven so there's no bit-banging going on. so that's your 2nd SD/MMC card: the other one is on every single one of the EOMA-68 CPU Cards we've designed so far and so it's probably going to be there on all but the aaaabsolutely lowest-budget cards [in the future]. that one will be running at the speed that the 1 (or 2ghz) CPU can run at, for example i believe the A10 it's a UHC Class 3 4-bit-wide and on the iMX6 i believe it's a 110mhz 8-bit (SD MMC v4 or something).
but, if you really want an EOMA-68 CPU Card with 2 SD/MMC Cards, let's talk. the SoCs typically have 2 or 3 SD/MMC interfaces: i'm sure we could design something, but it'll need the tooling paid for to design the casework as you're not going to get 2 Micro-SD Cards plus USB-OTG and Micro-HDMI into a 40mm x 3mm space at the end of the connector. so it'd have to go somewhere in the middle of the PCB, meaning that it'd need to be top-loading and therefore a cut-out made in the PCMCIA casework; that'd need paying for.
Maybe Allwinner's chips are missing a lot of things that other SoCs have but most of the feature list for the code there can be handled on a typical SoC and/or PMIC.
please stop focussing on allwinner. allwinner's SoCs are just the first in a decade-long roadmap that will see us going to 14nm and beyond, with oct-core SoCs and beyond and more that any of us couldn't possibly predict on timescales but will enjoy having access to... *without* a redesign.
if you prefer not to use STM32F or Cortex M0 or use the PMIC i chose which happened i believe to be the best choice for a 7in tablet then it's always possible to do the various functions as discrete components - USB or I2C devices. there's an I2C "keyboard scanner" chip that i found recently, which has gone into the sparkfun 8x8 LED driver product. you can always get hold of USB AC97 ICs. you can always get hold of USB Camera ICs that have on-board compression that will give you more than VGA resolution. etc. etc. but they cost!!
and my take on it is that because you are adding value at the future-upgradeability level, that that extra cost is WORTH IT, both from a design perspective as well as from an end-user perspective.
from a design perspective: think about how much hassle it turned out to be to design and implement the OpenPandora 1. do you *really* want that hassle again, having to redo an 8 to 10 layer PCB in another 2 years or possibly even 18 months because the SoC you chose for the OpenPandora 2 is *already* out-of-date 6 months into the sales cycle?
from an end-user perspective: people who buy an EOMA-68 Pandora might not wish to be dependent on the design decisions made by the Pandora Team! they might be happy with a budget CPU Card. they might be happy with the fastest most expensive CPU Card that's available on the market. there might be a group of them willing to get together and do a kickstarter for you to pay for the design of the fastest most expensive CPU Card around, knowing full well that it can be done *quickly* and can go straight into their EOMA-68 Pandora *WITHOUT* you having to go through the hassle of redesigning the entire product, or them ripping the thing apart, unscrewing it, re-assembling it just to replace the PCB (like the GTA04)
so there is a lot more value in EOMA-68 than first appears, and you *DON'T* have to make compromises on quality to get the advantages.
l.
Last edited by a moderator:
The P1 has a PCB the full with and depth of the case to allow for the keyboard to have something to make electrical connections on.
Everything else fits on the back of that PCB.
If the SOC were to be on a removable PCB, then there would have to be a second one for the keyboard, instantly making the whole unit significantly thicker.
If you can find somewhere to put a compact flash (or pcimcia) card in the P1, I'll think about the benefits of using an EOMA module
Everything else fits on the back of that PCB.
If the SOC were to be on a removable PCB, then there would have to be a second one for the keyboard, instantly making the whole unit significantly thicker.
If you can find somewhere to put a compact flash (or pcimcia) card in the P1, I'll think about the benefits of using an EOMA module
Exophase
Nothing good will ever come of Exophase.
I understand that other cards are possible.
On this forum we've talked in the past extensively about separating the SoC/RAM/PMIC on a main PCB, EvilDragon agreed that's the best way, so that's pretty much what would happen either way. Not really a question
What you're trying to bring to the table isn't the form factor, it's the selection of cards that's realistic for you to make. You say you can just make anything and will take requests and it'll happen, I don't believe it. There's a hard limit to how many of these things you can make.
Of course Jz4780 won't work, I'm surprised I even have to tell you that.. Same reason why "upgrading" to x86 is a bad idea..
What I really meant when I said "open to anything" is "open to everything", or "it's not like you guys will put just anything on the cards." You've given huge lists of criteria that have driven choices, a big emphasis on open source compliance and availability.. but now you say you'll use anything people want?
Yeah anyone can do an EOMA card, that of course begs the question of why they'd want to use this big and limiting form factor for a handheld, which I guess the rest of the post will get into..
Only because so far everything you say you are doing is low quality, low speed..
Then why do you not even have a real DAC on the board? You said on gp32x that < $2 for the chip was too much. That's not indicative of chasing absolute rock bottom prices at the absolute exclusion of all else?
404.
So we're talking about different form factors for this standard now? I thought the idea was it was supposed to be interchangeable between other devices? If we're talking about something unique to Pandora why get you to do it?
I've used them extensively (pretty large packet ones), I know what they're capable of and what they aren't.. but we're not talking about what GPIOs are on the chips on the board, but what you're bringing off of the main connector..
Did you see what I said about that?
It's comparatively bad at all of those things. Especially the audio part. I don't know how this eludes you. PWM audio is terrible. Most SoCs that would be reasonable candidates for Pandora 2 have camera controllers and STM32 is awful at this. PMICs that would be necessary to support the SoC have battery and power management. Keyboard controllers may be on the PMIC (it is on Pandora). Mouse controller is worthless for us. Audio controller is the only thing you're offering but the compromise is far too great, Pandora users would lynch you.
Of course for all this stuff you need software on the STM32 chip..
Are you really investigating these things seriously? Yes that guy has an STM32F talking to a camera. A 128x96 camera, that talks over I2C. Do you get it? The camera is a toy useless for most applications and the reason you don't need a controller is because the camera takes care of it over a very low speed interface - because it's a very, very low quality camera. That's not the kind of camera someone wants in pretty much any modern consumer device.
If there's a camera people will want something with a real resolution and frame rate, something that you will not be able to pipe through a little STM32F.
So you're talking about putting all this stuff on the card? At what point does that defeat the purpose?also, there are variants of the STM32F that will do I2S. so you could wire up a decent MAXIM CODEC if you wanted to. i think they're the 120mhz variants, so they cost a little bit more. ST Microelectronics have an application note on using these faster STM32Fs for *decent* audio. the only reason i picked PWM is because it looked "good enough" for a tablet, and i was running out of pins
There's a reasonable baseline for audio quality that's suitable for all iterations of Pandora 2 for many years. That means you put it off the card. That means the card needs to expose the right interfaces, far more than you're exposing.
Have you actually listened to what the PWM you're speccing sounds like? Or talked to someone who has experience with quality audio? And why do you think people have lower audio standards for a tablet?
Well that's an even worse problem then, your specification is way too limiting for bringing out interfaces to things you'd want on a Pandora 2 PCB and there's no way to gain access to those headers (not sure why you put them all there then)
Not sure what this microcontroller's role is in camera for your board anyway, it's not like it can provide any high speed interfaces for it...
Have you actually looked into the specifications of the GPIOs? You can't run them every cycle at 72MHz, then you have to bitbang PCLK.. Let's say you manage something like 16MB/s of data, plus overhead of the signaling/blanking.. so maybe you can do 640x480x24bpp @ 18FPS? Maybe? I mean, have you really tested this? You should try it before basing your whole design and a bunch of claims around it..
Oh, and the processor is of course fine managing bit-banging the camera while doing audio, keyboard, mouse, battery management, etc at the same time right?
They're just called analog inputs.
So are you saying now the so-called standard for this connector is anything we device? How can it be interchangeable when there could be random analog signals on any given pin?
Again, the connector is the limiter. Any SoCs that would be interesting for Pandora 2 already have several MMC/SD ports.
Even if somehow you can customize the connector arbitrarily there are simply too few pins on it.
Of course you're missing something - yes the STM32F can run SD full speed but how is the main SoC talking to it? These are embedded processors, not really well designed to be slaves to bigger things, so they don't have an external bus that can be operated externally for instance (the ones that even have an external bus at all have a pretty slow one).
The CPU module in a Pandora 2 should not have ANY SD card slots. Let me reiterate this again - the entire point of using a separate module for the expensive CPU/RAM/PMIC combo is to reduce costs of having to replace them if something else on the board breaks and to reduce the cost of being able to upgrade it. Things like audio controller, SD, button inputs, wifi, LEDs, connectors, etc - these are things that won't have a huge demand to be changed and are also things that are more prone to mechanically failure. You don't want to have respin all this stuff for each main module.
You totally missed the point of that sentence. I don't care about Allwinner, I'm just trying to reason why you want to include functionality externally that most SoCs already include, and thought maybe it's because you're too used to crippled chips.
Also don't know why you asked me to stop focusing on Allwinner then went on defending them..
I'm not going to bother with the rest of what you posted, I feel like it's totally irrelevant - if you want to encourage OPT to use a modular approach that's already determined. If you want to encourage them to use YOUR module approach then I see way too many downsides.
This too. Although compact flash still adds substantial thickness to the CPU module PCB (while just needing a second board itself probably wouldn't add more thickness than the connectors already dictate).
Last edited by a moderator:
hiya exophase - there's too much here for me to correct first before being able to move forward, which says that you've an approach in mind and have already made up your mind, therefore it really doesn't matter what i say, because if i speak up and correct the assumptions it makes me "look bad" because i have to fight with you over those assumptions and corrections, and if i don't speak up then you will appear to be correct because the mistaken assumptions already make you conclude that this is not a viable approach.
so i think i'm going to leave this discussion - there's nothing that i can say which will help you because you've already made up your mind - other than to mention that i will be back when the team in spain i've been helping out have completed their EOMA-68 hand-held console that they've designed, to let people know where they can order it.
apologies to anyone following this thread who may have been hoping for an upgradeable pandora games console.
so i think i'm going to leave this discussion - there's nothing that i can say which will help you because you've already made up your mind - other than to mention that i will be back when the team in spain i've been helping out have completed their EOMA-68 hand-held console that they've designed, to let people know where they can order it.
apologies to anyone following this thread who may have been hoping for an upgradeable pandora games console.
I think that, because of the size constraints it would be better if everything needed for basic pandora operation was on one board, and secondary peripherals on another.
I'd have one board, much like the current pandora mainboard but without the nice DAC, with only one memory card slot (perhaps microSD), without a USB hub; making it simpler and cheaper.
Then add another 15cm x 8cm board below it with DAC, with SDXC, with GPS, with accelerometer, with vibrator motors, USB hub, space for hacking, whatever
You could leave out the lower board for compactness, replace the upper one for better specs and/or replace the lower one for more features
----
I'll be interested to see an EOMA-68 handheld, but still can't see how it could work out in something pandora-like
I'd have one board, much like the current pandora mainboard but without the nice DAC, with only one memory card slot (perhaps microSD), without a USB hub; making it simpler and cheaper.
Then add another 15cm x 8cm board below it with DAC, with SDXC, with GPS, with accelerometer, with vibrator motors, USB hub, space for hacking, whatever
You could leave out the lower board for compactness, replace the upper one for better specs and/or replace the lower one for more features
----
I'll be interested to see an EOMA-68 handheld, but still can't see how it could work out in something pandora-like
Last edited by a moderator:
Exophase
Nothing good will ever come of Exophase.
You sound like you're under the impression that I'm somehow in charge of Pandora 2. I'm not. I haven't made up my mind about anything and it's not really fair to assume I'm just predisposed against you; I think that your proposal has several technical flaws with them. If I have misunderstood something explain it, or say nothing - posting that I'm wrong about everything but that you can't explain how or why is not helpful and makes you look worse than however bad you think you'll look by defending your product and concept.
Maybe things are getting a little lost in all the back and forth, I'll try to make this clear and as succinct as I can. If I'm fundamentally misunderstanding something here then tell me.
1) EOMA-68 gives you a fixed interface of 68 pins that is meant to be interchangeable with other device. That means the pins must have fixed functions as per your specification, and must follow a fixed form factor except with maybe the length being only a minimum (but I'd hate to have an oversized card sticking out of a device). You spell out all the interfaces in schematics and here http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68 but they are as follows: parallel RGB, I2C, USB, ethernet, SATA3, and 8 GPIOs.
1a) IMO these functions aren't a great fit for Pandora 2 which wouldn't use SATA3, probably wouldn't want ethernet, and wouldn't want parallel RGB (lesson learned in Pandora 1, a small serial cable is better). 8 GPIOs is too few for Pandora's controls which needs at least 13 before factoring in the keyboard. Your specification dictates that all cards must have SATA controllers, parallel LCD, and ethernet so these are wasted costs where not needed.
1b) PCMCIA form factor is very thick for a handheld that also needs a full PCB for keyboard.
1c) Compact Flash is 50 pins and will inevitably suffer more severe problems if you try to fit in anything similar to this specification.
2) If you want additional features than what can or should be done over the 68-pin interface they have to be added as extra customizations on the board. There's a limited amount of space on the PCB and more importantly you are highly limited in how many connectors you can fit on the end.
2a) Polls on this forum show at least one full SD slot and at least one full USB + mini or micro USB to be pretty much non-negotiable. Can you fit that?
2b) Having all the stuff on the main board means that if the board is upgraded you have to include all those features again.
3) You say pick what we want and give it to you and you'll design it. So do you envision making the board for Pandora 2, or are you encouraging them to make their own EOMA-68 board, or is either good for you? Because if you're encouraging them to subcontract to you that sounds like a bad idea, unless you can amortize costs greatly with huge volume for a custom Pandora part (not seeing this happening). As far as experience goes, yes OPT is inexperienced but aren't you even less experienced?
And let me stress again, citing these problems doesn't mean I or anyone is against the idea of an upgradeable Pandora (although I can see some particular pros and cons with that). These are problems I see fitting your particular design with Pandora.
The whole thing about the STM32F's feasibility for those other functions is basically a whole different topic.. If this card type were used for Pandora there's no way it'd use an STMF32 for the features you want it to, that's just a given. The SoC + PMIC would handle most of it and there's no way the audio quality would be acceptable. So when I talk about technical feasibility of this it's more to see if you have an understanding of just how bad using it for audio and camera will be.
First of all.. you talk about talking to a camera directly with the microcontroller. How is this possible? CSI needs differential data and clock signals. You can't do this over GPIOs, you need a transceiver. You can do the command part over I2C but that's only part of the story. You gave an example of an STM32F interfacing a very low resolution camera (that I can't find a reference to). What I did find your blog reference to was using this: https://www.sparkfun.com/products/8667 That's not just a camera but a camera module that includes a camera controller, so you really are including one and the STM32F really isn't the controller. The price of this module speaks for itself. And how do you interface this to the card? You need to use those 8 GPIO pins for the data bus.. then you need the data clock input somewhere, to go to the microcontroller to step the DMA.
For audio and PWM, I've explained as much as I can the limitations, I hope you understand them well (I saw on your blog you talked about using a 1MHz PWM for good quality - this is concerning, 1MHz would sound terrible). Not sure if the PWM limit is 36MHz or something lower, but I do know no matter what you won't be able to get the same quality as the 12-bit DACs, which makes me wonder why you don't use PWM for the volume control and the DACs for the audio output. If you must have it done by this chip.
Exophase
Nothing good will ever come of Exophase.
Okay, I think I was misunderstanding one thing earlier, that the STM32F was supposed to go on the cards and not off of it. Kind of hard for things to be clear when the posts had a lot of "hey here's some PCB drawings!".. anyway, that does change some things - the camera, sound, additional I/O etc going through the STM32F makes more sense now.
But that brings it all back to a really major problem.. how on earth is this microcontroller communicating all that to the card? By shoving it all down one I2C and USB line? The STM32F is supposed to be acting as all these USB interfaces simultaneously? That bandwidth is just not there..
I thought audio would come off a connector on the EOMA-68 card, but I guess not. So you really are in a bind here, unless you provide a USB or I2C to I2S bridge to get audio off the card and onto competent external hardware to handle it. I can see why you wanted to try to make everything go through this STM32F chip but that was just cheaping out, apparently you pretty much need something like that to make this work.. not good.
But that brings it all back to a really major problem.. how on earth is this microcontroller communicating all that to the card? By shoving it all down one I2C and USB line? The STM32F is supposed to be acting as all these USB interfaces simultaneously? That bandwidth is just not there..
I thought audio would come off a connector on the EOMA-68 card, but I guess not. So you really are in a bind here, unless you provide a USB or I2C to I2S bridge to get audio off the card and onto competent external hardware to handle it. I can see why you wanted to try to make everything go through this STM32F chip but that was just cheaping out, apparently you pretty much need something like that to make this work.. not good.
Last edited by a moderator:
monstercameron
Well-Known Member
yes, according to a.seigo of the kde vivaldi tablet
Exophase
Nothing good will ever come of Exophase.
The card connector has a 24-bit parallel RGB output for displays (and micro-HDMI out the insertion end). So yes, that's standard here AFAIK, at the expense of a huge number of pins on a limited connector. Pandora 2 would benefit from a much more narrow serial display connection as has become more common these days.
Similar threads
