Difference between revisions of "BemixOS"

From SlugWiki
Jump to: navigation, search
m
m (12 revisions imported)
 
(4 intermediate revisions by one other user not shown)
Line 1: Line 1:
BemixOS is an attempt to standardize all the microcontrollers used in Bemix through a uniform software layer. The user will be able to send and recieve packets on the 4E network in the same way, regardless of what type of PIC is used or whether it is in the Bemis bathroom or the Walcott bathroom. Also, all the general purpose IO will appear to be the same even if it is multiplexed. There may also be built in support for devices such as LCD displays, seven segment displays, and matrix keypads.
+
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.
 +
 
  
 
==Interrupts==
 
==Interrupts==
Line 21: Line 28:
 
* automatic software debouncing of inputs
 
* 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.
 
* provide functions such as getButton(buttonAddress) and readButton(buttonAddress) that wait for a button push and simply read the IO Buffer, respectively.
 
 
==Novel IO Devices==
 
 
==LCD Display==
 
This will be based on sample code for a standard text LCD display.
 
  
 
==See Also==
 
==See Also==

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.


Interrupts

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.

4E Network

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

EEPROM

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.

IO Buffer

  • 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.

See Also