Rabbit Semiconductor

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
Rabbit Semiconductor Inc.
Industry microcontrollers
Founded 1983
Headquarters Davis, California, United States
Owner Digi International
Website www.digi.com/lp/rabbit

Rabbit Semiconductor is an American company which designs and sells the Rabbit family of microcontrollers and microcontroller modules. For development, it provides Dynamic C, a non-standard dialect of C with proprietary structures for multitasking.

Rabbit Semiconductor was purchased in 2006 by Digi International.[1] Before the purchase, Rabbit Semiconductor was a division of Z-World, Inc. Z-World developed and manufactured embedded controller products as well as embedded software development environments.

Microcontroller architecture[edit]

The Rabbit processor family shares many features with the Zilog Z80/Z180 processors. For example, the registers of a Rabbit 2000/3000 processor are almost the same as the registers of a Z80/Z180 processor. The Rabbit 4000 processor expands to include the use of 32-bit registers. The instruction set of Rabbit processors also closely resembles the instruction set of the Z80/Z180 family. While the opcodes of many instructions are the same between the Rabbit 2000/3000 processors and Z80/Z180 processors, the two families of processors are not binary compatible.

The Rabbit processor family has unique features. For example, the Z80/Z180 family disables interrupts once an interrupt is serviced by an interrupt service routine. However, the Rabbit processors permit interrupts to interrupt service routines according to priorities (a total of 4).

As with the Z80/Z180 family, the Rabbit processors are CISC processors, as opposed to RISC competitors like the Atmel AVR processors. A comparison of clocks per instruction of the Rabbit processor against a typical RISC processor like the AVR reveals that even though the Rabbit processors can use a faster clock (up to 60 MHz), the effective processing power is comparable to that of a similarly-priced AVR processor using a slower clock (up to 32 MHz). For example, the "INC (IX+d)" instruction requires 11 to 13 clock cycles (depending on specific processor and on operand characteristics)[2] on a Rabbit processor. The equivalent instruction sequence (LDD, INC, STD) on an AVR requires 5 clock cycles.[3] Another example is the CALL instruction. It requires 11 to 13 clock cycles (depending on specific processor and on operand characteristics) on a Rabbit microprocessor[2] versus 4 to 5 cycles[citation needed] on an AVR processor. This difference, in part, is due to the AVR using on-chip memory for both instructions and data, whereas the Rabbit uses off-chip memory for both instructions and data.

Rabbit Semiconductor claims that the instruction set of Rabbit processors is optimized for C code.[4] A similar claim is made by Atmel for their AVR processors[citation needed]. The two architectures actually have very similar addressing modes, such as literal, register, indirect and indirect plus displacement. Furthermore, both architectures have specialized 16-bit registers. The Rabbit has IX, IY and SP, whereas the AVR has X, Y and Z.

The main difference is that the Rabbit instructions place more constraints on register usage compared to the AVR instructions. For example, the 8-bit Rabbit ADD instruction permits only the A-register be the destination. However, the ADD instruction of the AVR permits the use any one of the 32 8-bit registers as the source or destination. Generally speaking, an instruction set that is less register restrictive is more optimizable because there is less need to save-and-reload the content of a register.

Dynamic C[edit]

Perhaps the most notable feature of the Rabbit microcontroller is its development environment. Dynamic C, a product of Rabbit Semiconductor, has additions, deletions and inconsistencies compared to the ANSI-C standard.

(Reference: Porting a Program to Dynamic C-Rabbit Semiconductor)

Dynamic C follows the ISO/ANSI C standard when feasible and desirable. Because the standard does not take into account the special needs of embedded systems, it is necessary to depart from the standard in some areas and desirable in others. The standard does not take into account important embedded systems issues such as read only memory and embedded assembly language. For this reason, practical compilers intended for embedded systems do not completely comply with the standard, but use it as a guide.

As an example of an addition, Dynamic C has a chaining mechanism to chain fragments of code from different subroutines to an arbitrary number of chains. This extension permits the use of not only initialized variables, but any arbitrary code to execute before a program starts execution in the main function.

As an example of a deletion, as of version 10.23 Dynamic C does not support block scope variables or bit fields. The development toolchain does not include a separate preprocessor and linker, which may complicate the process of porting existing programs to the compiler. As of version 10.64 block scope for variables is supported.

As an example of an inconsistency, Dynamic C implicitly treats all initialized global variables as if they were declared with the const qualifier. Furthermore, all const variables reside in flash memory. Earlier versions of Dynamic C did not check the use of the const keyword in parameters—it was possible to pass a const variable as a parameter to a function that did not expect it, potentially leading to attempts to write to flash memory. As of the latest version of Dynamic C, the compiler will produce an error when the user attempts to modify a const variable directly, and will produce a warning if the user discards the const qualifier when passing a parameter to a function.

Multitasking constructs[edit]

One noteworthy feature of Dynamic C is its inclusion of language constructs to simplify multitasking. These constructs, the costate statement and the slice statement, implement a form of cooperative and preemptive multitasking, respectively. As an example, consider the following program which flashes two LEDs with different frequencies:

void main()
    while (1)
        // Create 2 costatements which will toggle our LEDs.

When this code is run, the first costatement will be executed, and the first LED will turn on. The costatement will then yield to the second statement while it waits for 100 milliseconds. The second costatement will execute in a similar manner. While both costatements are waiting for their time to elapse, the while loop will busy-wait, but this waiting time could potentially be used to perform other tasks. For more information, see the Dynamic C User's Manual.

See also[edit]


External links[edit]