Post by thread:Odd PCL behaviour on 16C84

Hello, I use the modification of PCL extensively to implement switch statements. And I am fully aware of the consideration that must be given to PCLATH. However, if I modify PCL when in the top 100H bytes of a 16C84 processor, it doesn't work. The processor jumps off to somewhere completely different to where I want it to go. This also happens in the DOS simulator! I haven't done very much investigation into this problem, I just keep all my jump tables in the first page of ROM and that avoids it. I don't know exactly where in RAM this problem starts occuring, but it's near the top on ROM. Please note that in this case, I do NOT modify PCLATH, because I know that the table doesn't cross a 100H boundary. Has anybody else noticed this? Have I mis-understood/missed something? More investigation with a simulator or emulator would be useful I know. Thanks for any insight, Stuart.

part 0 4521 bytes I see that you have the same problem that I had. I've resolved that after long experiments with MPLAB-SIM because I didn't understood the data sheet.You have to check out the AN556 on the Microchip's site.You can put a table any where you want in prog.memory but you have to preset the PCLATH before the call table is executed. example. PC            &n bsp;   opcode ---------------------------- xxx    main     -             &nbs p;        - xxx            & nbsp;   movlw    H'02' xxx            & nbsp;   movwf    PCLATH xxx            & nbsp;   call         Table             &nbs p;        -             &nbs p;        - 246    Table  addwf    PCL 247                retlw    .... 248                retlw    .... 249                ............ 2xx                - // - You have to check, on which page in the prog.memory is the Table. In this example the Table begin in the H'246' so PCLATH has to be preloaded with H'02'. Be carefull that the Table doesn't cross a page boundary. If it does , you can check out AN556 example 6.The best way to check where the Table begin and stop is to assembly the program and check in the program.lst file. good luck, Valter Stuart Allen wrote: <BLOCKQUOTE TYPE=CITE>Hello, I use the modification of PCL extensively to implement switch statements. And I am fully aware of the consideration that must be given to PCLATH. However, if I modify PCL when in the top 100H bytes of a 16C84 processor, it doesn't work. The processor jumps off to somewhere completely different to where I want it to go. This also happens in the DOS simulator! I haven't done very much investigation into this problem, I just keep all my jump tables in the first page of ROM and that avoids it. I don't know exactly where in RAM this problem starts occuring, but it's near the top on ROM. Please note that in this case, I do NOT modify PCLATH, because I know that the table doesn't cross a 100H boundary. Has anybody else noticed this? Have I mis-understood/missed something? More investigation with a simulator or emulator would be useful I know. Thanks for any insight, Stuart.</BLOCKQUOTE>  </HTML> </x-html>

> Van: Stuart Allen <.....allenKILLspam@spam@SONY.DE> > Aan: PICLISTKILLspamMITVMA.MIT.EDU > Onderwerp: Odd PCL behaviour on 16C84 > Datum: maandag 12 oktober 1998 10:09 > > Hello, > > I use the modification of PCL extensively to implement switch statements. > And I am fully aware of the consideration that must be given to PCLATH. > > However, if I modify PCL when in the top 100H bytes of a 16C84 processor, it > doesn't work. The processor jumps off to somewhere completely different to > where I want it to go. That's funny ... Because of the hasseling with PCLATH I myself keep my tables (the few that I use) in the last 0100h bytes of memory (in the 16C84 and others). I do not see any out-of-the-ordinary behavour ... > This also happens in the DOS simulator! I haven't done very much > investigation into this problem, I just keep all my jump tables in the first > page of ROM and that avoids it. DOS simulator for 16C84 ? What's it's name ? > I don't know exactly where in RAM this problem starts occuring, but it's > near the top on ROM. > > Please note that in this case, I do NOT modify PCLATH, because I know that > the table doesn't cross a 100H boundary. It's not because of the _crossing_ of a page-boundary, but because of the Jump _target_ that you will have to set PCLATH. In other words : the source of the indirect-jump does not matter, the target of the jump does. It's perfecly legal to have a Indirect-jump vector of 0x40 to 0x60 and than to have the ADDWF PCL command at any adress higher-or-equal to 0xC0 in the page just in front of the page where PCLATH points to. (0xC0 + 0x40 --> target will be in the page PCLATH points to ...) > Has anybody else noticed this? Have I mis-understood/missed something? I myself have not. Maybe, I do not know. Please supply the offending routine for close scrutiny ... :-) Greetz, Rudy Wieser

Stuart Allen wrote: > > Hello, > > I use the modification of PCL extensively to implement switch statements. When you modify the Program Counter value by using an instruction such as ADDWF PCL, the new Program Counter value becomes the value in PCL concatenated with the 5 lower bits of the PCLATH register. Example. PC = 0010h = 0 0000 0001 0000 PCL is always the lower 8 bits of the PC value so, PCL = 10h = 0001 0000 If the value in W Reg = 5h and the ADDWF PCL instruction is executed then 5h is added to the PCL value. 10h 0001 0000 + 05h 0000 1001 = 0001 1001 New PCL value = 15h Because the PCL value is connected to the lower 8 bits of the Program Counter, they must also change. Just by changing the PCL value does not enable us to move anywhere in the PIC's ROM space. That would only allow us to move anywhere in the first 256 ROM addresses. The mechanism to enable us to move to 'anywhere' in the PICs ROM space is by using 5 bits from the PCLATH register. The reason we use '5 bits only' from the PCLATH is because the PC is 13 bits wide. So the 8 bits from PCL plus the 5 bits from PCLATH = 13 bits. Moving on from the above example... PCLATH = 01h = 0000 0001 PCL = 05h = 0000 1001 Merge these together we get 0 0001 0000 1001 New 13 bit PC value = 0 0001 0000 1001. This new value is now placed into the Program Counter. Because of the PIC's architecture, the PC value is incremented by 1. PC value now = 0 0001 0000 1010 = 0106h. This address is where the next instruction will be fetched from. The 16F84 only has a 1K ROM space so only 11 bits from the PC value are used. eg. 001 0000 1010 = 106h Notice how we were able to move more than 256 ROM locations from the original instruction. Hope this helps. -- Best regards Tony Multimedia 16F84 Beginners PIC Tools. **New Improved PicNPost** http://www.picnpoke.com Email .....picnpokeKILLspam.....cdi.com.au