"Elder Costa" <elder.costa@terra.com.br> wrote> The thread [no pun intended, I suppose? - ed.] also > provided a lot of food for thought.Food for thought soon makes for mental indigestion. -- Nicholas O. Lindan, Cleveland, Ohio Consulting Engineer: Electronics; Informatics; Photonics. Remove spaces etc. to reply: n o lindan at net com dot com psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
I don't use an RTOS because...
Started by ●January 12, 2005
Reply by ●January 16, 20052005-01-16
Reply by ●January 16, 20052005-01-16
Elder Costa wrote:>What's your point after this totaly useless post?There is a way to influence what gets discussed in a newsgroup that works well, and another way that has never worked no matter how many people have tried it. What works: Posting articles on the topic you wish to see discussed, and participating in the resulting discussion. Using killfiles and filters so that you don't see the posts that you dislike. What doesn't work: Complaining about how terrible all those other posters are for not posting what you want them to post.
Reply by ●January 16, 20052005-01-16
Michael N. Moran wrote:> Ian Bell wrote: >> But it is worth noting that there is a significant lowering of >> reliability as soon as you move to a pre-emptive system. > > What a bunch of FUD. > I assure you that for an appropriate application > I can write a more maintainable and highly reliable > application with a pre-emptive scheduler. > > Do you have an facts to back-up that claim? > >I refer you to 'Patterns for Time Triggered Embedded Systems' by Prof. Michael J. Pont. Ian -- Ian Bell
Reply by ●January 16, 20052005-01-16
Tim Wescott wrote:> Michael N. Moran wrote: > >> Ian Bell wrote: >> >>> But it is worth noting that there is a significant lowering of >>> reliability >>> as soon as you move to a pre-emptive system. >> >> >> What a bunch of FUD. >> I assure you that for an appropriate application >> I can write a more maintainable and highly reliable >> application with a pre-emptive scheduler. >> >> Do you have an facts to back-up that claim? >> >> > I don't -- but all the SQA folks and software developers who I know > who've ever worked on really life-critical stuff (fly by wire and > medical) tend to view RTOS's with deep suspicion bordering on paranoia. > Basically it is _much_ easier to fully analyze the timing and > inter-element interactions of a system based on a task loop than one > based on an RTOS. >And let's be clear about this, an event loop can be a RTOS. My comment was aimed solely at pre-emptive ones. Ian -- Ian Bell
Reply by ●January 17, 20052005-01-17
"Ian Bell" <ruffrecords@yahoo.com> wrote in message news:csbs89$vgv$2@slavica.ukpost.com...> > No,no,no,no,no not unless you absolutely *have* to do floating point > arithmetic.I beg to differ. The Imagecraft AVR compiler for instance produces direct code for 8 and 16 bit operations, but calls lib routines when you use longs. Meindert
Reply by ●January 17, 20052005-01-17
>> >> So, you do write you C libraries yourself too ? >> > >99.999% of C library functions are irrelevant for small embedded systems so >what's to write?And what about malloc/free ?! It is commonly used as many discussion here show. - An how small is small ? Todays embedded systems range from a 6-pin PIC up to many-megabytes telecom routers. As for the RTOS I maintain we say all below 4K RAM is too small for _our_ RTOS (dynamic, message passing). -- 42Bastian Do not email to bastian42@yahoo.com, it's a spam-only account :-) Use <same-name>@epost.de instead !
Reply by ●January 17, 20052005-01-17
42Bastian Schick wrote:>An how small is small ? Todays embedded systems range from a 6-pin PIC >up to many-megabytes telecom routers.In my field we call 6-pin PICs "Supercomputers" because they have so much more capabilities than what we use...
Reply by ●January 17, 20052005-01-17
On Sat, 15 Jan 2005 14:03:14 +1100, Mike Harding <mike_harding@nixspam.fastmail.fm> wrote: [... C Library Functions ...]>Very rare that I would use any of the above. > >If I want to copy memory (for example) two pointers usually do >the trick. > >>sprintf is usually too large for the applications I work on. > >It "usually" is for me too - that why I said " very occasionally" >but a number of compilers provide cut-down versions.You roll your own memcpy, but pull in sprintf for simple string formatting? Permit me to shake my head in amazement... Regards, -=Dave -- Change is inevitable, progress is not.
Reply by ●January 17, 20052005-01-17
> You roll your own memcpy, but pull in sprintf for simple string > formatting? Permit me to shake my head in amazement...memcpy = frequently used function, large data moves, hand-optimization->speed optimization. The drive for a hand-rolled sprintf is totally different; the goal being to reduce memory footprint. If the compiler provides a cutdown version of the function, it can make sense to use it.
Reply by ●January 18, 20052005-01-18
On Mon, 17 Jan 2005 10:39:18 +0000, Guy Macon <_see.web.page_@_www.guymacon.com_> wrote:> >42Bastian Schick wrote: > >>An how small is small ? Todays embedded systems range from a 6-pin PIC >>up to many-megabytes telecom routers. > >In my field we call 6-pin PICs "Supercomputers" because they >have so much more capabilities than what we use...Out of curiosity, what are _you_ using, 1-bit serial CPUs (no joke, they exist). -- 42Bastian Do not email to bastian42@yahoo.com, it's a spam-only account :-) Use <same-name>@epost.de instead !
