Greetings

This forum handles questions and discussions concerning Microchip’s 8-bit compilers, assemblers, linkers and related tools.

Re: Greetings

Postby K9ACT » Mon Jun 23, 2014 4:50 pm

s
Ian.M wrote:XC8 v1.32 puts the program right at the end of the memory (even short programs) with a GOTO at location 0 to jump to it. The fix is only needed if you are having problems with MPLAB 8 SIM and getting that specific error message. While it is harmless, it should not be used when programming a real chip, as PIC16 devices have no problems if you let execution wrap around, and it does waste a word of program memory.


Bottom line seems to be that I can not use the Pickit 2 program to flash programs built on XC8. The work around is to use the built in programmer functions but they seem stone age by comparison. Another score for MicroC.

Question: What is the double underscore for in front of delay in Ric's program? It won't run in hardware without them and again MicroC couldn't care less.

One more question: What is the .as file that keeps getting in the way of what I am trying to look at? seems to have something to do with Java but is it anything I need to be concerned with.

js
K9ACT
 
Posts: 13
Joined: Sat Jun 21, 2014 6:45 am

Re: Greetings

Postby K9ACT » Mon Jun 23, 2014 5:00 pm

Someone named "Code Critter" posted an interesting response but I can not post to that forum anymore. It just ignores all answer options.

If you are here, please repost or send me email jack@schmidling.com

If not, would someone please advise him via that other forum.

Thanks,

js
K9ACT
 
Posts: 13
Joined: Sat Jun 21, 2014 6:45 am

Re: Greetings

Postby ric » Mon Jun 23, 2014 11:23 pm

K9ACT wrote:...
Question: What is the double underscore for in front of delay in Ric's program? It won't run in hardware without them and again MicroC couldn't care less.

That is simply how they have named the delay macro. I assume it is for historical reasons, Hitech C used the same name.
It is documented on page 330 of the XC8 User's Guide.
Latest test project, an LED matrix display made from one reel of addressable LEDs. here
User avatar
ric
Verified identity
 
Posts: 659
Joined: Sat May 24, 2014 2:35 pm
Location: Melbourne, Australia
PIC experience: Professional 5+ years with MCHP products

Re: Greetings

Postby jtemples » Tue Jun 24, 2014 1:52 am

In C, symbols with leading underscores are reserved for the implementation. This means that a compiler vendor can introduce a symbol like __delay_ms into a header file without the risk of a collision with a user-defined symbol of the same name.

As for why all of the SFR symbol names don't start with an underscore, I don't know...
jtemples
Verified identity
 
Posts: 195
Joined: Sun May 25, 2014 2:23 am
Location: The 805
PIC experience: Professional 5+ years with MCHP products

Re: Greetings

Postby vloki » Tue Jun 24, 2014 8:01 am

K9ACT wrote:Bottom line seems to be that I can not use the Pickit 2 program to flash programs built on XC8. The work around is to use the built in programmer functions but they seem stone age by comparison. Another score for MicroC.

This makes no sense since in my opinion here is no reciprocal effect between compiler and programmer.
vloki
Verified identity
 
Posts: 186
Joined: Wed May 28, 2014 8:42 am
Location: Germany
PIC experience: Professional 5+ years with MCHP products

Re: Greetings

Postby Ian.M » Tue Jun 24, 2014 4:26 pm

Unless he's using obsolete PICkit 2 software that may be crashing on an XC8 v1.32 HEX file.

@K9ACT: We need to know exactly what version PICkit 2 standalone software and device file you were trying to use and exactly what went wrong when you tried to use it to load a HEX file and program your chip.
Ian.M
Verified identity
 
Posts: 95
Joined: Wed May 28, 2014 12:47 am
PIC experience: Professional 1+ years with MCHP products

Re: Greetings

Postby K9ACT » Fri Jun 27, 2014 6:14 am

Ian.M wrote:Unless he's using obsolete PICkit 2 software that may be crashing on an XC8 v1.32 HEX file.

@K9ACT: We need to know exactly what version PICkit 2 standalone software and device file you were trying to use and exactly what went wrong when you tried to use it to load a HEX file and program your chip.


Pickit2 v2.61.00 and device file 1.61.00

When I import hex, it displays 3fff all the way down to the second last line and the program seems to start there but there is only one line of memory left.

Turns out when I tell it to "write", it writes the program and it works but it is very discomforting not to see the hex file as I am used to seeing it.

js
K9ACT
 
Posts: 13
Joined: Sat Jun 21, 2014 6:45 am

Re: Greetings

Postby vloki » Fri Jun 27, 2014 8:18 am

K9ACT wrote:When I import hex, it displays 3fff all the way down to the second last line and the program seems to start there but there is only one line of memory left.
Turns out when I tell it to "write", it writes the program and it works but it is very discomforting not to see the hex file as I am used to seeing it.
js

This sounds *a bit* unlikely ;)
Did you try to view your hex file in an editor ?
May you post one ?
vloki
Verified identity
 
Posts: 186
Joined: Wed May 28, 2014 8:42 am
Location: Germany
PIC experience: Professional 5+ years with MCHP products

Re: Greetings

Postby K9ACT » Sat Jun 28, 2014 4:57 am

vloki wrote:
K9ACT wrote:When I import hex, it displays 3fff all the way down to the second last line and the program seems to start there but there is only one line of memory left.
Turns out when I tell it to "write", it writes the program and it works but it is very discomforting not to see the hex file as I am used to seeing it.
js

This sounds *a bit* unlikely ;)
Did you try to view your hex file in an editor ?
May you post one ?


I have attached screen shots of the first and last page of the Pickit 2 hex display and
the following is a Word view of the hex created by the code from ric.

The program loads and runs in hardware.

js



:040000000000FD2FD0
:100FB0008316031386018312031386010330F200A4
:100FC0008A30F1005630F000F00BE42FF10BE42FE3
:100FD000F20BE42FEB2FAB308312031386000330A8
:100FE000F2008A30F1005630F000F00BF52FF10BD3
:0E0FF000F52FF20BF52FFC2FDB2F8301D82FEE
:02400E0038FF79
:00000001FF
Attachments
HEX1.JPG
HEX1.JPG (30.21 KiB) Viewed 11269 times
HEX2.JPG
HEX2.JPG (30.11 KiB) Viewed 11269 times
K9ACT
 
Posts: 13
Joined: Sat Jun 21, 2014 6:45 am

Re: Greetings

Postby Ian.M » Sat Jun 28, 2014 6:08 pm

Nothing surprising here. The six lines of the HEX file that are in the FLASH program memory area match the two PICkit 2 memory screenshots.

The first line of the HEX file is a NOP followed by GOTO 0x7FD
The subsequent five lines of the hex file are a block of code located between 0x7D8 and 0x7FE
Then there is a line giving the CONFIG word and the final line is an end of file record, both of which don't appear in the program memory.

This is exactly what I would expect if the compiler is using a top down FLASH allocation strategy, and you have the NOP at address 0 for hardware debugger support and you are using my ROM range patch to prevent bogus address wraparound errors in the simulator.

You'd better read up on IntelHEX!
Ian.M
Verified identity
 
Posts: 95
Joined: Wed May 28, 2014 12:47 am
PIC experience: Professional 1+ years with MCHP products

PreviousNext

Return to MPLAB XC8

Who is online

Users browsing this forum: No registered users and 3 guests

cron