The AVR8 DOS is AVR8 Device Operation System was developed as a substitution for the previously written DSC - Device System Control. The AVR8DOS is a type of a Hardware Control Layer which is perfroming control on the hardware of the microcontroller and providing functionality which provides control of the onboard hardware across the communication medium. The main usage area of this software is Internet of Things. In its base it has avr8cs and HCL code which is responsible for hardware managment.
The development of the code has reached some point, so the snode can exchange data with master node via ethernet, has service menu, can store configuration in EEPROM and restore it. The snode firmware is quite stable, the host code look like doing fine too. The code needs further development and at the moment the development was stopped.
The idea is quite simple and not fresh. More specific, the AVR8DOS firmware allows to convert AVR8 MCU to node which becomes managable i.e configuring or modifying the MCU's hardware layout without uploading new firmware and controlling its hardware across the network. The firmware contains required drivers for the onboard hardware and external hardware which can be attached to one of the MCU's I/O. When reconfiguration of the node is required, a system engineer can login to the text interface or use host's controlling library for the node from the host side and perform changes by sending specially crafted control commands.
Also, except remote managment, the main functionality of the firmware is to collect the data, control attached devices and of cause send data to the host.
The main pronciple of the whole system is:
The host side also known as MASTER performes all calculations, takes major decisions and receive data and generate commands. This can be: server, PC, embedded computer, etc. The node side also known as SLAVE performes onboard managment, receiving-executing commands, returns results, takes minor decisions in terms of handler's logic. This is Atmel AVR8, Arduino. etc.
So, in other words, master node does not care about the compatability of the sensors, output devices, measuring equipment, etc... It also does not care about how it is connected. The master node only performes calculations and takes decisions. The slave node takes responsibility on control and compatibility of the connections by attaching correct drivers to the port.
Below is a demo of what I have so far:
The above images demonstrates the service menu of the node.
The principle connection schematics is demonstrated below:
In the image above, slave nodes are connected to the master node using ethernet. It is not necessary that it will use only ethernet for intercommunication, but it is most flexible way to do so. Usage of other BUSes is also possible, but it sould be supported by firmware.
On the first image, the initial setup is demonstrated. THe device is initialized statically by scenario which is hardcoded to the firmware.
On the second image, the additional serial device was attached to USART1 and configuration was stored to EEPROM. After hard reboot, the firmware checks the EEPROM magic number. If magic number is the same with the hardcoded to firmware, the firmware performes restore of the layout according to the configuration stored in the EEPROM.
On the third image, there is demonstrated a configuration which is stored to EEPROM.
On the forth image, the registered streams (FILE, kstream).
On the fifth image, the list of the allocated I/O pins to the nodes (DID, port number, mask).
On the 21 of January 2017 the following functions of the firmware was implemented and partially tested:
Documentation will be available upon progress Examples will be available upon progress
Q: What is the purpose of this project?
A: This project does not have any specific targets or milestones or etc. I develop it from the previous project DSC, in my spare time, just for fun and to gain some expirience.
Q: Will I be able to use it in my project?
A: I hope so.
Q: What is this project about, I can not understand!
A: No problem! It will be more clear upon the some progress will be made on development. I will upload a video on the usage example.
Q: What about security?
A: As this project is for "home automatisation" and not for industrial or controlling any machines which probably can do harm to people in case of error. I am not trying to comply with any security standarts because it will take a lot of time. So, to improve physical security: use security (blocking) circuits don't completely rely on software. And to improve virtual security: limit access from internet to the internal network, use up to date software, limit physical access to the communication medium.
In terms of security, there are another problem which is quite hard to deal with because the AVR8 has quite small amounts of SRAM and it almost not possible to use encryption or controll messages integrity.
Q: Actual status of the development?
A: Development is suspended, because I want to switch all my spare time on the other projects, which I planned.