Jump to content

DarrenJ

EstablishedMember
  • Content Count

    11
  • Joined

  • Last visited

Community Reputation

0 Neutral

About DarrenJ

  • Rank
    Newbrie
  1. tectona I think you will find that in equation 1 all the stuff on the right hand side is performed at the precision of the variables on the right hand side; ie a and b, so unsigned int. When the calculations are finished the result is converted to a signed int and assigned to c. In the second calculation the subtration is correctly converted to a signed int in the first statement. Then the second and third statements are performed at a signed int level instead of an unsigned int. I think?? this is C standard behaviour. I also think that if you want to change it, you can just cast it to an signed int eirlier. (NB: I haven't tried on this compiler) c = ((((signed int)(b-a))*100)/b); or use; signed int d; signed int e; d = a; e = b; c = (((e-d)*100)/e); or step it through as in your second example. c = (b-a); c *= 100; c /= b; perhaps it might also work like: c = (b-a); c = (c*100)/b; As there is a signed int on the right, but I would have to read my C books again (and the compiler docs) to check that one. Hope that helps. Darren J
  2. It does not look like you are setting PORTA up properly. If you read the datasheet it says that on a POR RA5 and RA3-RA0 are configured as ANALOG inputs. IE input channels to the ADC. So you should turn the ADC off for a start as i believe this over-rides the TRISA settings. So simply add a line to make: on = 0x01; off = 0x00; PORTA = 0; /*clear PORTA */ ADCON1 = 0x07; /* turn ADC off */ TRISA = 0; /* configure PORTA for output */ and see how that goes. Darren J.
  3. When I put that #pragma into a program and look at the program memory the data is placed correctly at 0x1600 so you might want to check your read_flash() function, ensure you are using it's return value correclty, and also ensure you are programing that section of the program memory to the device. Darren J.
  4. Igor Well in that case what you have seems right. It's as good as you are going to get as far as C code. You might find you can write it differently for better assembly performance (but the differnece will be negligable). Darren J.
  5. izakdude Well in that case you could use the original variable name, or you could make a union with the struct and an unsigned char or something inplace of the struct. I often do this with flag variables, so I can clear them all at once by clearing the byte and check if any of them are asserted by checking if the byte is 0, before checking them all individually. Darren J.
  6. igor, I don't think this is required. Check your data sheet, but I assume it will be the same. Darren J.
  7. izakdude, I havent tried it but hyou might be able to do somthing like this yourself. If you make a typdef of a struct with 8 single bit values. Then create a pointer pointing to that type. You could then point the pointer to a port and use the pointer to struct bit to assign the bits of the port. typedef struct { unsigned 7:1; unsgined 6:1; unsigned 5:1; unsigned 4:1; unsigned 3:1; unsigned 2:1; unsigned 1:1; } BITS; then BITS * PORTAbits = &PORTA; then *PORTAbits->7 = 1; I havent tried anything like this, but it seems reasonable. The only thing I can see that might be a hastle is the bits might be in the wrong order here. Anyway I hope this helps rather than confuses. Darren J.
  8. Dave, Thanks that works . However wouldn't it be better to change #include <system.h> to #include <BoostC.h> in the library .c file, and mark all the controll register as extern in the library .h file extern volatile unsigned char sspstat; extern volatile unsigned char sspcon1; extern volatile unsigned char sspbuf; So that the lib can be used with any target with the relavent registors instead of just the 18f6720? Is there any problem with doing it this way ? Thanks Darren J.
  9. After looking at the code I noticed that I had extern variables in the library. extern bit tris_sdo;//serial data out pin extern bit tris_sdi;// serial data in pin extern bit tris_sc;//serial data clock pin extern bit tris_ss;// slave select pin (Only used in slave with slave select mode) Which I had defined in a header file bit tris_sdo @ TRISC . 5; // serial data out pin bit tris_sdi @ TRISC . 4; // serial data in pin bit tris_sc @ TRISC . 3; // serial data clock pin bit tris_ss @ TRISE . 7; // slave select pin (Only used in slave with slave select mode) Could this having extern var's in an 18F library cause the linker to try and link in all the possible address space for an 18F chip or something ? Scratches head. Darren J.
  10. I was trying to build some code for an 18F6720, with a library I wrote and compiled for 18F. The linker gave the errors Error: Failed to allocate memory for var "porth" at address:0x00000f87 Error: Failed to allocate memory for var "portj" at address:0x00000f88 Error: Failed to allocate memory for var "lath" at address:0x00000f90 Error: Failed to allocate memory for var "latj" at address:0x00000f91 Error: Failed to allocate memory for var "trish" at address:0x00000f99 Error: Failed to allocate memory for var "trish" at address:0x00000f9A Failure Exit code was -1. [No error.] I did not try to use these var's in my code. Now the target is an 18F6720 and doesn't have a porth or portj. So these var's shouldnt be linked in by the linker right ?. There is a portj and porth on the larger 18F8X20 devices, which are similar though. So I tried changing the target to an 18F850, and it built fine. Any help on what this problem is and how to overcome it would be great. Darren J.
  11. SnakeByte Did you try it with the string quotation marks? #define TEST "randomstring" or int SomeValue = "TEST"; DarrenJ
×
×
  • Create New...