For most embedded needs Linux is a little too heavy. I recommend folks to take a look at Nuttx: http://nuttx.sourceforge.net/ This is POSIX and BSD licensed. May not support your chipset yet but the developer may help you port it.
For most embedded needs Linux is a little too heavy. I recommend folks to take a look at Nuttx: http://nuttx.sourceforge.net/ This is POSIX and BSD licensed. May not support your chipset yet but the developer may help you port it.
Thanks a lot guys for the suggestions.. Looking into it>Le 21/12/2011 13:07, Simon Clubley a =E9crit : >> On 2011-12-20, Tim Wescott<tim@seemywebsite.com> wrote: >>> >>> I forgot eCOS -- but then, I don't know how eCOS is fairing thesedays=>=2E >>> >> >> There's also RTEMS at http://www.rtems.com/ which is also open source. >> >> Simon. >> >FSL MQX RTOS could be an (free an lightweight ) alternative :=20 >http://www.freescale.com/webapp/sps/site/homepage.jsp?code=3DMQX_HOME&tid= >=3DSWnT > >Emmanuel > >--------------------------------------- Posted through http://www.EmbeddedRelated.com
Le 21/12/2011 13:07, Simon Clubley a =E9crit :> On 2011-12-20, Tim Wescott<tim@seemywebsite.com> wrote: >> >> I forgot eCOS -- but then, I don't know how eCOS is fairing these days==2E>> > > There's also RTEMS at http://www.rtems.com/ which is also open source. > > Simon. >FSL MQX RTOS could be an (free an lightweight ) alternative :=20 http://www.freescale.com/webapp/sps/site/homepage.jsp?code=3DMQX_HOME&tid= =3DSWnT Emmanuel
On 2011-12-20, Tim Wescott <tim@seemywebsite.com> wrote:> > I forgot eCOS -- but then, I don't know how eCOS is fairing these days. >There's also RTEMS at http://www.rtems.com/ which is also open source. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
On 21/12/11 01:06, 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. >I understood that Micro-C/OS-II required a fee per project, not per board design, and I believe the fee is quite a bit higher now. For a single project, that model will work well - and I'm sure that compared to other commercial RTOS's it is quite reasonably priced. But you'll quickly become concerned about the price if you have a lot of projects (but maybe there are site developer licenses, or something similar, also available). My point is not that it's a particularly expensive OS - just that people often think it is very cheap, free, or "free with the book".
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
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
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
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.
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