Jump to content

soft2

EstablishedMember
  • Content Count

    71
  • Joined

  • Last visited

Community Reputation

0 Neutral

About soft2

  • Rank
    Regular

Profile Information

  • Location
    Vermont
  1. Thanks for testing it Joli. If I add the _EEPROM def right after system.h it appears to work. It may not have been working before because I wasn't defining it soon enough. Another header may have called #pragma DATA that I didn't know about... I'm defining it now in the device header where it's missing but I wish Dave or Pavel would finish this header. best regards
  2. I see there is a header file for PIC18F45K50 (although somewhat incomplete) and a .TDF file as well. But MPLABX won't allow me to use the Sourceboost toolsuite for this device. Is there a list that MPLABX scans to see what devices are supported by SourceBoost toolsuite? Can I manually add this device to the list? If not, how long before you will formally support it?
  3. Thanks for your help. I tried adding it to my own code but it didn't work so I added it to the device header. The problem with that is it will be lost when I install the next SourceBoost update. There are a LOT of things missing from the device header file so I think I'm going to create a header with all the missing items and then add a line to the device header like #include missing_stuff.h at the end of the device header. Dave and/or Pavel really need to take a look at this header because it's missing multiple items and has no configuration data.
  4. Thx for your reply. I just installed ver 7.30 and it's in there. I'll send you a screenshot of my include dir if you really want to see it. The file date is 04/30/15 and the size is 33k which is very small compared to similar devices. It's on the device list and no, I did not select 45J50. I'll try to attach it to this post. PIC18F45K50.h
  5. Sounds like the _EEPROM does not have the correct address for the device you are programming. You can check it in the devices header file. You find the address required in the Microchip programming data sheet for the device. Let us know how you get on. Regards Dave Reviving this old thread because I'm having the same problem. I looked in the header file for the device and _EEPROM is not defined at all so of course I get an error when I try to use the directive #pragma DATA _EEPROM, xx, xx, ... Was this an omission? Or am I supposed to include another header? The BoostC v7 Compiler Reference Manual still recommends this directive to initialize EEPROM. The device is PIC18F45K50 and it includes the header pic18F45k50.h. I'm porting from a PIC18F4550 which has _EEPROM defined in its header. The new header also contains no _CONFIG defs.
  6. Hi Ted, I did this almost 2 yrs ago using the first release of version 7. Might have been the beta release. There were still some type casting bugs back then and a few other problems, but I managed to get it working quite reliably, reading and writing very fast using SPI. The SB code was fast enough that only hardware limitations determined the top speed. 3 - 5v was tricky! I ultimately gave up supporting FAT 12 and 16 and just did FAT32 because none of my SD cards were that small anymore. It was kind of funny I learned that certain bugs can kill the card with no way to bring it back! I killed 2 cards that way! I'm overwhelmed with a work deadline right now but I would have fun sharing code with you in about 3 weeks.
  7. Hmmm... I've been using large arrays including structs > 256 bytes and -idx 2 without getting this error. Is the error produced when you declare an array of 300 bytes or just when you use a struct that contains a 300b array? It would be nice to have more in-depth explanation of -idx 2. I've encountered problems with it but never seen this error.
  8. Lasse I'm not sure if anyone got back to you on this. There are several instructions such as POSTINC and POSTDEC that only use 8 bits of address so there will be a problem if they operate on a variable that crosses a bank boundary such as an int or long starting at 0x000007FF. POSTDEC for example will operate on the first byte and then decrement the address which will just wrap around to the other end of the bank. Pavel and Dave were aware of this when developing v7 and probably that's why they added the linker error (just guessing). They also looked at some potential solutions such as the linker trying to make sure multi-byte variables did not cross bank boundaries but this is a lot trickier with, for example, a pointer to one type that is cast to a larger type, or how the ptr will be assigned, so the linker may not know ahead of time. I'm not sure what solutions were ultimately implemented - perhaps Pavel or Dave has time to chime in here? I'm guessing the linker error was added when variables could not be moved to a safer place. Your struct may also contribute to the problem (or caused the linker error). If one variable within the struct was aligned so to cross a bank, the linker would have to do a special allocation for the entire struct, which may be impossible. I'm curious how other compilers/linkers have dealt with this issue. It may be a limitation of the PIC18 devices that if you use large arrays, you have to pay close attention to alignment. Best, Henry
  9. Has anyone used V7 yet? Curious how it affects ROM usage, compile speed, optimization etc. Is it possible to install and use 2 versions of BoostC at once on your PC? Then we could compile with different versions and compare various performance factors.
  10. This question has been asked before, but no one has ever answered it that I'm aware of. I am using ICD2 for debugging. It could be due to a MPLAB deficiency (do all 3rd party compilers do this?) or a problem with the integration protocol (is SB conforming to all current specs?) It would be nice if Pavel or Dave could address this and if nothing else, let us know they are aware of the problem even if they don't plan to do anything about it. Regards, Henry
  11. Thanks we are waiting patiently for that. Just to give you an idea how patient we are, I'm sure most of us could wait a few more hours, possibly even until tomorrow. So, don't rush or anything...
  12. The configuration settings for Debug and Release versions is a new problem that started with MPLAB v.8 and it doesn't stop there. There are other problems that began with that version such as project source file locations. If some are in subdirs then MPLAB or SourceBoost won't find them in some cases. I've tried to find out if this is a sourceboost error or MPLAB but nobody can tell me. All I know is it used to work in MPLAB v.7.xx and I wish somebody would fix it. As far as rebuilding the whole project every time, that is a major PITA but again nobody has ever answered my inquiry as to who needs to put this on their bug/enhancement list. My guess is that MC changed their specs/requirements for integrated tools but either didn't tell the tool providors or SB hasn't gotten around to updating yet. Only a guess. I'm also using ICD2.
  13. Turns out that what you Alex suggested helped in my problem. Declaring the variables as volatile shows them in watch window, no matter if they have initial value assignment or not. So now that my problem is gone, I'm still curious to know what causes this kind of behaviour? Thanks! I think you have to do more than just init the variable. If the variable is only initialized and then not used again, then it can either go out of scope or become literal. You may not see this in the assembly code.
  14. jean-M, Confirm the size of SeringueActive.VolumePar_Pas. An unsigned char would give those results. You also haven't told us how NbrePas is declared.
×
×
  • Create New...