Jump to content

soft2

EstablishedMember
  • Content Count

    71
  • Joined

  • Last visited

Everything posted by soft2

  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.
  15. Isn't a vector a very different animal from an array? An array is fixed in size when it's declared. A vector can grow and shrink dynamically and uses lots of overhead to do so. No? Best, Henry
  16. Wait, BoostC supports recursion??? Could have fooled me. I've never been able to get it to work. What's your trick? I thought the way the stack worked on a PIC made recursion pretty much impossible. Regards, Henry
  17. I thought it was partly for this, but mostly because lower case is easier to type!
  18. This bug has been thoroughly discussed (in fact waaay over discussed) here: http://forum.sourceboost.com/index.php?showtopic=4229 The gist of that discussion is that a good solution that accomodates both 8 and 16 bit EEPROM addresses while minimizing overhead has been developed for a bug-fix release but we're all still waiting for it... In the mean time, most of us are using Reynard's solution which is to roll your own. It's quite easy and the data sheet for every PIC18 part that I've seen has the code already written for you. Regards, -Henry
  19. Nigel, I haven't had any problems with the BoostC code for 32-bit variables, whether signed or unsigned. I've created a couple of projects for the 18F4550. One in particular had a lot of unsigned long logic and arithmetic. If you post your code we might spot something you need to do that is unique to BoostC.
  20. Hi davidb, I'm aware of the 4 asm instructions that get generated when you assign a 16-bit value in RAM. It doesn't work with all the SFRs, perhaps because they're not always contiguous or special buffering etc but I think you're right it would probably work with these. Where I'm still confused is why you don't want to write a byte to each register (or only one if EEADRH is not defined) instead of always writing 16 bits to two consecutive addresses and the associated problems with that. Or why you thought the directive testing for EEADRH in the header with a new lib would result in a short being truncated using Pavel's proposal? Your post suggests that I must have misunderstood you somewhere along the way, or vice-versa. You seem plenty knowledgable so I apologize if missed something. We're satisfied with Pavel's proposal so perhaps we should move on to more important things... Regards, Henry
  21. That is the problem I was referring to in post 14 when I said: "Pavel, why wouldn't you do it like this which would prevent somebody from accidentally linking in both overrides and then writing code that would crash? A real possibility if they were porting some code from a 256 byte rom device to a part with > 256." The solution in my post would solve that problem and also David's concerns but wouldn't allow for a reduced overhead version on the long EE parts. Hence the reason for two libs. I'm glad it's worth your time Thanks, Henry
  22. Why not if it's used in the header file as Pavel is proposing? You can't use it in the .c file as I mistakenly suggested in post 14 because the libs are just that - libs and obviously not re-compiled on our end. The directive that checks for EEADRH ensures that we link in the correct overload of the fn without, like you said, directives for each part. There are several problems with this. First, I don't think you can update two registers at once like you are proposing due to hardware limitations. Correct me if I'm wrong - I hope I am because it would be a nice feature if we could do it! In other words, // Load address eeadr_16bit = address; cannot work on any PIC18 device because you can (generally) only write to one register at a time. Reading the datasheet would appear to confirm this. Again, let me know if I'm wrong. Also, the c code to be replaced has no directives as you show above. There would be 2 separate functions that both use the same name but different parameters. OK, they would each have different names in the lib due to name mangling but that would be invisible to you as the user. The linker would automatically link in the correct fn. Another problem is it would require the assumption that EEADRH and EEADR would have to be contiguous as you pointed out. I don't think Microchip has ever implied that this would be guaranteed even if it's usually true. Also most of us struggle at one time or another with a shortage of RAM and/or program ROM. With Pavel's proposal your existing code (on a < 256 byte ROM part) would compile and link with less overhead than if we were always forced to link in a version that was loading a short on the stack instead of a char (for the fn call) as well as making a 16 bit assignment in the lib instead of only char. And as you mentioned, it assumes eeadr+1 is unused. Pavel seems unconcerned about writing to unused addresses but I'm still shy about it, and his lack of concern may be due to eeadrh not being defined as eeadr+1. I'm not sure why function overloading would require two lib files but I don't write compilers... It seems to me that name mangling would take care of the problem and only the correct function would end up being linked into our file from the lib that contained the two overloads of each function. No? Regards, Henry
  23. Yes because the register is 8 bits for both of them. When eeadrh is defined, it is always defined as a char because these are 8-bit devices. No? Correct me if I am wrong, but what you seem to be implying is that if eeadr & eeadrh are in consecutive hardware registers in lo/hi byte order (as they probably are) then writing a short to just eeadr will also write the high byte of the short to eeadrh. Surely, this cannot be correct as shorts should always be converted (truncated). Writing a short to any char will only write the lo byte to the char and the top byte will be lost. However, if you defined eeadr (or a mirror of it to avoid confusion) as a short then writing a short to just eeadr should update both eeadr and eeadrh correctly. No. It's irrelevent whether eeadr & eeadrh are contiguous in the hardware. I think you are confusing the function parameter with the actual assignment within the function. First you pass a short to the function. Then the function takes the hi order bits of the short and assigns them to eeadrh. Then it takes the low order bits and assigns them to eeadr. Then it returns (OK it might do a couple other tasks). We never cared whether eeadr and eeadrh were in consecutive hdwr registers; we never tried to "write a short to just eeadr"; never had to cast a short to a char (implicitly or explicitly); we never lost any significant bits. Correct me if I'm wrong, but AFAIK these devices only do things 8 bits at a time (mostly!). What I learned that's new, if I understand Pavel correctly, you can assign something to a bogus address or register and it will have no side effect. Are you sure? I would have thought that would crash on the spot. Regards, Henry
  24. Do you mean the argument called "address" or the register eeadr? The latter will always be a char. That won't change in the re-write. The assignment isn't made until inside the body of the fn. The short won't ever be converted to anything else. The hi order bits will be assigned to eeadrh and the low order bits assigned to eeadr or eeadrl. I hope this clarifies Henry
×
×
  • Create New...