Serial Wombat
a general-purpose digital interface device for hobbyists, engineers and students

Did you know...

Serial Wombat Pin Mode Restrictions (Playing by the rules)

When creating a new pin mode for the Serial Wombat, the most important thing to remember is that your code is just one part of all the code that's running on the Wombat. Therefore, you need to "play nice" with the rest of the software. Among the most important rules:

1. Don't hog the processor. The Serial Wombat tries to service all of the 40 pins within the time allotted for each frame (by default, 1 millisecond). That's a lot of work to do in 1ms! Your pin mode should get in, make its decisions, set the output pins if necessary, and get out. It's usually a bad idea to do a "while" loop in your pin mode that waits for some event to occur. For this reason, most pin designs should be designed as state machines.
2. Don't declare global or static variables. Each Wombat pin has 10 bytes allocated to it for the pin mode. Two of these are the public data buffer, and 8 are for general purpose use. These bytes are maintained from call to call of your pin mode, so data you store there will stay there. If you need additional memory, use the get/set user_buffer functions to move memory in and out of the RAM allocated to the user. This is how functions such as the LCD drivers (which require dozens of bytes to store messages) work. 10 bytes may not seem like much, but when used efficently, you can achieve a great deal with it. Pin modes in which more than one pin work together (such as the Rotary Encoder, LCD driver, or Keypad decoder modes) can use the storage memory from those pins together. You can also use stack (automatic local) variables for temporary storage.
3. Don't declare too many local variables. Declaring too many locals can cause stack overruns, which can make the Wombat behave unpredictably. A pin mode shouldn't declare more than 16 bytes of local variables.
4. Don't use deep subroutine calls. Your pin mode should call at most one level deep into code you write. Calling many subroutines deep can cause stack overflows.

There are also a variety of rules when using the internal resources of the PIC microcontroller the Wombat is based on. Restrictions for using Timers, the SPI bus, EEPROM, and other resources will be discussed later.