>-----Original Message-----
>From: spam_OUTpiclist-bouncesTakeThisOuTmit.edu [.....piclist-bouncesKILLspam@spam@mit.edu]
>On Behalf Of Peter Bindels
>Sent: 29 June 2007 09:23
>To: Microcontroller discussion list - Public.
>Subject: [PIC]/[EE] Small microcontroller with GCC support?
>
>
>Hello,
>
>I was thinking. I have been using PICs for a few times before,
>and I'm professionally speaking a software guy (up to the edge
>of hardware, but hobbyist beyond). For myself a simple
>processor with very advanced software support and easy
>hardware interfacing (as in, electrically) would be the ideal
>solution. That rules out any devices I can't solder (BGA,
>TQFP), devices with near-none software support (BASIC stamps)
>and devices with complex hardware interfacing (FPGA's with
>softcores). The only problem I have with SDCC (which I've used
>up to now) is that it doesn't support C++ or anything similar.
>
>I'm expressly not out to somebody telling me C++ in a 512 byte
>device is bollocks, I know that you can make C++ act like a
>pig but I also know that you can make it work like a fairy.
>
>What kind of device would I be best off with?

> #include <CRIT.h>
> #include <kbd.h.>
> #include <rs232.h>
> #include <timer.h>
>
> volatile int errors = 0;
> volatile int keycode = 0;
>
> void Rs232txd {
>   CRITA
>   if((rs232->status & RS232_TXEMPTY) && keycode) {
>     rs232->txd = keycode;
>     keycode = 0;
>   }
>   CRITZ
> }
>
> void ButtonsToSerial(void) {
>     CRITA
>     if(keycode) { // overrun
>       errors |= TXD_OVERRUN; // NOT throw(), oops
>       CRITZ // !!!
>       return;
>     }
>     keycode = kbd->keycode;
>     kbd->status & ~KEY_DOWN;
>     CRITZ
>     Rs232txd;
> }
>
> int main() {
>   timer_init();
>   rs232_init();
>   kbd_init();
>
>   timer_setup(0, TICKS);  // needed by kbd for debouncing
>
>   rs232->speed = RS232_SPEED;
>   rs232->txcallback = Rs232txd;
>   rs232_poll();
>
>   kbd->debounce = DEBOUNCE_CONSTANT;
>   kbd->callback = ButtonsToSerial;
>   kbd_poll();
>
> idle:
>   goto idle;
> }
>
> Yes, I know that you described an event driven model and I a timer driven aided
> one, but this illustrates just a little bit of what you need to implement to
> make your 'beautiful' main() work (20-50 more lines of code missing, to do the
> timer interrupts, the keyboard, and the serial and baud generator init). You or
> someone who implements it (the libraries) for you.

> wouter van ooijen wrote:
>
> >> I think Peter's point is that if you use a compiler in such an
> >> environment, you better make sure that what you need is explicitly
> >> specified as reentrant.
> >
> > That is essentially a strawman argument: bad implementations exist (or
> > could exist), so the language feature is bad.
>
> I don't think it's necessarily a strawman argument. It's difficult to get
> anything guaranteed by any software vendors these days; most things are
> specified as "it's working unless it doesn't" :)  The more complex a
> language is, the more difficult is it to make sure for yourself, and the
> more complex it may be to find out when something doesn't work as specified
> (which actually happens occasionally :).
>
> IMO this is one of the reasons why C has been around for so long in the
> area of small embedded systems: it's a workable compromise. (Which is not
> to say that other such compromises, and better ones for many situations,
> exist.)

> On 01/07/07, Gerhard Fiedler
> <EraseMElistsEraseMEconnectionbrazil.com> wrote:
> > wouter van ooijen wrote:
> >
> > >> I think Peter's point is that if you use a
> compiler in such an
> > >> environment, you better make sure that what you
> need is explicitly
> > >> specified as reentrant.
> > >
> > > That is essentially a strawman argument: bad
> implementations exist (or
> > > could exist), so the language feature is bad.
> >
> > I don't think it's necessarily a strawman
> argument. It's difficult to get
> > anything guaranteed by any software vendors these
> days; most things are
> > specified as "it's working unless it doesn't" :)
> The more complex a
> > language is, the more difficult is it to make sure
> for yourself, and the
> > more complex it may be to find out when something
> doesn't work as specified
> > (which actually happens occasionally :).
> >
> > IMO this is one of the reasons why C has been
> around for so long in the
> > area of small embedded systems: it's a workable
> compromise. (Which is not
> > to say that other such compromises, and better
> ones for many situations,
> > exist.)
>
> The sole reason why C is abundant in embedded
> systems programming is
> because C was abundant in embedded systems
> programming. Did you ever
> try to convince somebody to NOT do the tread path
> and to try something
> new? You should try - it gives you a whole new
> perspective on why
> Windows is used everywhere, why people keep using C
> for embedded
> systems and why people keep driving SUV's. The main
> answer is the
> Prisoners Dilemma, which (in short) says that you
> have to do
> everything that you could do to gain an advantage,
> and if you do
> something different you most likely have a
> disadvantage.
>
> People use C because they have code in C, people
> don't switch to
> Pascal because of their C code base. The only
> difference would be in
> startups - and notably startups have a high failure
> rate that isn't
> related to the language. Which leads to statistics
> showing that using
> C gives your project a low chance of failure (in a
> noncausal relation)
> causing all managers to flock to C. Again.
>
> As I've been sure of for 20 years (and given my age,
> that's an awful
> long time for me) people use what's known to work
> and if you're the
> one that produces what's known to work you only have
> to make your
> application sufficient. If people accept 10 crashes
> per day - so be
> it. The entire concept of brands and product lines
> never appealed to
> me but unfortunately I appear to be a strong
> minority in that. I'm for
> change if I see the results being better than
> before, even if I'm not
> sure that the results will be better.
>
> Apologies for the rant.
>
> Regards,
> Peter

> wouter van ooijen wrote:
>
> >> I think Peter's point is that if you use a
> compiler in such an
> >> environment, you better make sure that what you
> need is explicitly
> >> specified as reentrant.
> >
> > That is essentially a strawman argument: bad
> implementations exist (or
> > could exist), so the language feature is bad.
>
> I don't think it's necessarily a strawman argument.
> It's difficult to get
> anything guaranteed by any software vendors these
> days; most things are
> specified as "it's working unless it doesn't" :)
> The more complex a
> language is, the more difficult is it to make sure
> for yourself, and the
> more complex it may be to find out when something
> doesn't work as specified
> (which actually happens occasionally :).
>
> IMO this is one of the reasons why C has been around
> for so long in the
> area of small embedded systems: it's a workable
> compromise. (Which is not
> to say that other such compromises, and better ones
> for many situations,
> exist.)
>
>
> >> The exception mechanism is probably one of those
> possible problem spots,
> >> because by definition it has one single (global)
> exit point -- it
> >> usually ends up in main() if an exception doesn't
> get caught. So where
> >> does that leave the not caught interrupt
> exception?
> >
> > I am not familiar with the semantics of
> propagating an exception out of
> > the exception handler, ...
>
> If I were using a compiler that supports exceptions,
> I would want to know
> how my compiler handles this. I think if I need to
> be sure that exceptions
> are thread-safe, I need to know how they work
> (internally,
> implementation-wise, not how they are specified to
> work). Or have, for one
> reason or another, a lot of confidence in the word
> of others (usually in
> the form of good and proven documentation).
>
> > ... but if from your interrupt hndler you will use
> anything that can
> > throw an exception you'd better include an
> appropriate handler
>
> Exceptions may be thrown for any number of reasons,
> and not all have
> necessarily been thrown by your code (like division
> by 0 or stuff like
> this). Unless you can trust the compiler vendor's
> documentation 100% (or
> your own evaluation of the compiler's source code),
> you probably need a
> catch-all exception handler in any thread or
> independent interrupt code
> line if your compiler may throw exceptions -- even
> if your code doesn't
> explicitly throw any exceptions.
>
> One thing I have learned to appreciate when working
> with exceptions is a
> complete documentation of all exceptions that may be
> thrown (or re-thrown,
> or passed through) by any method (or operator, which
> is just a semantic
> form of a method). But this is not always given.
> (This is the same as with
> the code itself: often the documentation of the
> exceptions is three times
> more than the documentation of the method core
> function. Which is probably
> also the reason why it is so often incomplete...)
>
> (FWIW, I'm not arguing against the use of exceptions
> -- just in case :)
>
> Gerhard
>

> It's pretty questionable for the single-chip ARMs with 64k or
> less.  Our "embedded" systems allocate at 4k to 8k for each
> process or interrupt level stack (3 or 4 times that on RISC
> cpus, cause of the the potentially heftier context saving),
> and that's still for C.  We have relatively frequent arguments
> about C++, with the nay-sayers harping on just how easy it is
> to suddenly use up much more of one resource or another than
> you thought you were using.  To use C++ on a mid-sized
> microcontroller, you'd probably end up needing to restrict
> yourself to a subset of features and classes that not many
> people would still consider to be C++...

> On Jul 1, 2007, at 11:45 AM, Peter Bindels wrote:
>
>> People use C because they have code in C...
>
> I don't think your argument hold up very well.  Wasn't the original
> Apple OS written in pascal?  Wasn't ADA going to be required for all
> government-funded projects?  Was not PL/1 going to be THE language for
> anything IBM?  I don't recall C being heavily used in embedded projects
> 20 years ago; I recall it being barely available for computers as large
> as the IBM/PC of the day.

> Peter Bindels wrote:
> > Wasn't the original Apple OS written in pascal?
>
> I wonder if you were thinking of the very popular UCSD p-SYSTEM where the
> "native" compiler was Pascal?  I believe that much of the OS was written in a
> pascal language and then run interpretive on the "p-system".  A very popular
> platform for this were the Apple II's. This was circa early 80's or so.
>
>   Cheers,
>
>    Rich S.

> > The sole reason why C is abundant in embedded systems
> > programming is because C was abundant in embedded systems
> > programming.
> > (snip)
> > Apologies for the rant.
>
> But it is IMHO still true. But a mediocre standard is sometimes still
> better than no standard. If I learn my students some C that is very
> probably what they will need in their jobs. They have a hard time
> learning just C, I don't want to think of learning them CLU, Eiffel, a
> few Ada versions, C++, a bunch of pascal-with-objects, Modula 2,
> Haskell, Ruby, and a few more that I don't even know of.
>
> Wouter van Ooijen

> On 7/11/07, Olin Lathrop <RemoveMEolin_piclistspamBeGoneembedinc.com> wrote:
>
>  
>> There are just too many things broken in the C definition that I would never chose
>> C for any project of my own accord.
>>    
>
> Broken things, like what?
>
>
>  

>
>
> Rikard Bosnjakovic wrote:
> > On 7/11/07, Olin Lathrop
> <RemoveMEolin_piclistEraseMEspam_OUTembedinc.com> wrote:
> >
> >  
> >> There are just too many things broken in the C
> definition that I would never chose
> >> C for any project of my own accord.
> >>    
> >
> > Broken things, like what?
> >
> >
> >  

> > What is actually needed in embedded applications?
>
> The biggest complaint I have about high level languages is that they don't
> generate readable ASM code. No matter how hard the compiler writer tries,
> there is always some bug, some problem, or just some misunderstanding
> between what I wrote in the HLL and what it produced in ASM. So I need to be
> able to see that, and when necessary, comment out the line in the HLL and
> inline MY assembly so I can get the freaking job done.
>
> I have to agree with Olin that any HLL for the PIC should work with MPASM.
> Including macros.
>

> Walter Banks wrote:
> > Constant execution time has two open problems.
> > How to specify the constraint.
>
> Probably a special block for that purpose:
>
>   fixedtime 10 us begin
>     blah
>     blah
>     blah
>     end
>
> > What to do about run time dependent code sequences.
>
> The block must have a single entry and exit.  If/then/else may be allowed
> and you pad the shorter case to match the longer case.  Loops are not
> allowed.  If any branch exceeds the time without padding then you get a
> compile time error.

>
> There is no need to solve all problems for all cases.  You can see how I
> handle this in assembler by looking at the WAITxxx macros in STD.INS.ASPIC
> at http://www.embedinc.com/pic.  They still require some counting of
> instruction cycles to use, but at least you can specify a fixed delay time
> and the right number of extra instruction cycles are inserted automatically
> depending on the instruction rate.  You can change the oscillator speed and
> rebuild, and the delays will still be correct in absolute time.
>
> A compiler could do basically the same, except it counts the fixed
> instruction cycles instead of the programmer supplying the count.

> Walter Banks wrote:
> > At high baud rates (10's of instructions per bit) might make a good
> > example test case.
>
> That's not "high" baud rate.  I once did a 9600 baud UART in a PIC with a
> 160KHz clock.  That comes out to 4.2 instructions per bit time.  Assembly
> time calculations added extra NOPs as needed for correct timing, including
> taking care of the cumulative error.
>
>  I'd be impressed if you can show me a HLL that can do this.

> Walter Banks wrote:
> > As soon as we start computing fractions of an instruction it
> > opens the question of  should we be taking advantage of the
> > instruction transfer edges to reduce jitter.
>
> I'm not sure what you mean by instruction transfer edges, but any one
> section of code can of course only take a integer number of instruction
> cycles.  The user may need to be a little clever to eliminate long term
> error, but this can still be done with abutting sections of specified
> execution time.