Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
There are many different RTOS available for microcontrollers. I am specifically looking for RTOS that support the ARM Cortex M processors. Also, I am not interested in closed source solutions.
Attempting to compare the relative merits of each RTOS from websites and mailing lists seems pretty difficult as they mostly seem to have equivalent features and do the same thing. The real differences become apparently only after trying to use each RTOS for some tasks.
I know this is somewhat subjective question and probably hard to answer - but there must be many people out there who have actually tried several different RTOS and formed an opinion of the relative merits of each one.
I am specifically interested in FreeRTOS, ChibiOS and Coocox CoOS, but other choices are also very welcome.
For example: it would seem that in ChibiOS, ISRs can call any system functions, but those calls must be wrapped in chSysLockFromIsr()/chSysUnlockFromIsr() and the code is not preemptable during those sections. In CoOS, the only functions callable are the ones starting with isr_ such as isr_PostSem(), isr_PostMail(), isr_PostQueueMail() and
isr_SetFlag(), but those functions internally use a service request queue which means most of the request is preemptable.
Some of the features that one could take into account while choosing the RTOS:
context-switch time
interrupt latency
synchronization mechanisms (flags, semaphores, mutexes, mailboxes, queues, ...)
priority inversion handling
memory management support (i.e. memory pools)
scheduling policies support
MMU support
process support
memory footprint
efficiency of the kernel itself
POSIX vs. non-POSIX API's
software eco-system available (a.k.a middleware)
...
Which point(s) to put more focus, depends on the very application you're going to run. But generally, these are the things I can remember of which make difference between various RTOS's.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I tried to search across the internet, but was unable to find something.
So question is: What is better to use? OS provided cryptographic API or manually implemented/library provided algorithms?
I know that, when CPU enters in kernel mode after OS system call, it consumes large amount of CPU cycles, but on the other hand I know that OS can use hardware accerelated cryptography. So what is situation in real world? Is it worth to use OS Cryptographic API?
For example project that I work on, uses CRC32 and MD5 algorithms.
EDIT: My primary goal is to select fastest approach and secondary is to know all cons and pros.
MD5 is probably available everywhere. CRC32 is so simple (and not really cryptography) that you can just include or implement it directly in your application.
The Windows crypto API supports multiple providers and the default provider is probably fully implemented in user mode without switching to kernel mode for most things. The PRng and AES encryption might be implemented in hardware.
What is your goal? Speed? No backdoors? Obscure algorithms?
There are hardware accelerators for TLS but are are used primarily for public key encryption. Unless you have specialized Bitcoin mining hardware, hashing will be done userside and in software. Use what is most convenient.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have the task to write some crypto stuff in C and make it lightweight. The idea behind making it lightweight is, that it could run on a smartcard which doesn't offer much computational power and memory. It won't come to actually running it on a smartcard and it won't be for any practical use.
However, I'm curious if I could run the program on a smartcard without major adjustments. I'm aware that I'd probably have to change something in the IO-part but let's keep that aside. And by "smartcard" I mean a regular smartcard which could be afforded by the majority of private individuals and not some fancy stuff.
To restrict the question a little more:
Could I run the program without modification if I only use 8-bit integers in my program and the architecture is >= 8-bit, aswell as stay below the memory limit?
If no, why not?
Due to their limited CPU power, SCs mostly have their own security/encryption hardware and OS. The latter for instance controls access to critical features like the interface and key storage. Also, some of them have countermeasures against typical attack scenarios like differential cryptoanalysis, etc.
There are standards available, but which to pick depends on the actual card used. There are various SCs on the market with different capabilities and demands.
It is unlikely that your program will run without major modifications.
Note that the specs are mostly only available under NDA and possibly with additional guarantees from your side. The actual level depends on the capabilities and the card vendor.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
What open-source implementation(s) in C for a pthreads thread pool would you recommend ?
Additional points if this implementation is :
Light-weight: glib, APR, NSPR and others come with a big buy-in, I'd rather have just 2 files (header and implementation).
Tested on several platforms (Linux, BSD, Mac OS X, etc.).
Still maintained.
I worked on making something I'd be able to use and I've published it on github: it's unimaginably called threadpool.
If your goal is light-weight, then the last thing you want is a prewritten, super-general-purpose, high-level-abstraction-based implementation. Implementing a thread pool yourself, suited to your particular task, is fairly trivial, but you might also question whether you actually need a thread pool or whether you'd be fine just creating and destroying threads as needed.
Without knowing more details about your application, I can't give much more specific advice. But the tools you might find useful are:
Condition variables
Semaphores
A job queue protected by a mutex
POSIX message queues
Here is an implementation with these features:
ANSI C and POSIX compliant
Minimal but powerful API
Synchronisation from the user
Full documentation
I once used this, which isn't actually an official implementation per se. It does use pthreads as you requested, and should give you some ideas of what you need to do. (See threadpool.h, threadpool.c, threadpool_test.c, and the Makefile for instructions on how to compile.) You'll obviously have to do some refactoring as it's original intention is probably different than yours. It's commented rather well actually.
Even though this deviates from the original question, I'd also like to mention that the newest C standard, unofficially C1X (see wikipedia, hyperlink limit), has planned support for threads N1570 (google it, hyperlink limit again!) (7.31.15).
Some personal advice from my experience would be to make sure that your application can actually be run in parallel, and if the overhead of creating a new thread is so high that you can't live without a thread pool. Personally I've blundered on both these parts and I've actually ended up with implementations slower than my single threaded application. Also, you might want to be aware of different problems, including cache-lockouts and misses, which would actually degrade the performance of your application.
I'm probably blabbering on by now, but best of luck.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I'm looking for a good online reference on typical implementation of synchronization primitives (spinlocks, mutexes, semaphores, read-write locks, conditional variables, ...) either in abstract c+atomics or pseudo-asm (i.e. any reasonable notation of the sequence of atomic operations performed) or x86 asm. Something that starts with the most naive implementations and then addresses their shortcomings and some of the approaches to solving the shortcomings would be great.
Try Tanenbaum's Operating Systems: Design and Implementation.
edit: or Modern Operating Systems. I think the 1st one includes Minix, the 2nd one doesn't. Not sure, sorry =(
It's academically oriented, so it'll get you started on the right path.
Not a complete reference by any means, but the following paper is a classic and essential for understanding the implementation of synchronisation primitives in Linux:
"Fuss, Futexes and Furwocks: Fast Userlevel locking in Linux", Franke Russell & Kirkwod, Proceedings of the Ottawa Linux Symposium 2002 - available (among others) at: http://www.cis.temple.edu/~ingargio/cis307/readings/futex0.pdf
From that and the glibc sources it's possible to learn a lot, but it's not what I'd call easy-going :-)
As a side note, if you just want atomic stuff and you'r using gcc you have some built in functions that you can use instead of asm.
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
But for specific locks you always have Wikipedia
http://en.wikipedia.org/wiki/Spinlock
http://en.wikipedia.org/wiki/Semaphore_(programming)
Also worth looking at is
http://en.wikipedia.org/wiki/Lock-free_and_wait-free_algorithms
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I'd like to use a virtual machine like NekoVM into a small device but to build it, it requires Boehm GC, however there is no port of that GC to that small device so I was wondering if there is any alternative to it, something that could be done exclusively with C code?
I'd say your best option would be to port the GC to your platform, for which there are instructions (libgc porting instructions).
Additionally, it should be possible to swap out the GC implementation (NekoVM FAQ), see vm/alloc.c file.
EDIT:
Hopefully useful additional links: (untested)
Smieciuch Garbage Collector
libgcroots (based on libgc 7, abstracts architecture dependant bits)
Squirrel programming language
Perhaps you'd be better off with Lua, which has a very small but powerful virtual machine, has its own garbage collector built in, and runs on any platform that supports ANSI Standard C. With just a little effort you can even build Lua on a machine that lacks standard input and standard output. I have seen Lua running on an embedded device that was a small LCD touch screen with an embedded CPU stuck on the back. Neko is good work, but I think you'll find Lua every bit as satisfying.
I could suggest TinyGC (tinygc.sf.net) - an independent lightweight implementation of the BoehmGC targeting small devices. It is fully API-compatible (even more, binary compatible) with BoehmGC v7+ but only a small subset of the API is implemented (but sufficient for Java/GCJ-like memory management) and there is no automatic threads and static data roots registration. The latter, however, may require some efforts to make NekoVM work with it (i.e., call GC_register_my_thread() and GC_add_roots()).