V1.3.0 - Adding important features like Send and Receive and WaitAny along a full DotMatrix example

Version 1.3.0

• NOW, I am thrilled to announce that AtomicX have send and receive functions that enables data transferring between two or more threads, allowing real client / server application strategy inside embedded and non-embedded application, this way, small MCUs can be used to easily transport stack data (which is protected in this thread system) to other thread.

• Ported and enhanced the DotMatrix project, it implements a full Dot Led Matrix scrolling text system with

  • Serial terminal
  • Telnet Terminal
  • UDP Trap (You can send a UDP message to IP/2221 and it will display, Ideal for trapping messages)
  • An amazing general log API based on iostream, capable of adding "Specialized Loggers", and add using logger.AddLogger:

        logger << LOG::ERROR << "Failed to start WiFi." << std::endl;

  • based on ESP8266 and 8 or 4 Dot Matrix leds array
  • Just connect the Led Matrix (Dot Matrix Modul 8x8 Display Matrix Max7219 Led Lcd with 8 or 4 8x8 display)

      Designed for NodeMCU ESP8266
      ################# DISPLAY CONNECTIONS ################
      LED Matrix Pin -> ESP8266 Pin
      Vcc            -> 3v  (3V on NodeMCU 3V3 on WEMOS)
      Gnd            -> Gnd (G on NodeMCU)
      DIN            -> D7  (Same Pin for WEMOS)
      CS             -> D4  (Same Pin for WEMOS)
      CLK            -> D5  (Same Pin for WEMOS)
  

• Added WaiTAny, that extends the Wait/Notify functionality, since it will also receive, and return by reference, ANY TAG. giving the developer ability to easily create a full Client / Service infra structure.

• Dropping BROKER functionality, and welcoming Broadcasting functionality, it will enable a thread to receive all broadcasts asynchronously sent by other threads, only by enabling it and implementing the handler :

      virtual void BroadcastHandler (const size_t& messageReference, const Message& message) 

  and enabling it using the code:

      SetReceiveBroadcast (true);

  The handler will deliver tree parameters:

  • size_t MessageReference that works like a reference of what is the message about;
  • size_t Message.message which is the message payload (could be even an pointer);
  • size_t Message.tag that can be used as a meaning for the message:

  Example:

  • messageReference=BROADCAST_IRCAMERA
  • Message.message=CAMERA_DONE
  • Message.tag=CAMERA_READINGS

  On this simple example using 'mnemonics', that could have been enum class or directives, a single message was able to inform asynchronously that a IR CAMERA just read something, but could have informed ERROR or even that it was READING...., the approach allows a powerful controller, since you can apply layers on your code making processing really fast and precise and less messages will travel across the systems.

• mutex and smartMutex now have timeout, by using lock(<timeout time>) and sharedLock(<timeout time>), if no timeout is given: lock() or sharedLock() wait indefinitely (fully back compatible with existing code)

V1.2.1 Adding manageable auto-stack, Timeout object, semaphores and DynamicNice for Threads

Version 1.2.1

• Adding Dynamic Nice, now it is possible to let the kernel set the best performance for your thread, for this SetNice(*initial nice*) and than SetDynamicNice(true) in the constructor of your thread. The kernel will be able to always adjust your thread for Best performance, but, it will leave no room for sleeps between threads, increasing power consumption, it is powerful but use it carefully.

• Added YieldNow() the higher priority context change, it will allow other threads to work, but will, also return faster than others

• smartSemaphore, Used to compliance with RII, once used in the thread context, it takes a semaphore to be initialized and expose the same methods, although it manages the local context, and ones it it gets out of context, due to leaving {} or a functions, for example the semaphore shared context is released if ever taken during the smartSemaphore instantiated object life cycle. The same is available for mutex, called smartMutex, follows the same principle.

• IMPORTANT, Introducing Semaphores, atomicx::semaphore(<How many shared>), now you can use methods (acquire() or acquire(timeout)) and release() along with GetCount, GetMaxAcquired, GetWaitCount and static method GetMax to return the maximum shared you can use to instantiate. Examples for Arduino and PC where also introduced and fully tested.

• Introducing atomicx::Timeout, this will help tracking a timeout over time, using methods IsTimedout and GetRemaining and GetDurationSince. Special use case, if the timeout value is zero, IsTimedout will always return false.

• IMPORTANT NOTIFICATION atomicx::lock has been renamed to atomicx::mutex for consistency, all methods are the same.

• Improvement Added a contructor for self-manager start to define a start size and increase pace. For example: a thread starts with 150 bytes and increase pace of 10, but used stack was 200, the kernel will do 200 + 10 (increase pace) to give it room to work. The default value is (1)

        /**
         * @brief Construct a new atomicx object and set initial auto stack and increase pace
         *
         * @param nStackSize            Initial Size of the stack
         * @param nStackIncreasePace    defalt=1, The increase pace on each resize
         */
        atomicx(size_t nStackSize, int nStackIncreasePace=1);

v1.2.0: Introducing Self-Managed stack memory

• INTRODUCING Self managed stack, now it is possible to have self-managed stack memory for any threads, no need to define stack size... (although use it with care) just by no providing a stack memory, AtomicX will automatically switch the tread to self-managed, to do just use atomicx() default constructor instead.

  Notes:
  * It will only entries the stack enough to hold what is needed if the used stack is greater than the stack memory managed.
  * No decrease of the stack size was added to this release.
  * In case your thread is not able to resize the stack, if it needs more, StackOverflowHandle is called.

Examples:
- Ardunino/Simple
- avrAutoRobotController

• Explicitly added the pc example shown here to to examples/pc as simple along with makefile for it.
  Also updated it to have an example of Self-managed stack memory as well.

v1.1.3: Add ability to create custom Wait/Notify

• Now developer can create custom Wait and Notify using asubType attribute (uint8_t and casting to aSubTypes), internally regular wait/notify uses aSubType::wait and aSubTypes::look for SyncNotify.

Notify was split into `Notify` and `SyncNotify`

Version 1.1.2

• *Important Notify was split into Notify and SyncNotify to avoid compilation ambiguity reported for some boards, all the examples have been migrated to use one of those accordingly and tested against all supported processors.

Syncronous Notify timeout (Waits threads to call Wait with revVar/Tag)

Release v1.1.1

• PLEASE NOTE No Spin Lock what so ever in this Kernel, it is working fully based on Notification event along with message transportation.

• NOTIFY are now able to sync, if a atomicx_time is provided, Notify will wait for a specific signal to inform a Wait for refVar/Tag is up. This is a important feature toward using WAIT/Notify reliably, while your thread can do other stuffs on idle moment

• avrRobotController simulator for Arduino, is introduced, to show real inter process communication, it will open a terminal and both commands are available: system - To show Memory, Threads and motor status and move <flot motor A> <flot motor B> <flot motor C>

Wait/Notify enhancements

Release 1.1.0

• finish() method will be call every time run() is returned, this allow special cases like eventual threads to self-destroy itself, otherwise the object would be only a memory leak.... see examples on main.cpp

• SmartLock RAII compliance, allow lock or shared lock to be auto release on object destruction.

• IMPORTANT Now Notifications (Wait/Notify) can be timedout. if Tick based time is given, the waiting procedure will only stay blocked during it. (NO SPIN LOCK, REAL STATE BLOCK)

• IMPORTANT LookForWaitings block for timeout time will a wait for specific refVar/tag is available, otherwise timeout, can be used sync wait and notify availability

• IMPORTANT Now Wait/Notify Tags, used to give meaning/channel to a notification can be se to "all tags" if Tag is zero, otherwise it will respect refVar/Tag