...
Try defining a properly with:
union hello { struct foo { unsigned char a; unsigned char b; } foo; unsigned char ppp[2]; }; union hello test; void main(void) { test.foo.a = 5; test.ppp[0] = 50; /* overwriting foo.a */
Note the use of foo.
-- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems.
In message , drwho writes
Then you need to STOP PROGRAMMING and look at the architecture of the parts. Understand the hardware environment. Programming embedded systems REQUIRES a knowledge of the hardware. Especially in the 8 and 16 bit areas.
You will not get a fully ISO C compliant compiler for the PIC. It's architecture will not permit it. You need to write C for the PIC not portable C is you want to get any sort of efficiency out of it.
In which case READ THE COMPILER MANUAL not the ISO standard.
Sounds rerasonable
Not a chance.
The PIC is a real processor (not that I am keen on it) Don't blame the processor because you cant read the manual.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
architecture will not permit
sort of efficiency out of
Just out of interest, which bits of ISO C can't the PIC do?
cheers, Rich.
-- rich walker | Shadow Robot Company | rw@shadow.org.uk technical director 251 Liverpool Road | skype: rich_at_shadow need a Hand? London N1 1LX | +44 20 7700 2487 http://www.shadowrobot.com/hand/
Which ISO C?
This is not a trick question.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Which is what I meant.
Though off the top of my head ISO C requires levels of nesting and sizes of structures that the PIC is not physically capable of holding.
Almost impossible and AFAIK more 8 bit compilers don't do recursion as standard. You usually need non-standard keywords or declarations to do it.
Exactly. So you need to understand the architecture and the compiler rather than the C standard.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
architecture will not permit
sort of efficiency out of
There are no bits of standard C that the PIC can't do, at least in theory - but there are plenty of things that it can't do efficiently, and which compilers might therefore not support. Things like recursion would be a serious pain to implement. General data pointers would be very inefficient (at least on the PIC16 - I don't know the PIC18) unless the compiler was particularly smart and the code amenable (so that the compiler could turn the pointers into segment-specific pointers on the fly). That's just two examples - I'm sure there are more.
mvh.,
David
architecture will not permit
sort of efficiency
but there are plenty
not support.
structures that the PIC
Right - yes, that's a good point.
standard. You usually need
sdcc seems to support it pretty happily. This:
int recurse(int a) { if (a>1) return 1+recurse(a-1); else return a; }
gets compiled into
;-------------------------------------------------------- ; global & static initialisations ;-------------------------------------------------------- ; I code from now on! ; ; Starting pCode block S_recurse__recurse code _recurse: ; .line 3; recurse.c int recurse(int a) { MOVFF FSR2L, POSTDEC1 MOVFF FSR1L, FSR2L MOVFF r0x00, POSTDEC1 MOVFF r0x01, POSTDEC1 MOVFF r0x02, POSTDEC1 MOVFF r0x03, POSTDEC1 MOVLW 0x02 MOVFF PLUSW2, r0x00 MOVLW 0x03 MOVFF PLUSW2, r0x01 ; .line 4; recurse.c if (a>1) MOVF r0x01, W ADDLW 0x80 ADDLW 0x80 BNZ _00111_DS_ MOVLW 0x02 SUBWF r0x00, W _00111_DS_: BNC _00106_DS_ ; .line 5; recurse.c return 1+recurse(a-1); MOVLW 0xff ADDWF r0x00, W MOVWF r0x02 MOVLW 0xff ADDWFC r0x01, W MOVWF POSTDEC1 MOVF r0x02, W MOVWF POSTDEC1 CALL _recurse MOVWF r0x02 MOVFF PRODL, r0x03 MOVLW 0x02 ADDWF FSR1L, F INCF r0x02, F BTFSC STATUS, 0 INCF r0x03, F MOVFF r0x03, PRODL MOVF r0x02, W BRA _00108_DS_ _00106_DS_: ; .line 7; recurse.c return a; MOVFF r0x01, PRODL MOVF r0x00, W _00108_DS_: MOVFF PREINC1, r0x03 MOVFF PREINC1, r0x02 MOVFF PREINC1, r0x01 MOVFF PREINC1, r0x00 MOVFF PREINC1, FSR2L RETURN
don't know the PIC18)
compiler could turn
examples -
Yes; library calls for pointer dereferences suck...
than the C standard.
That's a given in embedded programming :->
-- rich walker | Shadow Robot Company | rw@shadow.org.uk technical director 251 Liverpool Road | skype: rich_at_shadow need a Hand? London N1 1LX | +44 20 7700 2487 http://www.shadowrobot.com/hand/
But the professional compilers don't . There is probably a good reason for that
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
writes
standard. You usually need
Too hard for them? :-)
No, seriously, if there is, what would it be?
-- rich walker | Shadow Robot Company | rw@shadow.org.uk technical director 251 Liverpool Road | skype: rich_at_shadow need a Hand? London N1 1LX | +44 20 7700 2487 http://www.shadowrobot.com/hand/
Rich,
The root reason is re-entrant code makes RAM space indeterminate. The practical reason it is rarely needed in real embedded applications after tail end recursion and all of the normal optimizations are applied.
There have been some very scary software faults reported over the last 20 years traced to recursive code and stack creep.
The one I am most familiar with was the anti-lock brakes on a well known German car in the early nineties. It detected the fault and just turned the anti lock brakes off.
In our tools we handle re-entrant functions and non-reentrant differently. We don't have special directives for re-entrant code.
Regards
Walter Banks Byte Craft Limited Tel. (519) 888-6911 Fax (519) 746 6751
Rich Walker wrote:
writes
standard. You usually need
Yes it is. Try just section 5.2.4.1 of the C99 standard. For a starter.
-- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems.
---8 In message , drwho
---8
For a start - there is no GCC implementation for the PIC18 that I am aware of - although there is a good one for the PIC24 and dsPIC.
You can search this group for posts by Chris to see his opinion on GCC.
-- Regards, Richard. + http://www.FreeRTOS.org 13 official architecture ports, 1000 downloads per week. + http://www.SafeRTOS.com Certified by TÜV as meeting the requirements for safety related systems.
Isn't this the "we're assuming you've got 512KB of ram on the target" section?
-- rich walker | Shadow Robot Company | rw@shadow.org.uk technical director 251 Liverpool Road | skype: rich_at_shadow need a Hand? London N1 1LX | +44 20 7700 2487 http://www.shadowrobot.com/hand/
Microchip is an excellent company, on some fronts. They treat smaller companies generally quite well, have had in the past well informed technical support staff with genuine personal software development experience as well as a good hardware understanding (and I mean this in comparison to other micro manufacturers' technical support staff, which have been consistently inferior to those at Microchip), they track problems in a consistent fashion you can understand, and they support their professional tools almost forever. Old chip production tools are supported far longer than I've found elsewhere. As in, I've never had them tell me "we don't support that anymore and cannot get you a replacement." I'm sure they have their problems, as well.
Which version?
The PICs have an instruction set and/or a page control register (depends on which PIC how much of what is what) that makes it "easy" to access variables on a "base page" that is 256 bytes in size. This means that you will want to place variables there, those which need faster access and/or where you think it may help in terms of code size because of the number of places that reference them. You don't have to do that. But if you want that advantage, you need to let the compiler know what you consider a high priority for that, so it can do it. I suppose they could have written something to take a more general clue from you (size vs speed, for example) and "figure some things out" on its own. But instead they just let you wrap the definitions so that the compiler is directed what to do about that.
Roughly speaking. The 18-series is better about this than some of the
16F-series, themselves better than some of the old 16C-series, if memory serves. But having programmed PICs since 1989, I might be mixing in a few experiences. Things vary a little. And the PIC18's are definitely nicer, in this regard.I don't recall that requirement. I believe in some code I wrote for the 18-series (it's been a few years, so forgive my memory), I could just declare the variables and the compiler/linker placed them 'satisfactorily.' I wrapped definitions that I cared to place on the base page (0), that's all.
The C18 compiler uses #pragma's. Use something like:
#pragma udata access myarea // definitions go here #pragma udata
to wrap your variable definitions. The C18 compiler (I don't think it works on PIC16's) uses the term 'access' to mean the faster access ram in bank 0.
Read the C18 compiler manual and look for those terms.
Jon
Yes, thought it's not quite that severe.
But the fact that a device isn't large enough to hold a 4095 character string literal doesn't mean it can't run conforming C programs. It just means that it can't run *all* conforming C programs.
-- John W. Temples, III
No, but it does mean that you lose (at least some of) the primary advantage of standard C; knowing it will execute on all systems meeting the ISO standard. This is obviously not fatal, but the designer needs to be aware.
-- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems.
No platform can.
--
Grant Edwards grante Yow! We have DIFFERENT
at amounts of HAIR --
visi.com
Handling re-entrant and non-reentrant functions differently is what I'd expect of any 8051 (or other similar 8-bit cpu) compiler. Some compilers may need help from a keyword to identify re-entrant code - others can figure it out automatically. What I think Rich found strange was Chris' claim that "professional" compilers would not support recursive code at all. As you say, recursion is not much used in 8-bit systems - and if it is, it's probably a bad idea. But it's still part of the C standards, and I would expect any decent C compiler to support recursive functions if that's what the programmer gives them (as long as it does not mean all other code is hobbled with software stacks just in case they are called recursively).
mvh.,
David
writes
standard. You usually need
The original suggestion was to "use GCC with a real processor like and (sic) AVR, MSP, or ARM7".
Chris has been known to post on reflex whenever he sees the three letters "g", "c", and "c" together, at least in the context of small microcontrollers. Hence the reply apparently came *before* he'd read to the end of the sentence.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.