flit / argon-rtos Goto Github PK

Hi,
I'd like to use argon-rtos in my project which uses custom makefile. I noticed several problem during configuration of include paths.

Here, you have #include "argon/src/ar_internal.h".
Such include expects, that I have include path set to parent directory of repo clone and this clone directory is called 'argon'. Both conditions are kind of nonsense.
#include "../ar_internal.h" should be sufficient or just completely without path.

Here is similar problem. #include "argon/src/ar_config.h" This time it even collides with your suggestion hoiw to have custom config file:

"The recommended method is to copy the ar_config.h file to your application's source code tree and modify it."

There are other places where you just use #include "ar_config.h" and everything is fine.

Hi,
AFAIK IRQ handlers use current active thread stack. That means, every thread must have large enough stack to accommodate all IRQ requirements.

Is there any function which IRQ handler can call to switch to custom stack and then back?

When there is scheduled sleep longer than maximum systick period, sleeping times become imprecise. Sleep times are then multiples of systick maximum period, even the last one which would be probably shorter than that. Problem is this line https://github.com/flit/argon-rtos/blob/master/src/ar_kernel.cpp#L279. Systick is not reconfigured and stays at maximum period until it overshoots or matches nextWakeup time. Sleep is then longer than required.

I'll try to fix it and open PR

I have situation where I want to have multiple threads waiting for some event. Ar::Channel sounds like the proper way to let threads wait for event. Unfortunately event is consumed by first waiting thread. To deliver event to multiple threads, I've found this solution

while (channel.send(eventValue, 0) == kArSuccess);

Is there cleaner way?

Hi, I've tried to split todos and ideas into groups. Maybe the are in wrong one. I guess, you should be able to edit this post. Most of points come from doc/argon_todo.txt

Ideas

Timing

• Handle changing system clock by updating SysTick. Need to add API?
• High resolution timers. Tickless idle could be used to support timers with resolutions higher than a tick.
• Deal with wrapping of tick counter.
• Move to a solely tickless architecture.
• Replace tick counter with 64-bit microsecond time.

Features

• Add link from thread to object it's blocked on. (?)
• Unprivileged support?
  • Run kernel in privileged mode and use SVCall for most kernel APIs?
• Event flags?
• Handle a thread changing its own priority when it owns a mutex and has been hoisted in priority.
• Run main() in a thread.
• Replace main thread support with API to turn main() into a thread and start scheduler.
• Track time spent in scheduler. (requires microsecond <= timer resolution)
• Abstracted MPU support.
  • Protect thread stacks with MPU.
• Only defer irq operations if the kernel is locked, otherwise execute immediately.
• Main thread needs to be able to stop by returning from main()
• Add optional support for blocks.
• Consider possibilities of run-to-completion threads that share a stack.
• Need to be able to restart a thread once it has completed execution.
• Have an installable error handler to deal with errors in ctors. (?)
• Add kernel event recording/trace capability, with ability to report via ITM.
• Free dynamically allocated stack when thread is deleted.
• Add config option to compute thread stack usage and provide via ar_thread_get_report().

Refactoring

• Reduce kernel object sizes as much as possible.
• Move more internal stuff into Ar namespace.
• Channels only need one blocked list.
• ar_kernel_enter_scheduler() no longer does anything but call ar_port_service_call(). Merge the two.
• Use MSP for idle thread and timers. (?)
• Replace queue with buffered channel?
• Reset MSP when kernel starts so there is no wasted stack space.
• Make ar_kernel_run() set the current thread to the idle thread so the scheduler doesn't need a special case the first time it is executed.
• Add port kernel data struct so the extended frame flag can be included in g_ar. (Really useful?)
• Clean up enter_scheduler() vs ar_port_service_call() usage, switch threads.
• Separate tick timer routine sources so they can easily be replaced by the user (or make weak).
• Do we even need the suspended thread list? (used for cpu usage and thread reports)
• Limit channel and queue element size to a single word. (?)
• Return errors for non-zero timeouts in calls from timers, like for ISRs. (?)
• Can we replace the ar_list_node_t object pointer member with a calculation of node struct offset from the header of the containing kernel object struct?
• Change kernel flags to bool so writes are atomic. (this goes against kernel object size reduction)
• Use 16-bit atomic operations to reduce deferred action and runloop perform queue struct sizes (indexes).
• Make thread load computation work for tickless idle.
• Add thread stack usage to ar_thread_status_t and compute in ar_thread_get_report().
• Only run the scheduler when we know we need to switch threads. (maybe already the case)
• Only handle round-robin in the tick timer (except for tickless).

Language

• Use nullptr instead of NULL (provide compatibility macro for pre-C++11).
• Switch to using C11 or C++11 atomics? (increases code size noticeably)(maybe as a weak fallback?)

Api

• implement C api as wrappers allowing kernel to fully benefit from C++ features
• (Re) define a cleanup API for port
• Split ar_port sources (timing, generic,...)
• Add Thread::join()?
• Invert thread priorities, so that 0 is highest priority? This is the more common arrangement for RTOSes.
• Rename _halt() to ar_port_halt_cpu().
• Add a common header to kernel object structs with type and name pointer?
• Improve thread init and port APIs so the Thread class doesn't require an extra entry point wrapper.
• Change to a single ar_object_get_name() API?
• Change function pointer types to not be pointers, then make params etc pointers.
• Consider replacing special member function callback support with member function thunk class.
• Provide option to coalesce function calls added to runloop queue.

testing

• More thorough testing using cppunit. [Massive effort to get cppunit compiling under IAR.]
• Write an automated test suite.

Uncathegorized (need to move)

• Normalize channel and queue class send() and receive() methods' use of ptrs, references, or by value.
• Remove "m_" from kernel object member names since they are public and accessed directly?
• Remove need for idle thread by staying in scheduler until a thread becomes ready.
• Share a common timeout list for timers and blocked threads?
• Add config option for enabling dynamic stack allocation option, so malloc() is not required.
• Need a kernel object that can broadcast to wake up multiple threads.
• Let user allocate runloop function call queue.
• Remove queue and channel handler function support from runloops?

Issues

• Use of timers requires another stack.
• System load has garbage value if idle thread is only run to invoke timers.
• It's very unintuitive to have default ctor for sem, mutex, channel? not actually init the object.
• ? Sometimes deferred actions are not being executed as soon as the kernel is unlocked, or the kernel is not being properly unlocked, causing a situation where the deferred action queue can overflow.
• ? Idle thread will WFI sometimes when we don't want it to, like when running timers back to back.
• Blocking the idle thread will cause the scheduler to assert.

(Issue reported by @diggit.)

There is one more warning:

./argon-rtos/include/argon/ar_kernel.h:54:26: warning: ISO C restricts enumerator values to range of 'int' [-Wpedantic]
     kArInfiniteTimeout = 0xffffffffUL   //!< Pass this value to wait forever to acquire a resource.

static const uint32_t kArInfiniteTimeout = 0xffffffffUL; would solve this warning, do/don't? (same would apply to kArNoTimeout for consistency

Hi,
-Wunused and for me -Wunused-parameter is sometimes very handy.

As title says, it would be nice to have such warnings suppressed on functions, that intentionally not use some parameter.

Possible solutions are explained here on SO.

If you want this solved, which solution do you prefer?

Hi,
I am a little bit confused by Runloop usage.

• Can you explain some simple usecase?
• What is the advantage of using thread+runllop+timer instead of putting function call into thread with sleep?

Hi,
I noticed a problem with thread waking from sleep in tickless mode.
When there is thread synced (infinite timeout) by semaphore from ISR, whole system timing breaks.
All sleeps in other threads are much shorter.

Note: Now I am syncing using simple suspend and resume principle which works.
Not, it does not, same problem.

All static ctors are called before ar_kernel_run() which configures list predicates. This results in g_ar.readyList and g_ar.sleepingList being possibly unordered at kernel startup. This causes that lower priority thread may run forever even though higher priority thread is waiting to be served.

As title says, deferred queue send is almost useless, because if you want to send something from interrupt, its' lifetime probably ends with interrupt handler. Deferred send at the moment of handling deferred actions probably points to memory already used by different data. This little fact may cause very weird bugs.

Hi Chris,

I tried to import your project in Eclipse and I'm afraid your project configuration is somehow damaged, the imported project has no settings, and the build is impossible.

I suggest you unpack a fresh Eclipse, install the GNU ARM Eclipse plug-ins and try the Import from Git.

You'll notice that in C/C++ Settings the project has no Tool Settings.

I did the test on two different platforms (OS X and GNU/Linux) with the same result.

Regards,

Liviu
GNU ARM Eclipse plug-ins maintainer