Difference between revisions of "BemixOS"
m (12 revisions imported)
Latest revision as of 23:29, 25 August 2015
BemixOS is a uniform software layer that will sit between the user's program and the PIC's hardware. It currently parses 4E Network packets and handles multiplexed IO (in simulation). Future versions will support peripherals such as LCD displays and matrix keypads. The motivation is lowering the barrier to development. If a 4E Network enabled device takes a hours of coding rather than a weeks, more project will get done by (hopefully) more people.
The heart of BemixOS is the interrupt handler. Each hardware event such as the arrival of a byte over the 4E Network triggers an interrupt, i.e. the interrupt handler is called "by magic." BemixOS determines the cause of the interrupt and dispatches control to the appropriate handler. For example, the 4E Network reception handler determines if the current packet is addressed to the device and, if it is, buffers it. BemixOS sets a hardware timer to interrupt the user's code at regular intervals. Currently this is used to switch the multiplexed IO lines.
Software interrupts are emulated. These allow for communication between the user's code and BemixOS. Rather than know the addresses of all the BemixOS buffers and functions (which are implementation, compiler, and processor specific), the user need only branch to a certain memory address with a request code in a certain register.
All communication between the user's code and BemixOS is done though software interrupts, either directly or through a buffer whose address is obtained though an interrupt. All transfer between the two processes happens through hardware interrups and jumps to a single know location in program memory. By keeping the interface clean, it should be possible to compile BemixOS such that its binary can simply be concatenated with the user's binary to form a complete working program. This is worthwhile because the PICs can write to their own program memory. Upgrading a device in a remote location would be as easy as transfering the user's binary over the 4E Network.
BemixOS will interrupt on a timer in order to perform IO and other tasks.
In general, a call to a BemixOS output function simply sets the appropriate interrupt flag and the interrupt handler does the real work of transferring the output buffer. BemixOS input functions simply read from a buffer. It is the responsiblility of the interrupt handler to fill the buffer, usually on each timer interrupt. This applies to the 4E Network and IO Buffer.
This be version 1.0 of the curruent version of the 4E network code. Improvements will include:
- fix collision bug where new packets overwrite old ones even if the new one has the wrong address
- fully interrupt driven reception and transmission
- imporved collision avoidence
- write in a way such that it is portable between PICs
- add error handling
BemixOS will provide support for reading and writing to the PIC's EEPROM. This will be used for storing the PIC's address, timer calibration values, passwords, and other user defined data that should not be hardcoded.
- buffer all general purpose IO, even if it goes directly to an IO port without multiplexing.
- automatic software debouncing of inputs
- provide functions such as getButton(buttonAddress) and readButton(buttonAddress) that wait for a button push and simply read the IO Buffer, respectively.