Jump to content
Pavel

Sourceboost V7.10 Release Candidate

Recommended Posts

SourceBoost v7.10 release candidate is available to download from:

 

http://www.sourceboost.com/CommonDownload/Binaries/SourceBoostV7.10RC/sourceboostv710.exe

 

What's new:

  • MplabX plugin updated to work with Mplab X 1.20
  • BoostBuild is now installed as a service
  • Added support for new targets PIC16f1508, PIC16lf1508, PIC16f1509, PIC16lf1509, PIC16f1782, PIC16lf1782, PIC16f1783, PIC16lf1783, PIC16F720, PIC16F721, PIC16F722A, PIC16F723A
  • Fixed several issues in compiler, simulator and ide reported on the forum

 

Let us know if you find any problems.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

I see that the problem reported in http://forum.sourceb...?showtopic=5030 has still not been addressed and you still need to declare a dummy "eeadrh" to get the linker to build when using a chip with 255byted of eeprom.

 

Any idea how to fix this without creating a new lib file for PIC18 that don't have EEADRH?

 

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

I see that the problem reported in http://forum.sourceb...?showtopic=5030 has still not been addressed and you still need to declare a dummy "eeadrh" to get the linker to build when using a chip with 255byted of eeprom.

 

Any idea how to fix this without creating a new lib file for PIC18 that don't have EEADRH?

 

 

Regards,

Pavel

I would have thought that was more your job rather than mine but since you ask how about adding the dummy EEADRH definition to all of the appropriate PIC18 header files. That would stop the linker from complaining and the user would not have to waste a day scratching his head wondering why the code doesnt compile.

Share this post


Link to post
Share on other sites

I see that the problem reported in http://forum.sourceb...?showtopic=5030 has still not been addressed and you still need to declare a dummy "eeadrh" to get the linker to build when using a chip with 255byted of eeprom.

 

Any idea how to fix this without creating a new lib file for PIC18 that don't have EEADRH?

 

 

Regards,

Pavel

I would have thought that was more your job rather than mine but since you ask how about adding the dummy EEADRH definition to all of the appropriate PIC18 header files. That would stop the linker from complaining and the user would not have to waste a day scratching his head wondering why the code doesnt compile.

 

Not sure I understand your suggestion. Can't see how a dummy EEADRH definition can help. Linker wants a variable called 'eeadrh' when links to eeprom library.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Hi

 

In my opinion, its better to face things as they are, instead of finding workarounds.

 

Why not make available 2 sets of libs, one for up to 256 bytes eeprom, and another for more than that.

Somtehing like what happens with "NOVO". The distribution as a set of libs for different processor families and different kernel resources configurations.

 

IMOH its the cleanest way to cope with this.

 

Best regards

Jorge

Share this post


Link to post
Share on other sites

The eeprom.h check for the EEARDH being declared.

 

If declared it chooses the short address else the char address functions.

 

A quick test using PIC18F2520, 256 bytes EEPROM did not grumble about EEARDH not being found.

 

Cheers

 

Reynard

Share this post


Link to post
Share on other sites

The eeprom.h check for the EEARDH being declared.

 

If declared it chooses the short address else the char address functions.

 

A quick test using PIC18F2520, 256 bytes EEPROM did not grumble about EEARDH not being found.

 

Sorry still no good. Eeprom header already checks this but it doesn't help linker that can't find 'eeadrh' variable.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Hi Pavel,

 

I see it now. It is the eeorpm_write than is causing the problem.

 

void eeprom_write(unsigned char address, unsigned char data)

This function is using eeadrh when it shouldn't as it is only an 8 bit address.

 

Cheers

 

Reynard

Share this post


Link to post
Share on other sites

Hi

 

Not exactly on the subject, Reynard already sorted it out.

 

But, I would like to know why the "eeprom.c" as declarations of the SFRs involved in eeprom operations and of the EECON1 bits, and not only, GIE is not an EECON1 bit.

The "eeprom.c" file has an inclusion for "boostc.h" so the SFRs and its bits should already be known, or am I missing something?

 

Best regards

Jorge

Edited by JorgeF

Share this post


Link to post
Share on other sites

Hi Jorge,

 

The external variables (SFR's) are declared using the 'extern' keyword as you would do in any C file that references a variable declared in another file.

 

The library does not know what the target device is so there no specific device header can be included.

 

As the bit definitions are common to all pic families they can be defined within the eeprom.c file.

 

GIE is not used with the eecon1 SFR that I can see.

 

Cheers

 

Reynard

Share this post


Link to post
Share on other sites

OK for now problem with eeprom code is fixed in the documentation. We added a note into eeprom API chapter into compiler help about library use with PIC18 that don't have EEADDRH.

 

Pavel

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...