Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
01/21/03 17:55
Read: times


 
#36913 - RE: Problem with Function Pointers in Banks
The banks are 32K becasue of the way it works on this Cygnal processor. In all banked applications there is a need for a common bank from 0x0000 -> 0xNNNN and a series of switchable banks from 0xNNNN+1 to 0xFFFF. (They dont have to go to all the way to 0xFFFF but it is standard practice). The commom area needs to be there to contain code that must able to execute at any time (such as interrupts) and code that is common and called from the various other banks. It is common practice when using the 8051 family with just a large external EPROM or FLASH chip with minimal logic to hook the 16 bit address bus to the low 16 bits on the FLASH/EPROM and to derive the upper address bits from a set of port bits. Using this scheme the port bits select whole 64K pages. The linker in these cases setups up the common area by making copies of all the same binary image in the lower portion of each 64K page. This makes that lower portion look "unchangeable" from the viewpoint of the processor. Under these conditions you can pick the common area size to be almost anything you like and I have seen many that use 16K. It is however somewhat of a waste of FLASH/EPROM.

Cygal came along with their 128K FLASH parts and due to the fact that fancy bank selection circuitry is "somewhat free" and onboard the chip have arranged it so that the first 32K of flash is visible from 0000->7FFF. Then the logic for the banks makes the 128K visible in four pages in the window from 8000->FFFF. As a matter of fact on the Cygnal part the Bank page 0 lets you see the same data as normally shows up at 0000->7FFF.

This scheme does not waste any of the FLASH. And you simply modularize your code to put as much stuff as you can into the common bank to keep performance up there it is important. This application however has tons of code that is mostly of two types. There is a whole user interface on a 128x64 pixel grraphics display and a 7 key arrow type keypad. All the display code with all these sprintf's and text handling works quite nicely out of one bank while I can put all the RS232 port packet handlers in another bank. There are 2 UARTS that send and receive quite a bit of data which gets entered / displayed from/to the LCD screen. So bank switching performance is not an issue in this application. All the interrupt routines use circular queues which are kept in the onboard 8K XDATA space and with the 25MHz (actually 22.1184 MHz :o) ) 1X clocking performance of the 'F126 there is no real performace penalty of using interrupts in the common bank. It could get a little ugly using the bank switch calls from within an ISR...but we try to stay away from that !!

Michael Karas


List of 12 messages in thread
TopicAuthorDate
Problem with Function Pointers in Banks            01/01/70 00:00      
RE: Problem with Function Pointers in Banks            01/01/70 00:00      
RE: Problem with Function Pointers in Banks            01/01/70 00:00      
RE: Problem with Function Pointers in Banks            01/01/70 00:00      
RE: Problem with Function Pointers in Banks            01/01/70 00:00      
RE: Problem with Function Pointers in Ba            01/01/70 00:00      
RE: Problem with Function Pointers in Ba            01/01/70 00:00      
RE: Problem with Function Pointers in Ba            01/01/70 00:00      
RE: Problem with Function Pointers in Ba            01/01/70 00:00      
RE: Func Pointers / fixed the wode post            01/01/70 00:00      
RE: Problem with Function Pointers in Ba            01/01/70 00:00      
RE: Problem with Function Pointers in Ba            01/01/70 00:00      

Back to Subject List