(sdcc)
You said that you were compiling for the pic18f2550, but according to the sdcc manual, it only supports pic14 and pic16. Support for pic18 is supposedly still a work in progress.
- Vote on answer
- posted
12 years ago
overflow in supposed to be unsigned long
Loading thread data ...
- Vote on answer
- posted
12 years ago
Its the family name, pic18f2550 is a pic16 says sdcc
-- - stoffer
- Vote on answer
- posted
12 years ago
Also overflows at 65535 :-/
- kristoffer ek
- Vote on answer
- posted
12 years ago
also overflows at 65535...
(complete code at )
- kristoffer ek
- Vote on answer
- posted
12 years ago
It sounds like your compiler thinks that 16 bits is long enough. That just should not happen.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
- Vote on answer
- posted
12 years ago
Completely different family.
- Vote on answer
- posted
12 years ago
Well, it usually works ,-)
-- - stoffer
- Vote on answer
- posted
12 years ago
If i declare my byte-variables as unsigned long it works:
unsigned long long_counters[4];
long_counter = long_counters[0] | (long_counters[1]
- Vote on answer
- posted
12 years ago
Sounds like you need to do a couple of things:
- Look at the assembly code.
- Make sure your compiler doesn't use 16 bits as sizeof(long);
Mark Borgerson
- Vote on answer
- posted
12 years ago
[...]
Yes, it does.
Note: The integer promotions _are_ performed.
Note: The _value_ of the right operand.
Regards,
-=Dave
- Vote on answer
- posted
12 years ago
No it doesn't.
Your comments are silly and pointless. The type of a promoted unsigned char is int. If int is 16 bits (most likely in this case) then 16 bits is not enough to store the result of char_counter[i]
- Vote on answer
- posted
12 years ago
No, he's right.
Look at your previous post:
pic14? Doesn't that set alarm bells ringing?
sdcc classifies the PIC families by their instruction width. "pic12" (not supported by sdcc) means 12-bit instructions (PIC10, low-end PIC12), "pic14" is 14-bit instructions (high-end PIC12, PIC16), "pic16" is 16-bit instructions (PIC18). So a PIC18F2550 is actually a "pic16" target in sdcc's terminology.
But that's beside the point. Using sdcc for anything other than 8051 is asking for trouble. The other targets are not-even-alpha quality (even after you deal with its use of "generic" pointers for PIC18 rather than having distinct code/data pointers, meaning that it's never going to compile Microchip's reference code).
- Vote on answer
- posted
12 years ago
8
The PIC16Fxxx are refered to as PIC14 by SDCC because it has a 14 bit instruction code. The PIC18Fxxx ar referred to by the instruction width if 16 bits, thus with SDCC call the code for the PIC18Fxxx "PIC16" code :(
- Vote on answer
- posted
12 years ago
LOL. Thanks for the explanation.
Best regards, Spehro Pefhany
-- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
- Vote on answer
- posted
12 years ago
If you think so, you haven't looked on (nor even successfully tried to imagine) ny platform where the problem at hand even exists to be solved.
Either that, or you need to smoke less of that funky stuff.
Yeah, so what?
That doesn't have any effect either.
The problem was that the type of the _left_ operand of that
- Vote on answer
- posted
12 years ago
8);
You may hate casts, but the code above won't work properly on machines with 16 bit ints, since the expression 'char_counter[i]
- Vote on answer
- posted
12 years ago
Kudo's for doing a comprehensive test!
Groetjes Albert
--
-- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst