Jump to content

jrmymllr

EstablishedMember
  • Content Count

    18
  • Joined

  • Last visited

Community Reputation

0 Neutral

About jrmymllr

  • Rank
    Newbrie
  1. I'm using 18F86K22, and at the end of a compile I see: ROM available:131072 bytes I look back at the datasheet and it clearly states this part has 64K Flash. So I try the 128K version, 18F87K22 and see this after a compile: ROM available:262144 bytes Is this an error? I know how the Microchip datasheet states number of instructions, and bytes of memory, but the number of instructions is half the Flash size. So I don't see how the ROM (Flash) can appear double.
  2. I'm paranoid about wearing things out, so I always do this if data will change more often. I have used the "write at power down" by using LVD interrupt. It seems to be hit or miss. It's a great concept, but the reliability of that implementation takes some time to validate.
  3. I don't have that license yet. I was hoping Pavel or Dave would jump in soon and clarify this a bit. I could write my own, but have pushed off this issue as it's not holding me up right now. I'm actually doing wear-leveling of a small block of data, so for now I simply assume the EEPROM is only 256 bytes instead of 1024 on the prototype units.
  4. I did not realize goodies is an executable, I assumed it is a directory and knew I didn't have that. So, I tried running it, and it says how I need a license, etc. So it won't extract, however I have the full commercial license and the compiler says so when building. EDIT: I just figured out I have to run preg.exe first just like I did for the compiler, but it says "The name/key you entered does not appear to be valid. Please try again." Confused now. I'm using the same key I did for the compiler. Jorge I did try casting it yesterday, but that didn't work either.
  5. It doesn't seem to me like you can, but this conditional statement you speak of is related to the problem I think, because it behaves as if the address parameter is only a char. As for eeprom.c, I haven't been able to find this. I found eeprom.h, the .lib files, but no C source.
  6. No luck finding it in the forums. I could write my own, but for now I've put it off hoping for a fix so I don't have to spend time on it.
  7. Using the newest version of BoostC (which by the way is working great otherwise) on 18F86K22. I noticed something odd in a routine that I had working in HI-TECH. After some debugging, I figured out that when eeprom_write() is passed an address of 0x100, it writes to 0x00, and so on. So instead of passing it a variable containing the address, I did a test: eeprom_write(0x100, 0x55); eeprom_write(0x101, 0xAA); Low and behold, EEPROM addresses 0x000 and 0x001 now contain 0x55 and 0xAA respectively. In eeprom.h, I see this: #elif _PIC18 unsigned char eeprom_read( unsigned cha
  8. I'm really on a roll. This is possibly the 3rd compiler bug I've found in three different compilers in the last month or two. I say possibly because two are confirmed, including this one, and the 3rd one Microchip hasn't really admitted yet. Anyway glad to see this will get resolved. Pavel any idea on when the next release will be available?
  9. When the parser finds this two statements in the same "c" module (plus inclusions) it sees the 1 - The variable defined in this module 2 - The same variable declared as if it is defined in other module. Sample 2 - Function declaration When the parser finds this two statements in the same "C" module (plus inclusions) it sees the 1 - A function prototype. The function can be defined later in this same "C" module or in another one. 2 - The same function prototype but preceeded with "extern". As the compiler doesn't throw errors nor warnings at this it looks like: 2.1 - The compiler i
  10. The problem with this theory, and I just discovered this, is that if I change the function type from a function pointer to just a standard function, it compiles. So to illustrate: This doesn't work: BOOL( *functionname ) ( void ); extern BOOL( *functionname ) ( void ); This works: BOOL functionname( void ); extern BOOL functionname( void );
  11. I tracked it down further. In the .c file I have: BOOL( *functionname ) ( void ); In an included .h file, that function is extern'ed: extern BOOL( *functionname ) ( void ); When both these are present, it complains: error: variable 'functionname' already exists If I remove the "extern" line, that .c file compiles, but of course other .c files calling that function fail. Does BoostC use extern differently? Having an extern really shouldn't cause any problems. Even if I move the extern to the .c file in question, just to test, it still gives me the same "already exist
  12. I am trying to integrate a C library into my project and came across a problem. This library was compiling ok in HI-TECH, so the syntax is ok with at least that compiler. Here's the problem: The error in the subject line is generated when this line is in the code BOOL( *functionname ) ( void ); It is a function pointer that is set in the code depending on what mode it's in. If I comment it out, it compiles, but fails at link saying: Error: Failed to resolve external: functionname BOOL is already defined elsewhere. I'm stumped. Any ideas?
  13. The floating point numbers are IEEE754 single precision floating point numbers, that is a number with an 8 bit exponent and 24 bit mantissa, ie each floating point number uses 32 bits. The best way to describe them is that they support a precision of 24 binary digits. Yes. Limitations apply (no arrays of function pointers). Function declarations like "void strcpy( char *dst, const char *src )" are supported (are used in our library functions, take a look in string.h). I don't know the Hi-Tech compiler so can't comment. Regards Dave Hi Dave, this looks workable. I'm placing
  14. I've used AVRs a little, but the product I'm working on already has an 18F designed into it. In retrospect, I might have used a different chip, such as a dspic30F, if for no other reason to avoid the RAM banking the 8 bit PICs use. It's my assumption this is what's causing a lot of the issues with HI-TECH. Although I've heard very good things about AVR, I have little experience with them compared with PICs, as do my coworkers, but I'd like to check them out more when I have some spare time.
  15. What microcontroller(s) are you using? 18F8527, then later switching to 18F86K22.
×
×
  • Create New...