EETimes

Embedded Systems September 2000 Vol13_10

Issue link: http://dc.ee.ubm-us.com/i/71837

Contents of this Issue

Navigation

Page 61 of 229

H64180 __ Context __ Switch: Save the current task's context PUSH main register set PUSH secondary register Get BBR and PUSH Save SP into the TCB of the task to suspend; Restore the new task's context Load SP from the TCB of the task to resume; POP and set BBR POP secondary register set POP main register RET segment of 32KB. The Rabbit makes it easy to have multiple stacks since the stack segment can be placed on any 4KB page boundary beyond phy - ical address OxODOOO. With the mem- ory configuration shown, we could have 64 stacks each having 512 bytes and thus have each stack segment hold the stack of eight tasks. Of course, we could split up the stack dif- fe re ntly between tasks because some tasks may require more or less RAM than oth ers. The XPC is similar to the BBR reg- ister of the 180-class processors but se ts th e bank ize to 8KB. The 8KB area act as a page rathe r than as a bank. This scheme is s. imilar to the very few extra cycles needed. The exception is the 16-bit multiply instruc- tion, which requires 12 cycles. Thi · is much better than the original Z80, which requires a minimum of three or four cycles per byte with many instruc- tions requi,-ing multiple extra cycles. Rabbit Semiconductor advertises the Rabbit 2000 to be four times fas ter than a Z80 when executing compiled C code on systems that have equal mem- ory access times. This is a due to a com- bination of improvements: • Every insu-uction executes in fewer clock cycles • New instructions improve the qual- ity of compiler generated code • Memory interface improvements permit higher clock speeds for the ame memory access time Finally, tl1e Rabbit 2000 contains a number of l/0 devices on chip: 40 parallel 1/0 ports, four asynchronous serial ports, numerous timers, a watch- dog timer, and in terfaces for memory chips. The register model fo r the Rabbit is shown in Figure 8 and is nearly iden- tical to the Z80 except for the addition of the following registers (shown in bold in Figure 8): XPC, IP, STACK- SEC, DATASEG, SEGSIZE. The EIR is the same as the I regis- ter on the Z80 and thus contains the uppe r byte of an interrupt vector table. The IIR replaces the R regi ter on the Z80. However, the IIR is used to point to an interrupt vector table spe- cific to intern ally ge ne rated inte r- rupts. The IP register i the interrupt pri- ori ty register. It contains four 2-bi t fields that hold a history of the proces- sor's inte rrupt priority. In fact, the Rabbit supports four levels of proces- sor priori ty. The Z80 and 180-class processors have only two: maskable and non-maskable. What I find partic- ularly useful i that you can save and restore the current interrupt priori ty level on the stack. This makes it a nat- ural for critical sections as shown in Listing 5. Memo ry management on th e Ra bbit is similar to the 180-class proces 01-s as shown in Figure 9, but it's more fl exible. There are four reg- isters in the Rabbit MMU: SEGSIZE, DATASEG, STACKSEG, and XPC. In Figure 9, I assumed a product might have 128KB of ROM and 64KB of RAM. The EGSIZE register is used to establish tl1e bounda ry of the Root Segment, Data Segment, and Stack Segmen t. I decided to have 24KB of code that is non-bankable and a data 60 SEPTEMBER 2ooo Embedded Systems Programming 80x86 real mode except tha t the page is 8KB instead of 64KB and the amount that the page can slide is 4KB instead of the 80x86's 16 bytes. The re are no limit regarding th e 8KB size of the page because the compile r generates code to change the XPC register when the code pass- es the 4KB ma,-k (that is, halfway tl1rough the page) . This is done with a "long jump" instructio n tha t changes the XPC registe r and the PC. The net effect is that there are no gaps in the utilization of memory a is the case of banked schemes when functions do not quite fill up a bank. The entire process is handled by the compiler and is qui te trans- pa re nt to the programme r. The only caveat is that no single statement can gene,-ate more than 4KB of code- an unlikely possibili ty. With the configu- ration shown in Figure 9, I could have 24KB of root code and 1 04K.B of extended code for a total of 128KB of code. The root code is shown in the diagram as taking 24KB. In fact, the root code region can be made small- er or larger. Root code enjoys a slight advantage over extended code in tha t subro utin e linkage is a little faste r, a fac tor that is most important for very short subroutin es. In a typi- cal Rabbit application, most of th e code would reside in extended code space.

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems September 2000 Vol13_10