Coding woes on a 16F84

Page: < 123 > Showing page 2 of 3
Author
MageX
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2012/09/10 04:27:22
  • Location: 0
  • Status: offline
Re:Coding woes on a 16F84 2012/09/10 14:55:32 (permalink)
0
Ian.M

Ah, the MPLAB X simulator has issues . . . Please try MPLAB 8.

Pasting from the forum into MPLAB usually results in an ugly, hard to read mess even though it usually still builds OK.  Please attach the source as a file (the paperclip icon in the full editor) so we can easily simulate it. There is probably something subtly wrong with the second table.

 
I'm sure the copy/paste could be interesting. As it was, I had fun with Safari (I have a Mac, as well as Windows XP, Windows 7, and Linux systems), trying to get the original post composed. Since it's enclosed with the appropriate code blocks, it I'd like to think that a copy/paste will work fine, but I'm learning that things don't perform according to how they should. In fact, that's why I'm here. wink
 
Anyway, I've already adjusted the file to relocate the ISR, instead. I saw no reason to save a copy of the table relocation method, since it was proving to not be working. Also, without understanding how the routines work, it'd be more problematic than formatting to make things go through the appropriate steps. Even more of a waste, considering that I've already simulated the table relocation and had the simulator show that it works. Only computed GOTO tables are effected by being moved around, correct? Anything that uses CALL/GOTO/RETLW/RETURN will work anywhere within the 1k word space, as I understand it. The ISR, of course, uses RETFIE, but that portion of the code was 100% static with the table relocation. There was 2 other tables that were left in place, immediately after the ISR. Those should be good to go, too. As it was, with HIGHTABLE defined, the code did not operate when assembled and programmed to a 16F84, but simulated perfectly. If I didn't define HIGHTABLE, the programmed chip works. In fact, I have 1 of my 16F84 chips programmed that way, just to have something operational available.
 
Now, if any of you have an Atari 8-bit computer, I could provide the appropriate archive that contains the schematic and original .hex that all of my work is based upon. You could then truly see how the code behaves with and without that define.
#21
MageX
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2012/09/10 04:27:22
  • Location: 0
  • Status: offline
Re:Coding woes on a 16F84 2012/09/10 15:00:58 (permalink)
0
I guess I should have held off on my last reply. The copy/paste was very easy to "fix" for proper formatting. All lines, except the first line, had an extra space added at the beginning. Seems like a flaw in the forum code, there.
 
In any case, here's the raw file: MageAKI - hightable.asm
#22
Ian.M
Super Member
  • Total Posts : 13114
  • Reward points : 0
  • Joined: 2009/07/23 07:02:40
  • Location: UK
  • Status: offline
Re:Coding woes on a 16F84 2012/09/10 15:28:56 (permalink)
0
Yes the forum is half-broken, and has been for a couple of years now, despite several upgrades. Older versions of Firefox (4.0 or earlier) work better than most other browsers.   I am using K-Meleon (also Mozilla derived) with a few user scripts to help with some of the most annoying problems.
 
The forum adds a space at the beginning of every line in code tags, every time, and also tends to mangle tab characters and in some cases looses line endings, joining adjacent lines together.  It is browser dependent.   By attaching the code, you ensure we see exactly what you do - a big help when debugging a build or runtime error as we can refer to stuff by its line number.     Its stiill a good idea to use code tags for any chunks of particular interest as not everyone will bother opening an attachment. 
 
Is there any chance you could post the schematic in a PC readable format and also the original HEX (zip them or the forum, will reject odd file extensions) ?  It doesn't even have to be a modern graphics file format as long as I know what it is.   From earlier comments, I believe that it is something to do with using a PC keyboard on a really old Atari (Not an Atari ST).  Do you know if the code was for the original PC/XT keyboard protocol or the slightly different AT/ATX one, or am I barking up the wrong tree completely?
#23
MageX
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2012/09/10 04:27:22
  • Location: 0
  • Status: offline
Re:Coding woes on a 16F84 2012/09/10 16:23:40 (permalink)
0
Ian.M
Is there any chance you could post the schematic in a PC readable format and also the original HEX (zip them or the forum, will reject odd file extensions) ?  It doesn't even have to be a modern graphics file format as long as I know what it is.   From earlier comments, I believe that it is something to do with using a PC keyboard on a really old Atari (Not an Atari ST).  Do you know if the code was for the original PC/XT keyboard protocol or the slightly different AT/ATX one, or am I barking up the wrong tree completely?

 
It's a generic, AT code set 2 protocol to Atari 8-bit interface. It tracks 2 of the 6 outputs from the POKEY chip (the keyboard scanning outputs), and triggers the appropriate strobe input for normal keys versus meta keys (shift, control, and break keys on the Atari keyboard). 4 other outputs are used on the PIC to simulate the console keys (Start, Select, Option, and Reset). The original design included a 5th output that was toggled via a modified Reset key press. The original code was written by a guy in Germany, thus the original code includes both an English and a German keyboard layout. The English layout had a couple flaws (the ] key produced a + on the Atari, for example), as well as certain limitations (both Ctrl and Shift could not be applied to the "2" key at the same time). I also wanted to change what some keys were defined to do. The Atari keyboard scanning allowed for 67 keys total (64 keys, plus Ctrl, Shift, and Break), but only 61 keys were actually available on the keyboard (6 key values were not reachable on an unmodified Atari). I decided to map certain PC keys to some of those unused values. Also, the original code has routines to send commands to the keyboard, but they failed to work. That was another aspect I am still trying to address.
 
The attachment contains the schematic (GIF format) and hex file I started with. Unless you have an Atari 8-bit computer, you'd have to build a 6-bit counter that operated at 15kHz to simulate the Atari's keyboard scan. the /KR1 signal would be a match for a normal key at the appropriate counter value, while /KR2 would be signal the meta keys at the appropriate counter value. Switching the chip to a 16F628 (maybe even the 16F88) can simplify the circuit by eliminating the external clock source.
#24
1and0
Access is Denied
  • Total Posts : 8460
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re:Coding woes on a 16F84 2012/09/10 21:12:27 (permalink)
0
I have only took a brief look thru your code and this thread, so I might have missed something.  When you relocated the XL8_SC2 jump table to the end of the program memory, did you restore PCLATH for the other lookup tables after calling XL8_SC2?  That is,
 
        call    XL8_SC2         ; Translate Scan Code to POKEY Code
    #ifdef HIGHTABLE
        clrf    PCLATH          ; Restore PCLATH for other tables
    #endif
   
EDIT:  Also, since the GetBit lookup table is located in the ISR, PCLATH might need to be saved, cleared and then restored in the ISR.  Or use this instead of the lookup table.
 
EDIT2:  Or relocate *all* the tables to the last 256-word block of the program memory and initialize PCLATH only once after power-on.

post edited by 1and0 - 2012/09/10 23:05:38
#25
dan1138
Super Member
  • Total Posts : 2868
  • Reward points : 0
  • Joined: 2007/02/21 23:04:16
  • Location: 0
  • Status: offline
Re:Coding woes on a 16F84 2012/09/11 01:33:43 (permalink)
0
Both of the PIC16F84 and the PIC16F128A have just one code page.
 
This means the PCLATH is ignored for GOTO and CALL instructions.
 
Should you port your code to a larger PIC16F you will need to be very careful with the PAGESEL and the targets of the GOTOs in the table must be in the same code page as the table.
 
Please consider changing the ISR to use this code:
;
; Convert ScanCount <5:3> to bit mask
;
; Pros: Does not use PCLATH so ISR does not need to save it.
;       Does not use another stack level in ISR.
;       Uses 11 instructions.
;       Old code uses 14 instructions.
;
; Cons: Needs 11 instruction cycles to run.
;       Old code needs only 10 instruction cycles.
;
; Replaces this code:
;    
;     rlf ScanCount,W 
;     andlw 0x70 
;     movwf Scan_Swap 
;     swapf Scan_Swap,W 
;     call GetBit 
;    
    movlw   0x0F            ; if bit 5 is 0, must be bit 3,2,1,0
    btfsc   ScanCount,5                            
    movlw   0xF0            ; if bit 5 is 1, must be bit 7,6,4,5
    btfsc   ScanCount,4                            
    andlw   0xCC            ; if bit 4 is 1, must be bit 7,6,3,2
    btfss   ScanCount,4                            
    andlw   0x33            ; if bit 4 is 0  must be bit 4,5,1,0
    btfsc   ScanCount,3                            
    andlw   0xAA            ; if bit 3 is 1, must be bit 7,5,3,1
    btfss   ScanCount,3                            
    andlw   0x55            ; if bit 3 is 0  must be bit 6,4,2,0
;
; Remember to remove bit table:
;    
;   GetBit 
;     addwf PCL,F 
;     retlw 0x01 
;     retlw 0x02 
;     retlw 0x04 
;     retlw 0x08 
;     retlw 0x10 
;     retlw 0x20 
;     retlw 0x40 
;     retlw 0x80 
;

 
Also please think about using this for your key code translation lookup:
;
; Table lookup that can span
; a 256 instruction boundary.
;
; Does not need temporary storage.
;
; Input: W = 0 to 255 offset into table.
;
; Notes:
;   Table can be located anywhere in memory.
;   Does not need to be close to this function.
;
; Replaces this code:
;
;   XL8_SC2                                ; Add Scan Code (Set 2) to PCL 
;       addwf PCL,F                        ; Code - Description 
;
XL8_SC2
    movwf   PCLATH              ; Setup high part table
    xorlw   HIGH(SC2_Table)     ;  address without using
    xorwf   PCLATH,F            ;  a temporary register.
    xorlw   HIGH(SC2_Table)     ; Recover table offset.
    addlw   LOW(SC2_Table)      ; Add to table base address.
    btfsc   STATUS,C            ; Skip if does not cross boundry.
    incf    PCLATH,F            ; Adjust high byte of address when it does.
    movwf   PCL                 ; Lookup table entry.
;
; Table can be anywhere in memory
;
SC2_Table:
    retlw 0xFF                  ; 0x00 - should never see this code 
    goto  Proc_F9               ; 0x01 - F9 
    retlw 0xFF                  ; 0x02 
    goto  Proc_F5               ; 0x03 - F5 
    retlw 0x13                  ; 0x04 - F3 
    goto  Proc_F1               ; 0x05 - F1 
    retlw 0x04                  ; 0x06 - F2 
    goto  Proc_F12              ; 0x07 - F12 
    retlw 0xFF                  ; 0x08 
;
; ...
;
    goto  Proc_SysRq            ; 0x84 - Alt-SysRq 
    retlw 0x35                  ; 0x85 - 8 (German layout?) 
    retlw 0x1C                  ; 0x86 - Escape (German layout?) 
    retlw 0xFF                  ; 0x87 
    retlw 0xFF                  ; 0x88 
    retlw 0x06                  ; 0x89 - + (German layout?) 
    retlw 0x1A                  ; 0x8A - 3 (German layout?) 
    retlw 0x0E                  ; 0x8B - - (German layout?) 
    retlw 0x07                  ; 0x8C - * (German layout?) 
    retlw 0x30                  ; 0x8D - 9 (German layout?) 
    retlw 0xFF                  ; 0x8E 
    retlw 0xFF                  ; 0x8F 

post edited by dan1138 - 2012/09/11 01:40:42
#26
MageX
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2012/09/10 04:27:22
  • Location: 0
  • Status: offline
Re:Coding woes on a 16F84 2012/09/11 03:46:02 (permalink)
0
1and0

I have only took a brief look thru your code and this thread, so I might have missed something.  When you relocated the XL8_SC2 jump table to the end of the program memory, did you restore PCLATH for the other lookup tables after calling XL8_SC2?  That is,

EDIT:  Also, since the GetBit lookup table is located in the ISR, PCLATH might need to be saved, cleared and then restored in the ISR.  Or use this instead of the lookup table.

EDIT2:  Or relocate *all* the tables to the last 256-word block of the program memory and initialize PCLATH only once after power-on.

 
Thank you for the suggestion. It's possible that the GetBit table was being read in my testing and getting the high PCLATH data. As I only have 15 words left in program space, with the enhanced ISR code, I'm trying to use as few instructions to fix this issue as I can, too. The other table is a hard-coded macro (multiple keystrokes played out on the Atari), and was certainly not being called in my tests.
 
Still, this is all starting to prove the simulator as having operation errors. Which could lead to many software bugs that cause lots of wasted programming time.
#27
Ian.M
Super Member
  • Total Posts : 13114
  • Reward points : 0
  • Joined: 2009/07/23 07:02:40
  • Location: UK
  • Status: offline
Re:Coding woes on a 16F84 2012/09/11 04:07:05 (permalink)
0
As I said earlier, The MPLAB 8.xx simulator is generally reliable with reasonably well documented limitations that do not significantly affect the peripherals of a PIC16F84.  Unless you have NO WAY WHATSOEVER of running a Microsoft OS, I suggest you install MPLAB 8.87.  
 
If you are NOT using a windows PC, it is still  worth going through the considerable pain installing VMWARE player then setting up a VM and installing MS Windows XP into it, updating that to SP3 then installing MPLAB 8.xx + your choice of other Microchip tools to get a reasonably stable development enviroment. If runing under VMWARE, even Microchips USB I/F programmers and debuggers work. If you already have an XP, Win2K, WinFLP, or Vista VM, do try running MPLAB in it but be aware that not all VM solutions have good enough USB HID device support.  You may be able to simply convert a copy of your existing Windows VM's disk file to VMWARE format.  
 
I found a link to the Atari 8 bit POKEY chip datasheet in a wikipedia article.  It should help understanding of the Atari side of this project - especially signal names and timing.
 

Keyboard matrix connection to POKEY
 
CD4051 8 channel analog multiplexer datasheet.
post edited by Ian.M - 2012/09/11 04:19:16

Attached Image(s)

#28
MageX
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2012/09/10 04:27:22
  • Location: 0
  • Status: offline
Re:Coding woes on a 16F84 2012/09/11 04:27:16 (permalink)
0
dan1138

Both of the PIC16F84 and the PIC16F128A have just one code page.

This means the PCLATH is ignored for GOTO and CALL instructions.

Should you port your code to a larger PIC16F you will need to be very careful with the PAGESEL and the targets of the GOTOs in the table must be in the same code page as the table.

Please consider changing the ISR to use this code:
{removed}
Also please think about using this for your key code translation lookup:
{removed}

 
With ScanCount not being being a single bit that rolls through, will your suggested code return a SINGLE bit as active? It is masked by POKEY_Meta, but POKEY_Meta cannot be restricted to a single bit (Ctrl and Shift have to be usable at the same time, but triggered at different scan counts). Bits 1, 5, and 7 of POKEY_Meta can all be active at once. While Break is rarely used in conjunction with Ctrl and Shift, it can be done and needs to be handled accordingly. It was looking like your suggested code change will allow multiple bits to remain active when only 1 should be.
 
As for the processing of boundary crossing, The tables don't not cross any boundaries. Are you saying that the silicon lags the PCLATH update/use, thus the added code of a boundary check is the only way it will be applied in time?
#29
JorgeF
Super Member
  • Total Posts : 3297
  • Reward points : 0
  • Joined: 2011/07/09 11:56:58
  • Location: PT/EU @ Third rock from the Sun
  • Status: offline
Re:Coding woes on a 16F84 2012/09/11 05:16:12 (permalink)
+2 (1)
Hi
 
 
About PC boundaries, you have to make a distinction bettwen the "goto" / "call" instructions and the PC arithmetics.
The "goto" and "call" instructions carry 11 bits of addressing with them, that is enought for a 2K addressing range, meaning PCLATH<4:3> won't be used, and can be treated as "don't care" as the addressing will roll back to the first page whatever the value of this 2 bits.
 
When arithmetics around the PC, like in "addwf PCL" are involved, only 8 bits of the program addressing space are provided, the remainig are fetched from PCLATH<4:0>.
Thats why we have to manage both PCL and PCLATH<4:0> when using lookup tables as long as the PIC as more than 256 program words to address (in some PICs there is no PCLATH but they have the equivalent feature).
 
Having a PIC where the "call" / "goto" instruction don't use the PCLATH or only use a part of it makes it worse, as we can't relly on the "call" instruction to have set the PCLATH to the address range of the table.
 
Best regards
Jorge
 
 
 
 
 
post edited by JorgeF - 2012/09/11 05:21:32
#30
MageX
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2012/09/10 04:27:22
  • Location: 0
  • Status: offline
Re:Coding woes on a 16F84 2012/09/11 05:22:12 (permalink)
0
Nice to see you've done a little homework rather than just post suggestions without knowing how things need to work. The suggestion of resetting PCLATH was something that hadn't been offered until recently, and certainly was an oversight on my part. For all I know, that will be the actual fix that was needed. Then again, that's assuming PCLATH isn't cleared/updated automatically, like the simulator suggests.
 
Also, it might be worth noting that the scan counter (K0-K5 outputs) is incremented by a 15kHz clock (15000 vs 1000000 effective operation). The chip will only track a single, normal key for each pass through the scan. However, Ctrl, Shift, and Break will all be sampled and tracked on the same pass. That allows Ctrl, Shift, and Ctrl-Shift combinations, as well as the ability for Break to be triggered. I believe that document you found has all of these details in it, too.
 
Assuming that the suggested code to replace the GetBit table will result in the exact same operation, I'd be very willing to save code space versus save 1 or 2 processing cycles. As previously commented about, there is plenty of time for a few extra processing cycles. Plus, there are only 3 possible meta keys, as seen in that document excerpt you posted. So the suggested code change may be made even more efficient. The GetBit table is only used for the /KR2 signal. That was something from the original code, and I'll happily rework things. Eliminating unnecessary code, either by replacing it with a smaller equivalent or by simply commenting it out, always helps in the end. For example, the original code was processing and tracking the left and right Ctrl, Shift, and Alt keys seperately. The Atari only has 1 Control key, 1 logical Shift key (2 physical keys that act the same), and no Alt key at all. The code to track the PC versions separately was simply a waste of code space. Well, for foreign keyboards, the Alt keys may need to be tracked individually, but I've concentrated on the only layout I have available.
#31
Ian.M
Super Member
  • Total Posts : 13114
  • Reward points : 0
  • Joined: 2009/07/23 07:02:40
  • Location: UK
  • Status: offline
Re:Coding woes on a 16F84 2012/09/11 05:24:50 (permalink)
0
"Should you port your code to a larger PIC . . ."   could also be read as "If, in the future, you port your code to a larger PIC . . ."  and I *think* Dan is trying to warn you that the computed GOTO for the tables needs the extra calculations on any PIC with more than 2Kword of program memory.  (As the 14 bit core CALL and GOTO opcodes have only 11 bits for addressing, and the program counter is 13 bit, they take PCLATH.3,4 as the high bits).  See PICmicro™ Mid-Range MCU Family Reference Manual DS33023A:section 6.2.4
 
The midrange silicon ONLY updates PCH itself when execution progresses from address xxFFh to yy00h where yy=xx+1 and xx is any page, or with the value on the return stack for RETURN, RETLW and RETFIE instructions or by loading it with PCLATH if you write anything to PCL or by copying two bits from PCLATH if you execute a CALL or GOTO, or by zeroing the same two bits when an interrupt source makes it 'call' the ISR.  Apart from zeroing PCLATH on any reset, the PIC *NEVER* changes PCLATH except when your code explicitly writes to it. 
 
There is only a one cycle lag and that cycle executes as a NOP (as the next instruction in the pipeline is abandoned) - which is why CALL, GOTO, RETURN, RETLW and RETFIE and any instruction with PCL as the destination take two cycles to execute and interrupts take two dummy cycles between the last instruction of the main program and the first in the ISR (see DS33023A:Figure 8-2).
 
For the PIC16x84(A) familys, the two bits used by CALL and GOTO are hardwired in PCLAH as '0' because the memory is too small to ever need them.
post edited by Ian.M - 2012/09/11 05:31:37
#32
MageX
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2012/09/10 04:27:22
  • Location: 0
  • Status: offline
Re:Coding woes on a 16F84 2012/09/11 05:31:36 (permalink)
0
Thanks, but I think the suggestion that just may fix things is ensuring that PCLATH is cleared for the other tables. A single extra instruction (clrf PCLATH) at the start of the other table(s) makes sense and was something I admitted to having overlooked. In fact, most of this thread overlooked it, too, so I don't feel quite so bad about it. After all, this is my very first PIC-based project. I don't know the ins and outs of every PIC, but I'm learning.
#33
MageX
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2012/09/10 04:27:22
  • Location: 0
  • Status: offline
Re:Coding woes on a 16F84 2012/09/11 05:49:00 (permalink)
0
Valid concerns, I'll agree. However, this project should never exceed a 2k word PIC. In fact, for the US keyboard layout, it likely won't exceed 1k words. As a keyboard adapter, there's simply a limit as to what you need to do. More macros with larger macro support? That'd be easily done by adding code to manipulate an external EEPROM (24C series, for example). That'd still fall within the 2k word program space. In fact, the original AKI circuit design already has a 24C-series compatible chip wired up, but no code seems to have existed to use it. That's another reason why I'm looking at adapting the source for the 16F628 (16F88, too, but I'll need to order at least 1 of those for testing in the circuit). More code space will be needed for the external EEPROM support, but there was the issue of relocating that table to deal with before trying to add too much else.
#34
1and0
Access is Denied
  • Total Posts : 8460
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re:Coding woes on a 16F84 2012/09/11 05:53:39 (permalink)
0
MageX
With ScanCount not being being a single bit that rolls through, will your suggested code return a SINGLE bit as active?
...
Assuming that the suggested code to replace the GetBit table will result in the exact same operation, I'd be very willing to save code space versus save 1 or 2 processing cycles.
Yes, Dan's code returns the same values as the GetBit table; that is, W = 1 << (ScanCount >> 3 & 7).  Replacing the GetBit table with his snippet will avoid having to save/restore PCLATH, which keeps program memory usage low.
post edited by 1and0 - 2012/09/11 05:58:48
#35
Ian.M
Super Member
  • Total Posts : 13114
  • Reward points : 0
  • Joined: 2009/07/23 07:02:40
  • Location: UK
  • Status: offline
Re:Coding woes on a 16F84 2012/09/11 06:04:00 (permalink)
0
MageX
Thanks, but I think the suggestion that just may fix things is ensuring that PCLATH is cleared for the other tables. A single extra instruction (clrf PCLATH) at the start of the other table(s) makes sense and was something I admitted to having overlooked.

No, for tables that never cross 256 byte page boundaries, CLRF PCLATH only works if they are in the zero page.  For all other pages, you need:
  
    movlw   HIGH(SC2_Table) ; Get high byte of table address
    movwf   PCLATH          ; Set PCLATH accordingly.

 
N.B. you can alternatively use Dan's elegant code to update PCLATH without smashing the value in the W register.
  
    movwf   PCLATH              ; Setup high byte of table
    xorlw   HIGH(SC2_Table)     ;  address without using
    xorwf   PCLATH,F            ;  a temporary register.
    xorlw   HIGH(SC2_Table)     ; Recover previous W.

which is no longer than saving and restoring W using a temporary register would be.
post edited by Ian.M - 2012/09/11 06:38:42
#36
MageX
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2012/09/10 04:27:22
  • Location: 0
  • Status: offline
Re:Coding woes on a 16F84 2012/09/11 06:09:18 (permalink)
0
1and0

MageX
With ScanCount not being being a single bit that rolls through, will your suggested code return a SINGLE bit as active?
...
Assuming that the suggested code to replace the GetBit table will result in the exact same operation, I'd be very willing to save code space versus save 1 or 2 processing cycles.
Yes, Dan's code returns the same values as the GetBit table; that is, W = 1 << (ScanCount >> 3 & 7).  Replacing the GetBit table with his snippet will avoid having to save/restore PCLATH, which keeps program memory usage low.

 
Hmm. Except, that doesn't sound like it will get the correct values. The result should be 0x02, 0x20, or 0x80. So, either I'm not seeing where that code change creates that, or that code change won't properly replace the table.
#37
MageX
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2012/09/10 04:27:22
  • Location: 0
  • Status: offline
Re:Coding woes on a 16F84 2012/09/11 06:12:37 (permalink)
0
The other 2 tables are small enough to stay where the "clrf PCLATH" will do the job. That's why I said that.
#38
DarioG
Allmächtig.
  • Total Posts : 54081
  • Reward points : 0
  • Joined: 2006/02/25 08:58:22
  • Location: Oesterreich
  • Status: offline
Re:Coding woes on a 16F84 2012/09/11 06:30:54 (permalink)
0
Nice trick Dan Smile

GENOVA :D :D ! GODO
#39
1and0
Access is Denied
  • Total Posts : 8460
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re:Coding woes on a 16F84 2012/09/11 06:38:58 (permalink)
0
MageX
Hmm. Except, that doesn't sound like it will get the correct values. The result should be 0x02, 0x20, or 0x80. So, either I'm not seeing where that code change creates that, or that code change won't properly replace the table.
What do you mean?  That snippet does this:
 
  input        output
  ScanCount      WREG
  -------------------
  b'xx000xxx'    0x01
  b'xx001xxx'    0x02
  b'xx010xxx'    0x04
  b'xx011xxx'    0x08
  b'xx100xxx'    0x10
  b'xx101xxx'    0x20
  b'xx110xxx'    0x40
  b'xx111xxx'    0x80
 
where x is don't care.

#40
Page: < 123 > Showing page 2 of 3
Jump to:
© 2018 APG vNext Commercial Version 4.5