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 char address ); void eeprom_write( unsigned char address, unsigned char data ); #ifdef EEADRH unsigned char eeprom_read( unsigned short address ); void eeprom_write( unsigned short address, unsigned char data ); #endif However if I attempted to define EEADRH (which I shouldn't have to) it complains. So I printed a message right after " #ifdef EEADRH" to check if it's using the prototypes where "address" is a short int instead of char, and it is using the short int version. What's going on here? Right after writing to 0x100, I check eeadr and eeadrh, and they are both zero.
  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 is accepting multiple copies of the same function prototype. This might be a consequence of it supporting function overloading. 2.2 - It is ignoring the all statement, just because is a second declaration (not definition) of the same function or as a side efect of the, AFAIK, "odd" usage of the "extern" qualifier. But, as I said its just my interpretation. A more in depth analysis would require a detailed review of some of the "C" standards, to see if the compiler is behaving correctly or not. Best regards Jorge For what it's worth, the code in question is the open source FreeModbus library, which compiled ok with HI-TECH, and is at v1.5 so it apparently has been around for awhile. It might be bad to assume this syntax is acceptable because of this, but that's my current thinking. Incidentally, I did see that a port of this same library is on the Sourceboost website, however ASCII mode was removed, leaving only RTU; therefore eliminating the need for these pointers. I don't know alot about the internal workings of C compilers, but would be curious as to what the BoostC authors have to say.
  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 exists" error. EDIT: Just found that this problem was reported in 2004, but has no responses! http://forum.sourceboost.com/index.php?showtopic=645
  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 an order for Pro as soon as I can get the purchasing information. The first things I'll be looking for when I do a successful compile is that it can produce correct code for these expressions: 1. a = 0xFFFF - (x * 100) + 42; 2. arrayname[y / 2] This might look like a joke, but HI-TECH consistently produced errant code in my situation, except for #2, which worked when it was put into the highest optimization level. For anyone who wants to try this on their HI-TECH compiler, don't bother. It'll likely work. It just doesn't work when thrown into my large C project.
  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...