Searching \ for '[EE]: Re: I say it is spinach . . .' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serial/spis.htm?key=spi
Search entire site for: 'Re: I say it is spinach . . .'.

Exact match. Not showing close matches.
PICList Thread
'[EE]: Re: I say it is spinach . . .'
2005\08\17@113257 by John Nall

picon face

I'm through with the original thread, having gotten it off my chest.  
But did want to follow up on one aspect:

> James Newton, Host wrote:
>
>> I guess my question would be how you would propose to bridge the gap
>> between the sort of IO, memory, etc... that C was designed for and
>> the sort of IO,memory, etc.. that the average PIC has?
>
It would be difficult, if not impossible, IMHO.  But C most likely is
the best starting point for such a task.  The real problem is that the
PIC programmer is not sufficiently shielded from the hardware.  And this
is a relatively easy problem to solve.  We solve it the way it has
always been solved -- by putting an interface between the programmer and
the hardware.

No matter what your opinion of DOS might be, it was an operating system
and ran well on some pretty insignificant chips.  The original Unix
operating system was very basic.  Andy Tanenbaum wrote a version of Unix
(which he called Minix) that supported multiple users on a 286 system.  
Linux Torvald's original Linux kernel was pretty elementary.  So for a
single user system, such as a PIC, a very elementary operating system
would not be a difficult thing to write.  A user would write his code,
link it with the OS, and load it into the PIC.  Reset would turn control
over to the OS, which would do the necessaries, and then turn control
over to the user program.  Interrupts would interrupt to the OS.  The
user would only make standard function calls in order to communicate
with peripherals.

Designing the system calls and hardware drivers would be the challenging
part of writing such an OS, but it does not seem like it would be all
that difficult, given a set of assumptions about what a programmer needs
to be able to do.  Someone who wanted to do something outside those
parameters could always go into machine language and do it, just as a
programmer is welcome (well, maybe not welcome, but allowed anyway) to
drive his own peripherals in Unix.

Once this was accomplished, then I think that a C-like language would be
a lot more feasible.  It still would not be C, but it could be very close.

John

2005\08\17@160356 by Peter

picon face

On Wed, 17 Aug 2005, John Nall wrote:

>>> I guess my question would be how you would propose to bridge the gap
>>> between the sort of IO, memory, etc... that C was designed for and the
>>> sort of IO,memory, etc.. that the average PIC has?
>>
> It would be difficult, if not impossible, IMHO.  But C most likely is the
> best starting point for such a task.  The real problem is that the PIC
> programmer is not sufficiently shielded from the hardware.  And this is a
> relatively easy problem to solve.  We solve it the way it has always been
> solved -- by putting an interface between the programmer and the hardware.

I don't know what got you people to take on C. C is a risc language with
25 (or less) reserved keywords. It does not have ANY built-in io, either
hardware or otherwise, and supports abstractions that allow access down
to a single bit, or at least boolean value.

All the problems are in the libraries, and in the extensions, not in
the language proper. People who take it for granted to use scanf() and
printf() (and fork()) in C programs have a problem when moving to
PIC16C54 platform. But the problem is still not with the language, it's
with the libraries (again).

So far, C has been ported to just about anything that (sometimes) has a
clock source and (sometimes) a reset pin. Unlike other high level
languages.

Peter

2005\08\18@020954 by Wouter van Ooijen

face picon face
> and supports abstractions that allow
> access down
> to a single bit, or at least boolean value.

It doesn't. The lowest abstraction level that is realy supported is the
byte (signed/unsigned char). That's one of the problems for PIC C
compilers.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\08\18@040536 by Peter

picon face

Re: no support for bit access in C: wrong ?

struct _packed_bits {
                unsigned int bit0:1;
                unsigned int bit1:1;
} packed_bits;

As usual it seems to be a compiler issue. The people who wrote C were
implementing an OS on a resource-limited machine and they almost
certainly thought about using bits as boolean flags.

Peter

2005\08\18@044709 by Electron
flavicon
face
At 11.06 2005.08.18 +0300, you wrote:

>Re: no support for bit access in C: wrong ?
>
>struct _packed_bits {
>                unsigned int bit0:1;
>                unsigned int bit1:1;
>} packed_bits;
>
>As usual it seems to be a compiler issue. The people who wrote C were implementing an OS on a resource-limited machine and they almost certainly thought about using bits as boolean flags.

Those are called bitfields and *are* part of the ANSI C standard.

Note also that the ANSI C standard leaves it up to the implementation whether a bitfield declared plain int is signed or not.
This in effect creates two alternative dialects of C.



>Peter
>-

2005\08\18@045128 by Wouter van Ooijen

face picon face
> Re: no support for bit access in C: wrong ?
>
> struct _packed_bits {
>                   unsigned int bit0:1;
>                   unsigned int bit1:1;
> } packed_bits;

Now try to get the address of bit0, or to pass it to a function.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\08\18@152157 by Peter

picon face

On Thu, 18 Aug 2005, Wouter van Ooijen wrote:

>> Re: no support for bit access in C: wrong ?
>>
>> struct _packed_bits {
>>                   unsigned int bit0:1;
>>                   unsigned int bit1:1;
>> } packed_bits;
>
> Now try to get the address of bit0, or to pass it to a function.

That is a pointer question ;-) You can pass only a pointer to modifiable
data as an argument to a function. Therefore the limitation is that in C
the *pointer* to the smallest entity is a pointer to an int (maybe to a
char). No ?

Peter

2005\08\18@154045 by Wouter van Ooijen

face picon face
> That is a pointer question ;-) You can pass only a pointer to
> modifiable
> data as an argument to a function. Therefore the limitation
> is that in C
> the *pointer* to the smallest entity is a pointer to an int
> (maybe to a
> char). No ?

Correct. So anythings smaller than a char is not a (full, real) dataype
in C.

Related: if you have a large number of boolean variables in your program
each will occupy 1 byte, not one bit. No big deal? Try programming on a
10F :) (Jal plug: Jal has real bit variables - they can be passed as
parameters, and they are occupy just one bit. I am not saying Jal is
better, but it proves that it is possible.)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2005\08\19@001710 by William Chops Westfield

face picon face
It occurs to me that the harvard architecture is not so much a
limitation as the lack of RAM space.  Other embedded systems
deal with similar issues (code in ROM, for instance) by simply
copying all the data to RAM during startup.  That would leave only
pointers to code as an issue, and they're less common...

BillW

2005\08\19@085459 by Gerhard Fiedler

picon face
Peter wrote:

>>> struct _packed_bits {
>>>                   unsigned int bit0:1;
>>>                   unsigned int bit1:1;
>>> } packed_bits;
>>
>> Now try to get the address of bit0, or to pass it to a function.
>
> That is a pointer question ;-) You can pass only a pointer to modifiable
> data as an argument to a function.

Bitfields /are/ modifiable data. It's just not possible to get the address
of a bitfield (whereas that works with other members of structs). In that
sense, bitfields are not fully integrated into the language.

> Therefore the limitation is that in C the *pointer* to the smallest
> entity is a pointer to an int (maybe to a char). No ?

It's a pointer to char (and the size of a C char is an implementation thing
-- it's not defined in the language, even though in most implementations it
is a byte). But there's no inherent reason why there couldn't be a type
"bit" with a pointer to it.

HiTech C (like many other "small processor C" implementations) has a type
"bit" -- it is a single bit, not surprisingly :) --, but no pointer to it.
I don't see a (language) reason why there couldn't be a pointer to a bit
type. They just would have to add some code to the compiler to properly
deal with this.

In terms of efficiency, it doesn't matter whether you use a
struct/bitfield, bitwise-or or the bit type to set a single bit -- all
three cases the result is a single bsf instruction.

BTW, it /is/ possible to create a substitute for a bit pointer, using a
struct that contains a pointer to a byte and a bit address, together with
some functions that then set/clear/test the bit identified by such a
pointer. You just can't use the standard C pointer (de)referencing
operators & and * (that would require C++'s operator overloading...)

Gerhard

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...