Thats very insightful..And you are?> > >Zarakava wrote: > >> Hi All, >> I am a mobile application developer > >You are STUPIDENT > > > >and this is the first time i >> have entered into developing an embedded application from scratch. Iknow>> that the title is a bit misleading and there will be rebuts in thegrounds>> that Android is an OS and Qt is a framework and C/C++ is a language. Letme>> explain my requirement. >> I need to develop an embedded device which will be installed in avehicle>> and it will periodically send telemetrics data to the cloud serverusing>> GSM modem. The telemetrics will include >> 1. GPS position data >> 2. Accelerometer readings >> 3. Image/Video data >> 4. It needs to light up a bulb on the device to visually indicate rash >> driving to the driver based on algorithms derived from >> acceleration/deceleration values >> >> I am looking forward to suggestions in the following areas:- >> >> 1. How to select an appropriate processor, sensor components? Who will >> design the board? Do the silicon suppliers provide consultancy in thatarea>> or does an hardware engineer select the processors, components anddesigns>> the board,the board design is then given to the silicon supplier as madeto>> order specs? >> 2. Android: Is it feasible to to port Linux for Android. Then portAndroid>> on top of that. Write Android ready device drivers and then hook it tothe>> Android APIs. Then write an Android application. My device will not havea>> display or a HMI. So is Android really adding value to my solution andis>> it worth to go through all the efforts mentioned above? >> 3. Qt: I am least experienced in Qt. But my understanding is that Qtcan>> take place of Android as an application framework. The process and >> questions pretty much remain the same as for Android. >> 4. C/C++: Or write C/C++ programs which will directly interact with the >> device drivers and achieve the need. >> >> Thanks a Ton! >> >> >> >> --------------------------------------- >> Posted through http://www.EmbeddedRelated.com >--------------------------------------- Posted through http://www.EmbeddedRelated.com
Android vs Qt vs C/C++
Started by ●December 15, 2011
Reply by ●December 20, 20112011-12-20
Reply by ●December 20, 20112011-12-20
On Dec 20, 6:33=A0am, "Zarakava" <biju@n_o_s_p_a_m.binaryveda.com> wrote:> Yes Tim. You got the requirement right. > Linnix, I had already followed up on your query. > Ok. Now the situation is that the client wants to start with a clean slat=e.> So the choices right from processor to sensors,kernel/OS,Coding platform > are open. > Tim, I read something about real time OS vxWorks. Are you pointing to > something like that or much lighter than that. > We are currently in the middle of talking to hardware engineers here who > can help us with the proper selection of components.Do your engineers have internet? Why can't they ask questions here?> Given the requirement any suggestions for > 1. Processor > 2. Sensors > 3. OS >Can you beat a <$200 design like this? Box System chip: Qualcomm MSM7627 Processor: Single core, 600 MHz System memory: 256 MB RAM / 512 MB ROM Built-in storage: 102 MB Storage expansion: Slot Type: microSD, microSDHC Maximum card size: 16 GB Camera Camera: 3.2 megapixels, Immobile Flash: LED Features: Auto focus, Macro mode, White balance, Effects, Self- timer, Panorama, Scenes Camcorder: 640x480 (VGA) Multimedia Music player: Supported formats: MP3, AAC, AAC+, WMA Video playback: Supported formats: MPEG4, WMV, 3GP, 3G2 Streaming: Yes Sensors GPS, ACC Interface Slider keyboard, touchpad. OS Linux 2.6, Android 2.2
Reply by ●December 20, 20112011-12-20
Linnix i dont understand the basis of your arrogance. Why my engineers do not ask questions here should not be your concern. I am asking questions here to learn and understand. If providing help towards that without posting your not so very witty comments is too much to ask, please ignore the post as there are better people providing valuable responses. please dont cloud that. As far as the specs go, you are not inline with my requirements. yet. thanks>On Dec 20, 6:33=A0am, "Zarakava" <biju@n_o_s_p_a_m.binaryveda.com> >wrote: >> Yes Tim. You got the requirement right. >> Linnix, I had already followed up on your query. >> Ok. Now the situation is that the client wants to start with a cleanslat=>e. >> So the choices right from processor to sensors,kernel/OS,Codingplatform>> are open. >> Tim, I read something about real time OS vxWorks. Are you pointing to >> something like that or much lighter than that. >> We are currently in the middle of talking to hardware engineers herewho>> can help us with the proper selection of components. > >Do your engineers have internet? Why can't they ask questions here? > >> Given the requirement any suggestions for >> 1. Processor >> 2. Sensors >> 3. OS >> > >Can you beat a <$200 design like this? > >Box > System chip: > Qualcomm MSM7627 > Processor: > Single core, 600 MHz > System memory: > 256 MB RAM / 512 MB ROM > Built-in storage: > 102 MB > Storage expansion: > Slot Type: > microSD, microSDHC > Maximum card size: > 16 GB > >Camera > > Camera: > 3.2 megapixels, Immobile > Flash: > LED > Features: > Auto focus, Macro mode, White balance, Effects, Self- >timer, Panorama, Scenes > Camcorder: > 640x480 (VGA) > >Multimedia > > Music player: > Supported formats: > MP3, AAC, AAC+, WMA > Video playback: > Supported formats: > MPEG4, WMV, 3GP, 3G2 > Streaming: > Yes > >Sensors > > GPS, ACC > >Interface > > Slider keyboard, touchpad. > >OS > > Linux 2.6, Android 2.2 >--------------------------------------- Posted through http://www.EmbeddedRelated.com
Reply by ●December 20, 20112011-12-20
On Tue, 20 Dec 2011 08:33:08 -0600, Zarakava wrote: (Top posting fixed)> >>On Mon, 19 Dec 2011 12:24:37 -0800, linnix wrote: >> >>> On Dec 19, 10:58 am, Tim Wescott <t...@seemywebsite.com> wrote: >>>> On Mon, 19 Dec 2011 10:44:35 +0100, David Brown wrote: >>>> > On 18/12/2011 17:00, Tim Wescott wrote: >>>> >> On Sun, 18 Dec 2011 09:52:05 -0600, Tim Wescott wrote: >>>> >>>> >>> On Thu, 15 Dec 2011 22:02:10 -0600, Zarakava wrote: >>>> >>>> >>>> Thanks Tim. >>>> >>>> Even though i am not looking at using Android now, but there is > no >>>> >>>> Android port available for 68K processor right. So in the same >>>> >>>> manner, will the choice also limit availability of compatible >>>> >>>> OS, tools etc. >>>> >>>> >>> There might be a Linux port for the 68K -- check Debian to see >>>> >>> what's current. Straight Linux, if you do anything at all that >>>> >>> big, is probably the way to go. >>>> >>>> >> I just checked -- the Debian port for 68K is "unofficial", but >>>> >> they say they're reviving it. >>>> >>>> > There certainly is Linux for the 68K, though it's not much used > these >>>> > days. There was a time when Linux on Coldfire was very popular for >>>> > small NAT routers, but I believe most of the market share here has >>>> > been lost to MIPS SoCs. Linux on "real" 68xxx devices was popular > a >>>> > long time ago, such as on pre-PPC Macs. >>>> >>>> > I don't think Debian would be the best starting point for Linux on >>>> > a Coldfire. I would start my search with ucLinux - ColdFire was >>>> > one > of >>>> > the two main targets for the MMU-less Linux, as many Coldfire's > don't >>>> > have an MMU, and even though the v4 core has one, it's a bit > limited, >>>> > and you might choose to run without it. MMU-less Linux has been >>>> > incorporated into the mainline kernel for many years, but looking >>>> > up ucLinux might give useful information. >>>> >>>> I kinda mentioned this in another post, but I should reiterate it > here: >>>> >>>> I would seriously question the need for something as heavy-weight as >>>> Linux for this application at all. >>>> >>>> Any old real-time kernel, or even a thoughtfully-constructed task > loop, >>>> should do the job just fine. Linux is certainly overkill, although > it >>>> wouldn't necessarily prevent things from working. >>> >>> I would say the same (overkill) for the hardware, except for the >>> image/ video. I just don't understand the need for the image/video >>> chip. Is this driver assistant for the blind? >> >>Could be for big-brothering commercial drivers or cops. Having post- >>crash video to prove innocence or to settle quickly if your driver was a >>bad boy would have some value. > > Yes Tim. You got the requirement right. Linnix, I had already followed > up on your query. Ok. Now the situation is that the client wants to > start with a clean slate. So the choices right from processor to > sensors,kernel/OS,Coding platform are open. > Tim, I read something about real time OS vxWorks. Are you pointing to > something like that or much lighter than that.VxWorks is as bad as Linux. I'm pointing to something much lighter than that. As I said, one could probably do this job without an OS at all, just run bare metal with a task loop. I'm a bit concerned for you, because this is one of those "if you have to ask, you can't do the job" sorts of things -- you need to get yourself one or two good books on embedded systems programming, and read them fast. Yes, you could do this on machine running Linux or VxWorks -- but your total machine load (both memory and processor usage) would be something like this: .----------------------------------------------.--------. | | | | LINUX LINUX LINUX LINUX LINUX LINUX | appli- | | LINUX LINUX LINUX LINUX LINUX LINUX | cation | | | | '----------------------------------------------'--------' You _could_ do this, but unless your production volumes were really low it's not going to pay back very fast. I'd do this with one of the many itty-bitty single-thread multitaskers out there, like Micro-C/OS-2, or FreeRTOS, (or maybe ucLinux, but I don't know enough about ucLinux to say). Or, like I said, I'd just do it in a task loop.> We are currently in the > middle of talking to hardware engineers here who can help us with the > proper selection of components. Given the requirement any suggestions > for 1. Processor > 2. Sensors > 3. OS1: This depends on your volume, but unless it is huge use one of the many ARM Cortex parts out there. NXP, TI, and nearly everyone else on the planet has them. The Atmel and Microchip 32-bit parts are candidates, too. 3: See above. 2: To do this right would require some careful assessment of what your client wants, and what's available on the market. It's not something I'd do for free. For free, I'll point out that Analog Devices seems to be the biggest name in inertial sensors, at least for low and moderate volume production. There are others, but the names slip my mind. Google is your friend. There is a very strong correlation between the quality of output from an inertial sensor and the amount of money you pay for it -- once you've zeroed in on one or two that'll do the job for you, you can almost find equivalents just by looking at price tags. So you really need to know just how good of a sensor you really need before you go shopping for the "world's best bargain" (which may be useless to you in the end), or the "world's best sensor" (which is currently in orbit, having proved an element of the theory of relativity, and has a cost approaching a billion dollars).> Also i was looking at the possibility of starting to develop the > application on a DIY board till the time the actual board prototype is > ready. Will that be a good idea? >Yes, sort of. I suggest that rather than looking to the DIY market first, you start by looking at manufacturer's processor evaluation boards. The DIY market tends to get stuck on older processors that are easy to get in qty 1; these aren't always the most cost effective (or capable) processors out there, and they sometimes aren't even easy to get reliably in large quantity (Atmel has a spotty delivery record, for instance). Manufacturer's eval boards not only work right off the bat, but you usually get better tools with them, and they're for processors that the manufacturer thinks (or wants) to sell going forward, not for processors that happen to be fashionable with hobbyists. But if the processor you want happens to be available on a DIY board that happens to have the features you want -- jump on it. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by ●December 20, 20112011-12-20
On Dec 20, 8:28=A0am, "Zarakava" <biju@n_o_s_p_a_m.binaryveda.com> wrote:> Linnix i dont understand the basis of your arrogance. > Why my engineers do not ask questions here should not be your concern. I =am> asking questions here to learn and understand. If providing help towards > that without posting your not so very witty comments is too much to ask, > please ignore the post as there are better people providing valuable > responses. please dont cloud that.Oh, OK. I was going to show you a 70g impact sensor for drop/crash detection. But i better hold my peace then.
Reply by ●December 20, 20112011-12-20
Thank you Tim. Will get going with the books. Thanks again>On Tue, 20 Dec 2011 08:33:08 -0600, Zarakava wrote: >(Top posting fixed) >> >>>On Mon, 19 Dec 2011 12:24:37 -0800, linnix wrote: >>> >>>> On Dec 19, 10:58 am, Tim Wescott <t...@seemywebsite.com> wrote: >>>>> On Mon, 19 Dec 2011 10:44:35 +0100, David Brown wrote: >>>>> > On 18/12/2011 17:00, Tim Wescott wrote: >>>>> >> On Sun, 18 Dec 2011 09:52:05 -0600, Tim Wescott wrote: >>>>> >>>>> >>> On Thu, 15 Dec 2011 22:02:10 -0600, Zarakava wrote: >>>>> >>>>> >>>> Thanks Tim. >>>>> >>>> Even though i am not looking at using Android now, but there is >> no >>>>> >>>> Android port available for 68K processor right. So in the same >>>>> >>>> manner, will the choice also limit availability of compatible >>>>> >>>> OS, tools etc. >>>>> >>>>> >>> There might be a Linux port for the 68K -- check Debian to see >>>>> >>> what's current. Straight Linux, if you do anything at all that >>>>> >>> big, is probably the way to go. >>>>> >>>>> >> I just checked -- the Debian port for 68K is "unofficial", but >>>>> >> they say they're reviving it. >>>>> >>>>> > There certainly is Linux for the 68K, though it's not much used >> these >>>>> > days. There was a time when Linux on Coldfire was very popularfor>>>>> > small NAT routers, but I believe most of the market share here has >>>>> > been lost to MIPS SoCs. Linux on "real" 68xxx devices waspopular>> a >>>>> > long time ago, such as on pre-PPC Macs. >>>>> >>>>> > I don't think Debian would be the best starting point for Linux on >>>>> > a Coldfire. I would start my search with ucLinux - ColdFire was >>>>> > one >> of >>>>> > the two main targets for the MMU-less Linux, as many Coldfire's >> don't >>>>> > have an MMU, and even though the v4 core has one, it's a bit >> limited, >>>>> > and you might choose to run without it. MMU-less Linux has been >>>>> > incorporated into the mainline kernel for many years, but looking >>>>> > up ucLinux might give useful information. >>>>> >>>>> I kinda mentioned this in another post, but I should reiterate it >> here: >>>>> >>>>> I would seriously question the need for something as heavy-weight as >>>>> Linux for this application at all. >>>>> >>>>> Any old real-time kernel, or even a thoughtfully-constructed task >> loop, >>>>> should do the job just fine. Linux is certainly overkill, although >> it >>>>> wouldn't necessarily prevent things from working. >>>> >>>> I would say the same (overkill) for the hardware, except for the >>>> image/ video. I just don't understand the need for the image/video >>>> chip. Is this driver assistant for the blind? >>> >>>Could be for big-brothering commercial drivers or cops. Having post- >>>crash video to prove innocence or to settle quickly if your driver wasa>>>bad boy would have some value. >> >> Yes Tim. You got the requirement right. Linnix, I had already followed >> up on your query. Ok. Now the situation is that the client wants to >> start with a clean slate. So the choices right from processor to >> sensors,kernel/OS,Coding platform are open. >> Tim, I read something about real time OS vxWorks. Are you pointing to >> something like that or much lighter than that. > >VxWorks is as bad as Linux. I'm pointing to something much lighter than >that. As I said, one could probably do this job without an OS at all, >just run bare metal with a task loop. > >I'm a bit concerned for you, because this is one of those "if you have to>ask, you can't do the job" sorts of things -- you need to get yourself >one or two good books on embedded systems programming, and read themfast.> >Yes, you could do this on machine running Linux or VxWorks -- but your >total machine load (both memory and processor usage) would be something >like this: > > .----------------------------------------------.--------. > | | | > | LINUX LINUX LINUX LINUX LINUX LINUX | appli- | > | LINUX LINUX LINUX LINUX LINUX LINUX | cation | > | | | > '----------------------------------------------'--------' > >You _could_ do this, but unless your production volumes were really low >it's not going to pay back very fast. > >I'd do this with one of the many itty-bitty single-thread multitaskers >out there, like Micro-C/OS-2, or FreeRTOS, (or maybe ucLinux, but I don't>know enough about ucLinux to say). Or, like I said, I'd just do it in a >task loop. > >> We are currently in the >> middle of talking to hardware engineers here who can help us with the >> proper selection of components. Given the requirement any suggestions >> for 1. Processor >> 2. Sensors >> 3. OS > >1: This depends on your volume, but unless it is huge use one of the many>ARM Cortex parts out there. NXP, TI, and nearly everyone else on the >planet has them. The Atmel and Microchip 32-bit parts are candidates, >too. > >3: See above. > >2: To do this right would require some careful assessment of what your >client wants, and what's available on the market. It's not something I'd>do for free. For free, I'll point out that Analog Devices seems to be >the biggest name in inertial sensors, at least for low and moderate >volume production. There are others, but the names slip my mind. Google>is your friend. > >There is a very strong correlation between the quality of output from an >inertial sensor and the amount of money you pay for it -- once you've >zeroed in on one or two that'll do the job for you, you can almost find >equivalents just by looking at price tags. So you really need to know >just how good of a sensor you really need before you go shopping for the >"world's best bargain" (which may be useless to you in the end), or the >"world's best sensor" (which is currently in orbit, having proved an >element of the theory of relativity, and has a cost approaching a billion>dollars). > >> Also i was looking at the possibility of starting to develop the >> application on a DIY board till the time the actual board prototype is >> ready. Will that be a good idea? >> > >Yes, sort of. I suggest that rather than looking to the DIY market >first, you start by looking at manufacturer's processor evaluation >boards. The DIY market tends to get stuck on older processors that are >easy to get in qty 1; these aren't always the most cost effective (or >capable) processors out there, and they sometimes aren't even easy to get>reliably in large quantity (Atmel has a spotty delivery record, for >instance). > >Manufacturer's eval boards not only work right off the bat, but you >usually get better tools with them, and they're for processors that the >manufacturer thinks (or wants) to sell going forward, not for processors >that happen to be fashionable with hobbyists. > >But if the processor you want happens to be available on a DIY board that>happens to have the features you want -- jump on it. > >-- >My liberal friends think I'm a conservative kook. >My conservative friends think I'm a liberal kook. >Why am I not happy that they have found common ground? > >Tim Wescott, Communications, Control, Circuits & Software >http://www.wescottdesign.com >--------------------------------------- Posted through http://www.EmbeddedRelated.com
Reply by ●December 20, 20112011-12-20
On 20/12/11 18:29, Tim Wescott wrote:> > Yes, you could do this on machine running Linux or VxWorks -- but your > total machine load (both memory and processor usage) would be something > like this: > > .----------------------------------------------.--------. > | | | > | LINUX LINUX LINUX LINUX LINUX LINUX | appli- | > | LINUX LINUX LINUX LINUX LINUX LINUX | cation | > | | | > '----------------------------------------------'--------' > > You _could_ do this, but unless your production volumes were really low > it's not going to pay back very fast. > > I'd do this with one of the many itty-bitty single-thread multitaskers > out there, like Micro-C/OS-2, or FreeRTOS, (or maybe ucLinux, but I don't > know enough about ucLinux to say). Or, like I said, I'd just do it in a > task loop. >ucLinux is like Linux, except that it doesn't use an MMU. So all processes are in the same address space, and you can't do a traditional fork (you can do a vfork). However, you would still get the same picture as with "normal" Linux. Before considering Micro-C/OS-2, read the fine print of the license - it's quite expensive. I'm not suggesting it is /too/ expensive - it's up to the buyer to decide if it's worth the money. But people often think of it as a small low-cost system, because it is very low cost to try out, and get surprised by the final bill.
Reply by ●December 20, 20112011-12-20
Thnak you David. I shall get back once i have educated myself on all the latest information provided here.>On 20/12/11 18:29, Tim Wescott wrote: >> >> Yes, you could do this on machine running Linux or VxWorks -- but your >> total machine load (both memory and processor usage) would be something >> like this: >> >> .----------------------------------------------.--------. >> | | | >> | LINUX LINUX LINUX LINUX LINUX LINUX | appli- | >> | LINUX LINUX LINUX LINUX LINUX LINUX | cation | >> | | | >> '----------------------------------------------'--------' >> >> You _could_ do this, but unless your production volumes were really low >> it's not going to pay back very fast. >> >> I'd do this with one of the many itty-bitty single-thread multitaskers >> out there, like Micro-C/OS-2, or FreeRTOS, (or maybe ucLinux, but Idon't>> know enough about ucLinux to say). Or, like I said, I'd just do it ina>> task loop. >> > >ucLinux is like Linux, except that it doesn't use an MMU. So all >processes are in the same address space, and you can't do a traditional >fork (you can do a vfork). However, you would still get the same >picture as with "normal" Linux. > >Before considering Micro-C/OS-2, read the fine print of the license - >it's quite expensive. I'm not suggesting it is /too/ expensive - it's >up to the buyer to decide if it's worth the money. But people often >think of it as a small low-cost system, because it is very low cost to >try out, and get surprised by the final bill. >--------------------------------------- Posted through http://www.EmbeddedRelated.com
Reply by ●December 20, 20112011-12-20
On Tue, 20 Dec 2011 22:15:21 +0100, David Brown wrote:> On 20/12/11 18:29, Tim Wescott wrote: >> >> Yes, you could do this on machine running Linux or VxWorks -- but your >> total machine load (both memory and processor usage) would be something >> like this: >> >> .----------------------------------------------.--------. | >> | | | LINUX LINUX >> LINUX LINUX LINUX LINUX | appli- | | LINUX LINUX LINUX >> LINUX LINUX LINUX | cation | | >> | | >> '----------------------------------------------'--------' >> >> You _could_ do this, but unless your production volumes were really low >> it's not going to pay back very fast. >> >> I'd do this with one of the many itty-bitty single-thread multitaskers >> out there, like Micro-C/OS-2, or FreeRTOS, (or maybe ucLinux, but I >> don't know enough about ucLinux to say). Or, like I said, I'd just do >> it in a task loop. >> >> > ucLinux is like Linux, except that it doesn't use an MMU. So all > processes are in the same address space, and you can't do a traditional > fork (you can do a vfork). However, you would still get the same > picture as with "normal" Linux. > > Before considering Micro-C/OS-2, read the fine print of the license - > it's quite expensive. I'm not suggesting it is /too/ expensive - it's > up to the buyer to decide if it's worth the money. But people often > think of it as a small low-cost system, because it is very low cost to > try out, and get surprised by the final bill.The last time I specified Micro-C/OS-II, it was a $1500, one time fee per board design (this was 10 years ago). The nearest competing "royalty free" license was $30000 for roughly the same thing. I called it "quite inexpensive". I forgot eCOS -- but then, I don't know how eCOS is fairing these days. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by ●December 20, 20112011-12-20
Tim Wescott wrote:> On Tue, 20 Dec 2011 22:15:21 +0100, David Brown wrote: > >> On 20/12/11 18:29, Tim Wescott wrote: >>> >>> Yes, you could do this on machine running Linux or VxWorks -- but your >>> total machine load (both memory and processor usage) would be something >>> like this: >>> >>> .----------------------------------------------.--------. | >>> | | | LINUX LINUX >>> LINUX LINUX LINUX LINUX | appli- | | LINUX LINUX LINUX >>> LINUX LINUX LINUX | cation | | >>> | | >>> '----------------------------------------------'--------' >>> >>> You _could_ do this, but unless your production volumes were really low >>> it's not going to pay back very fast. >>> >>> I'd do this with one of the many itty-bitty single-thread multitaskers >>> out there, like Micro-C/OS-2, or FreeRTOS, (or maybe ucLinux, but I >>> don't know enough about ucLinux to say). Or, like I said, I'd just do >>> it in a task loop. >>> >>> >> ucLinux is like Linux, except that it doesn't use an MMU. So all >> processes are in the same address space, and you can't do a traditional >> fork (you can do a vfork). However, you would still get the same >> picture as with "normal" Linux. >> >> Before considering Micro-C/OS-2, read the fine print of the license - >> it's quite expensive. I'm not suggesting it is /too/ expensive - it's >> up to the buyer to decide if it's worth the money. But people often >> think of it as a small low-cost system, because it is very low cost to >> try out, and get surprised by the final bill. > > The last time I specified Micro-C/OS-II, it was a $1500, one time fee per > board design (this was 10 years ago). The nearest competing "royalty > free" license was $30000 for roughly the same thing. I called it "quite > inexpensive". > > I forgot eCOS -- but then, I don't know how eCOS is fairing these days. >Looks fairly healthy: http://ecos.sourceware.org/ -- Les Cargill
