|
Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment. |
|
Thread Tools |
20th Oct 2020, 4:29 pm | #141 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: PIC 14 Karen
I use a late version of 'Original' MPLAB (8.96) in Windows but I am sure the Microchip tools like MPLAB were always available for Linux as well. I'll have another look.
Yes, look here, always available for Windows, Mac and Linux (3 columns).. although I can appreciate you'd rather use MPLAB X since that's what you already have running. https://www.microchip.com/developmen...nloads-archive |
20th Oct 2020, 5:21 pm | #142 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: PIC 14 Karen
The 3 columns in the classic MPLAB section are for 16 bit windows and 2 flavours of 32bit windows.... In the first section with windows, mac and Linux they are all versions of MPLAB X (or MPLAB IDE X for v1.xx)
|
20th Oct 2020, 5:36 pm | #143 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: PIC 14 Karen
Duh, quite right, should have scrolled further down the page, sorry.
|
20th Oct 2020, 5:37 pm | #144 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: PIC 14 Karen
32-Bit Windows MPLAB (original) runs perfectly OK on 64-bit Windows 10, but that won't help you either.
|
20th Oct 2020, 6:07 pm | #145 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: PIC 14 Karen
I might try running classic MPLAB under Wine... Even if it cant access the PICKIT I can always use the MPLABX IPE to program the chip. Id still like to know whats wrong with the page check... The only thing I can see is the table is inside a Macro but why that should be an issue idk.
|
20th Oct 2020, 6:20 pm | #146 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: PIC 14 Karen
Exactly which file are you trying to assemble (where from?) - I can see if it spits out the same error under original MPLAB.
|
20th Oct 2020, 6:21 pm | #147 |
Octode
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,087
|
Re: PIC 14 Karen
I'm ashamed to say I'm still using the old MPASM 5.03 from 14 years ago
PIC14.asm assembles fine, no errors, warnings or messages, and the PIC14 works great (the suppressed ones are only the usual advisory "ensure page/bank bits are set") That particular boundary check in my LST file is line 411, you dont have a couple of accidentally deleted lines Ian, maybe a macro end missing? Last edited by Phil__G; 20th Oct 2020 at 6:39 pm. |
20th Oct 2020, 6:52 pm | #148 | |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: PIC 14 Karen
Quote:
Code:
MPASM is not supported on 64 bit Operating Systems. Please consider migrating your project "PIC14_IKR" configuration "default" to XC8 Assembler or continue to use a previously released IDE. |
|
20th Oct 2020, 7:19 pm | #149 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: PIC 14 Karen
I realised you meant PIC14 (ref: Thread title) but I wasn't sure which revision. I've just loaded the .asm file into classic MPLAB (Runnng under Win 10 64 bit) and done a 'Quickbuild PIC14.asm - although it produced a lot of warnings about ensuring page bits were set etc, it assembled without any actual errors.
The tools MPLAB used in my case were: Quote:
|
|
20th Oct 2020, 7:41 pm | #150 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: PIC 14 Karen
Hmm maybe I'll try an older version of MPLABX or MPLAB classic under wine. Tbh I preferred classic when I used to use it and I've no need to support C or 32bit microcontrollers at the moment! It would be nice to find out how to fix the table checking in MPLAB X though. Thanks for the help folks.
|
20th Oct 2020, 9:39 pm | #151 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: PIC 14 Karen
Well I worked it out. If you want to use '$' in your code to represent the current address, you have to select "Generate absolute code" in the build options buried in the Production->Set Project Configuration->Manage configuration dialog. Which is something they could have mentioned in the error 151 message.... All compiles fine now.
|
20th Oct 2020, 11:02 pm | #152 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: PIC 14 Karen
When I assembled V1.3 of Karen's OrtonView code (which she was not able to supply the '.hex' of herself) MPLAB actually asked me whether I wanted to generate absolute addressed code or relocatable code. I chose absolute, which was hopefully the right answer.
|
20th Oct 2020, 11:16 pm | #153 | |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: PIC 14 Karen
Quote:
|
|
21st Oct 2020, 7:55 pm | #154 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: PIC 14 Karen
That was useful guys as I have only just installed MPLAB X so helped me get the ASM to assemble with it...
Last edited by Timbucus; 21st Oct 2020 at 8:10 pm. |
21st Oct 2020, 11:37 pm | #155 |
Triode
Join Date: Apr 2020
Location: Newtownabbey, County Antrim, Northern Ireland, UK.
Posts: 16
|
Re: PIC 14 Karen
Hi Slothie,
I know what the problem is and its not your version of MPLAB. I hit this problem last year and decided to understand why the IF statement failed. The if statement that is tripping the compiler means that you have added code in before a RETLW table shown below, in this case the display digit bit generator that uses a RETLW table to generate the portc display bit . See section of the code below. The if statement is designed to check if the RETLW has cross over to the next page typically from H'0500' to H'0600'. Although the code might compile because you commented out the if statement, the program will crash if you burn it to the PIC. Check the disassembled code in the "dissasembly Listing tab and scroll down to where you see the section of code below and check the Flash memory addresses on the left of it. The compiler makes 4 versions of this and all 4 of them need checked to make sure the high byte of the 4 addresses all have the same value i.e. H'05XX'. If any one of them or more jump into H'0600' the If statement will fail. It doesn't matter which High byte it is as long as the High byte value of the address is the same value for all PC + 3 pointer versions. The fix is straight forward enough. Make sure you always add your code after any RETLW tables to avoid the possibility of pushing one or more of the 4 versions into the next page. Any other solution can get messy and involves adding NOP's into the code to manually push and offending versions of the code shown below until they all have the same High address. of HHXX. Hope this makes sense. George L3 MOVLW HIGH ($+4) MOVWF PCLATH MOVF PLO,W ANDLW B'00001111' IF HIGH($)!=HIGH($+D'16') ERROR "PAGING ERROR" ENDIF ADDWF PCL,F RETLW B'00000001' RETLW B'00000010' RETLW B'00000100' RETLW B'00001000' RETLW B'00010000' RETLW B'00100000' RETLW B'01000000' RETLW B'10000000' RETLW 0 RETLW 0 RETLW 0 RETLW 0 RETLW 0 RETLW 0 RETLW 0 RETLW 0 ENDM |
21st Oct 2020, 11:40 pm | #156 |
Triode
Join Date: Apr 2020
Location: Newtownabbey, County Antrim, Northern Ireland, UK.
Posts: 16
|
Re: PIC 14 Karen
Oh and don't forget the uncomment the if statement once you have fixed it to make sure it stops complaining. Its better to have the statement in for obvious reasons.
Good luck, George |
22nd Oct 2020, 12:01 am | #157 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: PIC 14 Karen
As mentioned above, settting the "generate absolute code" option fixed it. I guess it was creating linkable code and so $ isn't known at assembly time. Like many of the messages put out by MPASM it failed to provide the vital information (like value of $ unknown). But yes, changing any of the code is going to risk pushing the table over a page boundary. Unfortunately its necessary to repeat the code to get the timing exact. The code is among the first in the code page so there is some margin for expansion.
|
22nd Oct 2020, 12:49 am | #158 |
Triode
Join Date: Apr 2020
Location: Newtownabbey, County Antrim, Northern Ireland, UK.
Posts: 16
|
Re: PIC 14 Karen
Reflecting back on the testing I did last year the solution isn't as tight as I first posted above. All 4 versions don't have to have the same High address, just as long as any one of them avoids the RETLW straddling two pages. see my explanation below.
The code MOVLW HIGH($+4) makes the compiler load W with the high byte address of what ever address the compiler is at, at the time its compiling this instruction + 4 address places forward. The 4 instruction places forward takes you to the ADDWF,PCL,F (excluding the if statement) and is effectively a table call instruction that adds the displacement down the table to the next RETLW needed and loads W with the RETLW value it holds. So if its being compiled at H'05F8' then add 4 places to H'05FC'. PCLATH would then get loaded with H'05'(the high byte of the 16bit address) and if the displacement to be added by the ADDWF,PCL,F instruction is, say , 10 places down, that would now be H'0606' , but PCLATH stored H'05' and so the Program Counter will jump to H'0506' instead of H'0606' and will likely crash at this point. Hope this makes sense. George |
24th Oct 2020, 1:13 pm | #159 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: PIC 14 Karen
Well, while others are engaged in debugging the Ortonview, I've been toying with making upgrades to the hardware and software in the PIC14. The first step is to place a programming connector on the board, so I don't need to keep levering the chip in and out - the socket I have holds onto the chip remarkably tightly and I want to keep it that way. The programming port needs the RB6/RB7 pins to be isolated during programming, fortunately they are connected to the display and I can unplug mine - its possible that because the display is driven the way it is then those pins will effectively be isolated anyway while the device is being held in reset. The only other change is to put a diode in series with R26 to block the 13v programming voltage from escaping onto the +5v rail.
I glued the connector to the underside of the board under the serial interface where it is near the chip, and some thin wire and a steady hand finished the job. I lifted one end of R26 and soldered the diode in series (checking a thousand times it was the right polarity!) which was effective but not terribly neat. If I had or could see an SMT diode I would have cut the track and soldered it on the rear.... When I tries it the first time it didn't work because I'd put the Vpp on pin 20 rather than pin 1 - oops! I didn't need the F1 signal anyway..... After correcting this I was able to read the PIC etc from MPLAB IPE/IDE if the PIC14 powered itself - the PICKIT wasnt quite up to the job for some reason. Now I just need to decide what to play with first.... |
24th Oct 2020, 1:37 pm | #160 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: PIC 14 Karen
Oh excellent - I was wondering if there was a way to do that on the PCB the other day so I could play with the ICSP header on my TL and PICKIT3 - mainly as I have been looking into how to use the debugging features - I assume that will need a rethink on the use of some of the pins rather than just popping the display.
|