Re using BREAK in 'C'

[William "Chops" Westfield]

On Jul 1, 2009, at 10:07 AM, Olin Lathrop wrote:

> So show me something reasonable and useful you can do in C that you  
> can't in Pascal (again, I'm using Pascal only as a example because I  
> happen to know it well).

How about:
     /*
      * Our console uart is memory mapped
      */
     struct uart_type *console = (struct uart_type *)0x801000;

Please provide a pascal example that works with at least two different  
vendors' pascal compilers.  Of course, this is extremely "dangerous",  
but I think it's a fine example of exactly the sort of thing that  
caused less dangerous languages to be dismissed from consideration for  
"systems" programming.

BillW

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

William Chops" Westfield" wrote:
>> we're stuck with C because there is no viable
>> alternative, which is true but not the point.
>
> So how do you feel about Java ?

Java is a much better language in structure and a little better in syntax.
They tried to be too C-like and kept some of the annoyances.  But the most
important thing is they made it strongly typed checked.

Unfortunately Java isn't a true compiled language, which makes it useless
for many of the things I do.  I also don't like how a JVM has to be
installed just run a program, and how the programs don't just run at the
command line because you're actually running the Java interpreter and
passing the program as a argument.  Still, if I didn't already have
something that worked nicely with a lot of libraries that I was comfortable
with I might write general purpose host programs in Java occasionally.

When talking to high school kids just getting into programming I usually
recommend they learn Java.  It's much harder to develop bad habits in Java
than in C, it teaches the right kind of computer science concepts, it's
easily and freely available, and there is a lot of support out there.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Benjamin Grant]

can everyone seriously stop indulging Olin in his unpopular views of C? If
he doesn't see the purpose of using it let him be. Who cares, you're never
going to win against him and he loves having this conversation so just stop
responding to it.

On Wed, Jul 1, 2009 at 5:37 PM, William "Chops" Westfield <westfw@...>wrote:

>
> On Jul 1, 2009, at 10:07 AM, Olin Lathrop wrote:
>
> > So show me something reasonable and useful you can do in C that you
> > can't in Pascal (again, I'm using Pascal only as a example because I
> > happen to know it well).
>
> How about:
>     /*
>      * Our console uart is memory mapped
>      */
>     struct uart_type *console = (struct uart_type *)0x801000;
>
> Please provide a pascal example that works with at least two different
> vendors' pascal compilers.  Of course, this is extremely "dangerous",
> but I think it's a fine example of exactly the sort of thing that
> caused less dangerous languages to be dismissed from consideration for
> "systems" programming.
>
> BillW
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[William "Chops" Westfield]

On Jul 1, 2009, at 9:29 AM, Dave Tweed wrote:

> Turbo Pascal was only ever available on two architectures: Z80 and x86

Turbo Pascal also ran on the 68k based Macs.

BillW


--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Tamas Rudnai]

I think it is not a win or loose conversation. I love these conversations
too as many times some very important thoughts pulled out of someones head
that would never mentioned otherwise.

Tamas


On Thu, Jul 2, 2009 at 12:12 AM, Benjamin Grant <benjamin.grant@...>wrote:

> can everyone seriously stop indulging Olin in his unpopular views of C? If
> he doesn't see the purpose of using it let him be. Who cares, you're never
> going to win against him and he loves having this conversation so just stop
> responding to it.
>
> On Wed, Jul 1, 2009 at 5:37 PM, William "Chops" Westfield <westfw@...
> >wrote:
>
> >
> > On Jul 1, 2009, at 10:07 AM, Olin Lathrop wrote:
> >
> > > So show me something reasonable and useful you can do in C that you
> > > can't in Pascal (again, I'm using Pascal only as a example because I
> > > happen to know it well).
> >
> > How about:
> >     /*
> >      * Our console uart is memory mapped
> >      */
> >     struct uart_type *console = (struct uart_type *)0x801000;
> >
> > Please provide a pascal example that works with at least two different
> > vendors' pascal compilers.  Of course, this is extremely "dangerous",
> > but I think it's a fine example of exactly the sort of thing that
> > caused less dangerous languages to be dismissed from consideration for
> > "systems" programming.
> >
> > BillW
> >
> > --
> > http://www.piclist.com PIC/SX FAQ & list archive
> > View/change your membership options at
> > http://mailman.mit.edu/mailman/listinfo/piclist
> >
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.mcuhobby.com
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

William Chops" Westfield" wrote:
>     /*
>      * Our console uart is memory mapped
>      */
>     struct uart_type *console = (struct uart_type *)0x801000;

I guess this defines CONSOLE as a pointer to a record of type UART_TYPE and
sets the pointer pointing to address 801000h?  A comment or two would help.

Anyway to show the flavor I created a whole program in Pascal that pretends
to use memory mapped hardware registers, which I think was your point.  I
also wrote it more in the style and naming convetions I would have written
such a thing:

program x;

const
  adr_uart = 16#801000;         {address of memory mapped UART registers}

type
  uart_p_t = ^uart_t;
  uart_t = record               {memory mapped UART hardware layout}
    stuff: integer32;
    morstuff: integer32;
    end;

var
  console_p: uart_p_t;          {points to console output HW registers}

begin
  console_p := uart_p_t(adr_uart); {point to the console output regs}
  console_p^.stuff := 27;       {send value to console}
  end.

I did a whole program so that I could actually build it to make sure I
didn't mess up something.  This program builds and runs on Windows.  Not
surprisingly is results in a popup about the program performing a illegal
operation when run.  Since my Pascal is implemented as a source to source
translator and the output is for MSVC on Windows, this also created a
temporary C file:

extern void string_cmline_set (
  int,
  char *,
  char *);

/*****************************
**
**   Start of program X.
*/
#define adr_uart_k 8392704
typedef struct uart_t {
  int stuff;
  int morstuff;
  } uart_t;

typedef uart_t *uart_p_t;

__declspec(dllexport) int main (
    int argc,
    char * argv) {

  static uart_p_t console_p;

  static int int_1 = 8392704;
  /*
  **   Executable code for program X.
  */
  string_cmline_set (argc, argv, "x");
  console_p = *(void * *)&int_1;       /* 8392704 */
  console_p->stuff = 27;
  return 0;

  #undef adr_uart_k
  }

Ignore the STRING_CMLINE_SET stuff.  That is implicit initialization added
to the start of all top level programs in my environment on Windows.  The
__DECLSPEC is unique to the Windows target platform.  Also keep in mind that
the above C was written by a machine for a machine, so its appearance and
style may look a bit strange and awkward, and it should really be judged by
the machine code a reasonable C compiler would produce from it.

> Please provide a pascal example that works with at least two different
> vendors' pascal compilers.

No, you're missing the point again.  We're talking about computer science
concepts, not particular implementations.  The point is that what you want
to do is possible in a more tightly typed language like Pascal.  A single
instance is proof enough.  Anyone can install my Windows host build
environment and verify this for themselves if they think I'm cooking the
data somehow.

> but I think it's a fine example of exactly the sort of thing that
> caused less dangerous languages to be dismissed from consideration for
> "systems" programming.

I don't see why.  A variant of Pascal (call it Pascal-like if you prefer)
was used to write the Apollo Aegis operating system.  Someone else pointed
out that a similar language was used to write the original Apple OS.

People seem to forget that tight type checking only means that typing rules
are enforced unless you explicitly say otherwise, as I did in using the data
type UART_P_T as a "type transfer function" in the first executable
statement.  I could have also used UNIV_PTR instead, but that would have
turned off more type checking than necessary.  UNIV_PTR is roughly like a C
void*.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Tamas Rudnai]

On Wed, Jul 1, 2009 at 11:37 PM, William "Chops" Westfield
<westfw@...>wrote:

> How about:
>     /*
>      * Our console uart is memory mapped
>      */
>     struct uart_type *console = (struct uart_type *)0x801000;
>
> Please provide a pascal example that works with at least two different
> vendors' pascal compilers.  Of course, this is extremely "dangerous",


I do not know any other Pascal than Turbo Pascal, but with that you could
declare a variable right on top of a memory location you desire:

var myloc : byte absolute $891000;

you could do things like this:

reg.ax:=$0003;
intr($10,reg);

or

mem[$A000: y*320+x]:=c;

you have pointers, binary operators -- but you do not have bitfields and
printf format strings. I think only these two things were what I liked a bit
more in C plus the for loop in C. What hard was to learn is why can't i just
define specific index range for an array and why the switch..case has that
few possibilities in C. Also that there is no equivalent of 'with' directive
in C and that I could not declare functions inside other functions. Actually
I did feel that C was a backup after Turbo Pascal and pain to use, but that
was the stream you had to swim in.

Tamas

>
> but I think it's a fine example of exactly the sort of thing that
> caused less dangerous languages to be dismissed from consideration for
> "systems" programming.
>
> BillW
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.mcuhobby.com
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Alan B. Pearce-2]

> I think we all agree that's where we are today.  All my point is that
> while we may be forced to use C today, we should complain about it
> whenever possible.

Complaining that their is no alternative does nothing useful. A better
proposition would be to work with someone like Mikroelektronika who do a
Pascal for PICs, to help them improve it, and maybe even port it to other
processors, which may help it get the critical mass ...

http://www.mikroe.com/en/compilers/mikropascal/pic/

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Alan B. Pearce-2]

>So yes there is a alternative or two, but only for small values
>of "alternative".  Actually the only one I can think of off the
>top of my head that supposedly is more than a toy is XCSB.

Well this does seem to be a reasonably comprehensive set of alternative
tools.

http://www.mikroe.com/en/compilers/

At least two more languages than Microchip provides ...

There are other providers of basic for PICs, in various forms as well. I
haven't had a chance to 'play' with any of these alternative languages, so
cannot comment on the quality of any of them.

I had the impression that JAL is a reasonably mature item as well, even
though you seem to write it off.

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Alan B. Pearce-2]

>Consider UCSD pascal, which was one of the larger efforts,
>designed to be portable/etc.  But it had a pretty
>significant performance penalty over true compilers;

I don't recall that being the reason it died - but the reason it died may
have been what put people off Pascal ...

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Rob Hamerling-3]

Hi Alan,

Alan B. Pearce wrote:

> I had the impression that JAL is a reasonably mature item as well, even
> though you seem to write it off.

Glad you bring it up. Jal (JalV2) is alive and well, not only the
compiler itself is still maintained and further developed, but there is
also a group of people building a set of libraries. Details:
compiler: http://www.casadeyork.com/jalv2
libraries: http://code.google.com/p/jallib

Regards, Rob.

--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Michael Rigby-Jones-2]

 

>
> William Chops" Westfield" wrote:
>
> > Please provide a pascal example that works with at least
> two different
> > vendors' pascal compilers.
>
> -----Original Message-----
> From: piclist-bounces@...
> [mailto:piclist-bounces@...] On Behalf Of Olin Lathrop
> Sent: 02 July 2009 01:00
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] using BREAK in 'C'
>
> No, you're missing the point again.  We're talking about
> computer science concepts, not particular implementations.  
> The point is that what you want to do is possible in a more
> tightly typed language like Pascal.  A single instance is
> proof enough.

I think you are missing Bills point.  Can you take the code you have
just written and be sure it will compile and work on any arbitrary
Pascal compiler?  Would you really want to have to have a diffierent
implementaion of this code for each target you want to use it on?

Most of the projects I work on keep the CPU pretty busy with a lot of
completely separate tasks, but since we don't use an RTOS, each task is
impleneted using a state machine.  All variables that are only used by
the task (e.g. the timer and state variable) are declared static within
the task function, since they need to retain their values between calls.

#define MY_TASK_PERIOD_MS 15

void MyTask( void ) {
    static int my_task_state = 0;
    static tickms_t mytask_time;

    switch( my_task_state ) {
        case 0:
            /* Initialise timer */
            mytask_time = StartTimer( MY_TASK_PERIOD_MS );
            my_task_state = 1;
            break;

        case 1:
            /* new state dpends on function return */
            my_task_state = ( MyFunc() )? 2 : 3;
            break;
       
        case 2:
            /* some stuff */
            break;

        case 3:
            /* some other stuff */
            break;

        case 4:
            if( TimerExpired( mytask_time ) ) {
                        mytask_time = StartTimer( MY_TASK_PERIOD_MS );
                        my_task_state = 1;
            }
            break;

        /* etc...etc... */
    }
}

When I last used Pascal (a long time ago admittedly), I could find no
way of defining static variables within a function, so end up using
globals which is very ugly.  Has this situation changed?

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Alan B. Pearce-2]

>I think you are missing Bills point.  Can you take the code
>you have just written and be sure it will compile and work
>on any arbitrary Pascal compiler?  Would you really want to
>have to have a diffierent implementaion of this code for each
>target you want to use it on?

Have you looked at the conditionals inside Microchip code to cover
differences between C18 and C30/C32 ???

And these are compilers from a single source ...

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Bob Ammerman]

> William Couture ha scritto:
>> Seriously.  I use C every day.  I never run into stupid problems from
>> trying to write something like Duff's device because I would never
>> try to bend/break the language like that (and the compiler I use most
>> gives me compile errors on that code).

Then the compiler you use most is not (ANSI) "C".

-- Bob Ammerman
RAm Systems

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[John Ferrell-5]

OK, I yield on the FORWARD aspect.

John Ferrell  W8CCW

"Extremism in defense of liberty is no vice, and moderation in pursuit of
justice is no virtue."
-Barry Goldwater
"You don't get harmony when everybody sings the same note."
-Doug Floyd

----- Original Message -----
From: "Wouter van Ooijen" <wouter@...>
To: "Microcontroller discussion list - Public." <piclist@...>
Sent: Wednesday, July 01, 2009 2:10 PM
Subject: Re: Re [PIC]using BREAK in 'C'

>> And NO FORWARD declarations please! A single pass compiler is fine.
>
> Do you realize that you have ruled out mutual recursion?
>
> --
>
> Wouter van Ooijen
>
> -- -------------------------------------------
> Van Ooijen Technische Informatica: www.voti.nl
> consultancy, development, PICmicro products
> docent Hogeschool van Utrecht: www.voti.nl/hvu
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Michael Rigby-Jones wrote:
> I think you are missing Bills point.  Can you take the code you have
> just written and be sure it will compile and work on any arbitrary
> Pascal compiler?  Would you really want to have to have a diffierent
> implementaion of this code for each target you want to use it on?

That would be a relevant question if we were chosing a compiler from today's
available choices.  I was only pointing out that C is a really bad language
and used some examples based on Pascal to show there are other ways.  I'm
not advocating Pascal either, but its concepts are useful as counter
examples to C, especially since I'm pretty familiar with a language based on
those concepts.

> When I last used Pascal (a long time ago admittedly), I could find no
> way of defining static variables within a function, so end up using
> globals which is very ugly.  Has this situation changed?

There are several ways to define static variable.  One is to put variables
at the module level outside any function:

module xxx;

var
  ii: integer32;  {static variable with module scope}

procedure aaa;
begin
  end;

procedure bbb;
begin
  end;

Subroutines AAA and BBB can both reference the static variable II.  This is
useful when a subsystem needs private state that several of its routines
need to access.

Another way is to define the variable in a specifically named section:

procedure aaa;
var (mysection)
  ii: integer32;  {static variable with subroutine scope}
begin
  end;

Of course the choice of section name may be dependent on linker conventions
and definitions in other non-code files, such as the MPLINK control file on
PIC targets.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

Olin Lathrop wrote:

> William Chops" Westfield" wrote:
>> Please provide a pascal example that works with at least two
>> different vendors' pascal compilers.
>
> No, you're missing the point again.  We're talking about computer
> science concepts, not particular implementations.  The point is that
> what you want to do is possible in a more tightly typed language like
> Pascal.  

I'm not sure I follow you. I at least never doubted that almost
everything that can be done with C can be done with any reasonable
Pascal dialect. I did much of it with Turbo Pascal... so this is not
really the question. And it's not the question Bill asked.

(FWIW, I think the main thing that C has that's missing from even decent
Pascal dialects is the precompiler. This is a quite useful tool for many
things the normal language can't do efficiently, but of course you can
use 3rd party preprocessors to help with that.)

But you're talking about popularity, availability. This is not a
computer science concept, this is a market concept. And for any language
to beat C in popularity in the (small micro embedded) market, it's not
enough that it is "better" in terms of computer science; the market
doesn't follow computer science concepts.

This is the thing you seem to get confused. The reason why C is more
popular has nothing to do with computer science concepts, and the reason
why Pascal almost completely lost its edge (don't forget that it had its
shot, was almost there, then squandered it) has nothing to do with
computer science concepts either.

As long as you dismiss the popularity of C as a big conspiracy of
idiots, you'll fail to learn the lesson from it (and to learn the lesson
from the fall into oblivion of Pascal). It could show you what is needed
for a language to become popular in a variety of markets. Bill's
question about code that works with two vendors' compilers goes in this
direction (and the "two vendors" part /is/ essential), and obviously has
nothing to do with computer science -- just as today's popularities of C
and Pascal have nothing to do with computer science.

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Gerhard Fiedler wrote:
> I'm not sure I follow you. I at least never doubted that almost
> everything that can be done with C can be done with any reasonable
> Pascal dialect.

Others do seem to doubt it though.  One of the technical arguments that
several people have made here recently is that you can "do anything" in C,
implying you can't do it in other languages.

> (FWIW, I think the main thing that C has that's missing from even
> decent Pascal dialects is the precompiler.

I agree.  A preprocessor can be a powerful addition to any language.

> But you're talking about popularity, availability.

No, I'm specifically not.  I understand how C got where it is and that today
you have to use it regardless of technical merits.  The part I'm trying to
point out is that C sucks technically, because too many sheeple use C and
don't see a problem with that.  I'm not saying there is a handy solution
because I don't see one either.  But the realization that it would be nice
if there was one is something too many people haven't made yet, and that's
what I'm trying to get them to see.  There are still people in this world
that actually *like* C (and I don't mean in the business sense), as
evidenced by several of the responses here.

> This is the thing you seem to get confused. The reason why C is more
> popular has nothing to do with computer science concepts,

No, in fact I've been trying to point that out.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[John Ferrell-5]

I own & use mikroelektronica Pascal. I like it. The support is great. The
marketing plan is great: no charge for up grades. Nice IDE. Hardware
available that allows really quick compile - test cycles. Unfortunately, it
is (like all other embedded compilers) a limited subset of the "real"
Pascal. It lacks the following:
With statements
Variant Records
A DEFINE compiler directive like c

and a few others.


John Ferrell  W8CCW

"Extremism in defense of liberty is no vice, and moderation in pursuit of
justice is no virtue."
-Barry Goldwater
"You don't get harmony when everybody sings the same note."
-Doug Floyd

----- Original Message -----
From: "Alan B. Pearce" <Alan.B.Pearce@...>
To: "Microcontroller discussion list - Public." <piclist@...>
Sent: Thursday, July 02, 2009 4:36 AM
Subject: Re: Re [PIC]using BREAK in 'C'

>> I think we all agree that's where we are today.  All my point is that
>> while we may be forced to use C today, we should complain about it
>> whenever possible.
>
> Complaining that their is no alternative does nothing useful. A better
> proposition would be to work with someone like Mikroelektronika who do a
> Pascal for PICs, to help them improve it, and maybe even port it to other
> processors, which may help it get the critical mass ...
>
> http://www.mikroe.com/en/compilers/mikropascal/pic/
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

John Ferrell wrote:

> I own & use mikroelektronica Pascal. I like it. The support is great. The
> marketing plan is great: no charge for up grades. Nice IDE. Hardware
> available that allows really quick compile - test cycles. Unfortunately, it
> is (like all other embedded compilers) a limited subset of the "real"
> Pascal. It lacks the following:
> With statements
> Variant Records
> A DEFINE compiler directive like c

FWIW, the C #define is /not/ a compiler directive, it is a preprocessor
directive. If Mikroelectronica's IDE allows you to configure a command
to be run on the file before compiling, then you can bind in a 3rd party
preprocessor to give you this. If it doesn't but has a command line for
the compiler, you can use a 3rd party editor or IDE and do it there.

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist