Hello everybody,

I'm new on the list. I have been using lazarus/fpc in huge projects for my company and for my own private ventures. FPC is a fantastic project and our true answer to Borland that has failed developers like me in a big way.

I'm joining the list with my recent read of the work being done in FPC for embedded micro controllers.

Most of my work was PC/server based but I always wished for a good pascal compiler to experiment with some micro controllers as well. I have seen the mikro pascal product for Atmel chips, but it did not keep my interest. Of course I immediately sat up straight when I heard FPC - which is my favourite language and compiler - doing some development work for mcu's.

I can not wait for futher developments. The excitement is much.

This is my first question / suggestion: With byte sized variables being the smallest accessible variable in the PC architecture, will we see a language extension to provide bit accessible variables for the micro controllers?

Thank you. Please continue the good work.

Op Wed, 29 Jul 2009, schreef Desmond Coertzen:

This is my first question / suggestion: With byte sized variables being the smallest accessible variable in the PC architecture, will we see a language extension to provide bit accessible variables for the micro controllers?

Do you mean bitpacking?

type  nibbles=bitpacked record
         low_nibble=0..15;
         high_nibble=0..15;
       end;

Daniël

That is fantastic!

Is this correct for application?

var
  SomeIOPort: nibbles;
begin
  SomeIOPort.low[7] := 1;
end;

On Wed, Jul 29, 2009 at 4:47 PM, Daniël Mantione <

This is not usable for accessing particular bits of microcontroller registers, because the internal format of a bitpacked record is undefined and can change at any time for any reason.

Jonas

Op Wed, 29 Jul 2009, schreef Desmond Coertzen:

nibbles is not an array?

Anyway, you can created bitpacked arrays, so the idea will work.

Daniël

Indeed, but do you think we should create a new syntax to map C bitpacked structures? Anyways, I'am using bitpacked arrays and records already in my embedded stuff

That is possible, but hard:
a) the alignment of bitpacked C records is defined in the ABI, and there are quite a few differences between different ABIs b) in C, you can have "char a:1;" and "int a:1;" and these will be aligned differently (although both are 1 bit). You'd have to invent some Pascal syntax to match that.

Anyways, I'am using bitpacked arrays and records already in my embedded stuff

Just don't come complaining when it breaks :)

Jonas

But if I define the 'nibble' data types myself (or use the bit packed data types provided by a 'system' unit for the particular chip), they would stay that way?

Did I understand correct of how to use a bit packed structure in code?

In my original question I wondered if FPC would provide a bit data type in the future of MCU compiler development. Smaller chips are bit accessible. If I may explain by example of hypotheses and use a code example:

It would be nice to see:

type
  TPortAStruct = bitpacked record
    Low = 0..7;
    High = 8..15;
  end;
var
  PortA : ^TPortAStruct;
  MyLatch : ^Bit; //the future bit data type being 1 bit wide
  MyRedLED : ^Bit;
//and now to use
begin
  //set up the adresses
  PortA := $0A01; //the supposed address for port A on this chip
  MyLatch := PortA.Low[3]; //the hypotheses: MyLatch is on PortA, low byte,
bit 3
  MyRedLED := PortA.High[0]; //My red LED is on PortB, high byte, bit 0
  //now only use the bits in the registers
  MyLatch^ := True;
  MyRedLED^ := True;
  //now use the whole register
  PortA^ := 0;
end.

The problem is that you have no guarantee how the compiler packs the bits inside your nibble data type. E.g., the bits may be ordered little or big endian (note that this about bit-endianess, not byte endianess; although the used bit-edianess may also differ depending on whether you are on a little/big byte-endian system -- which it already does, currently).

Jonas

Desmond Coertzen wrote

Is this correct for application?

While I know that you in fact can use bitpacked records to access singe bits in the memory, I wonder what kind of OS you want to use in this application.
Usually the OS prevents accessing I/O in a userland application (but there are things like mmap'ing I/O space to userland by a driver or using "uio".

-Michael

Jonas Maebe wrote

This is not usable for accessing particular bits of microcontroller registers, because the internal format of a bitpacked record is undefined and can change at any time for any reason.

Is this likely to happen ? AFAIK, in C the "struct ...:n" layout also is implementation depending and the memory layout in fact is not identical between high-endian and low-endian processors.

This _does_ offer problems when transferring such structures via Network or files.

-Michael

Florian Klaempfl wrote

Indeed, but do you think we should create a new syntax to map C bitpacked structures?

Would it not suffice just to provide a documentation on the layout of bitpacked arrays and records, which supposedly will be different for low and high endian processors, but otherwise don't need to change.

-Michael

That's irrelevant, unless you like writing programs of which it is documented that they may break with any new compiler release.

Even stronger: they are completely unsuited for that purpose. Just like Pascal set types, for that matter (for exactly the same reason).

Jonas

Michael Schnell wrote

Would it not suffice just to provide a documentation on the layout of bitpacked arrays and records, which supposedly will be different for low and high endian processors, but otherwise don't need to change.

It is impossible to predict whether they need not be changed for any current or future processor or toolchain. If you really want something with a fixed layout, then a new concept has to be introduced in which you can precisely specify this layout in a way that is endian-agnostic (rather than just declaring types and hoping that the compiler will forever lay them out the way you need them).

Bitpacked arrays and records are not intended nor suited for that purpose.

Jonas

Microcontrollers most of the time don't have any OS on them.

Jonas

No use for OS, just for smaller MCU's that are bit accessible.

By application I meant: Is this the correct method to apply a bit-packed structure to code?

I'm referring specifically to the MCU extensions to FPC (much appreciated extensions) that are under development at present listed on fpc wiki

Jonas Maebe wrote

a new concept has to be introduced in which you can precisely specify this layout in a way that is endian-agnostic

C does not offer endian-agnostic layout either, so endian-awareness is "standard" :).

An endian-agnostic implementation supposedly would perform quite poor.

-Michael

Jonas Maebe wrote

Even stronger: they are completely unsuited for that purpose.

True, but often not adhered to :(

I once had to write a program against a network protocol that was documented using using these C bitfield struct. And they did not state that they did this with a small-endian processor in mind. And I needed to write the program for a big-endian processor.

Real fun ;)

-Michael

Jonas Maebe wrote

Microcontrollers most of the time don't have any OS on them.

Of course. I daily work on such projects.

What I meant was: I suppose FP applications mostly is used on some kind of OS.

-Michael

Michael Schnell wrote

What I meant was: I suppose FP applications mostly is used on some kind of OS.

Not when targeting microcontrollers.

Jonas

Jonas Maebe wrote

Not when targeting microcontrollers.

What kind of Microcontrollers do you know that are used with FP programs ?

-Michael

http://wiki.freepascal.org/Embedded

Jonas

In our previous episode, Desmond Coertzen said:

No use for OS, just for smaller MCU's that are bit accessible. By application I meant: Is this the correct method to apply a bit-packed structure to code?

Note that there are two kinds of bitaccessibility.

E.g. microchip follows more the bitpacked way, where all SFR are overlayed (ABSOLUTE in FPC) with a bitpacked union in the header.

In addition some mcu's like IIRC 8051 (*) allows to access ANY integer/byte value to be accessed using .<bitnr> suffix. So if b is of type byte, b.7 returns the 7th bit. It also had a special type bit to store these and do some limited arithmetic on them. Probably mapping directly on some bit sized registers/flags and instructions.

(*) iirc we had some Hitachi clone 80515 or so. The compiler was the fairly
wellknown Keile one.

Thanks to everybody for their comment.

My own comment is mere suggestion.

As x86 developer, i'm used to manipulating bits with byte-wise or/and/not/shr/shl operators. (very tricky when doing PDU packing for 7 bit words into 8 bit words for some GSM coding schemes)

As far as endian is concerned: Integer types i found always to be little endian in most pascal compilers by default. To do big endian (network byte order) transport for some protocols or file formats, i used the htonl and htons lib functions on the integer fields. I wrote htonl_64 myself for 8 byte width integers.

As far as the FPC compiler is concerned, this should not be a concern as it seems the decisions regarding the byte order was made and cemented in place long ago. But now that you guys mention byte order, are there directives in FPC where integer byte orders can be changed?

If language syntax might be extended to provide bit width accessibility for MCU's, i think the same methods must be followed throughout FPC: In all technical specifications I have come accross, bit 0 is always the least significant bit of any word regardless the size of the word. That makes things simple.

As for the way the syntax will work, I can only suggest sticking with pascal as close as possible. It's a fantastic language.

Desmond Coertzen wrote

As far as endian is concerned: Integer types i found always to be little endian in most pascal compilers by default.

It's big endian on big endian architectures.

No, it's always the native byte order of the underlying architecture.

At least in the PowerPC documentation (both from Motorola and IBM), bit 0 is always the most significant bit.

Jonas

It's big endian on big endian architectures.

Which arhictecture(s) does big endian?

Desmond Coertzen wrote

> It's big endian on big endian architectures. Which arhictecture(s) does big endian?

Of the ones that FPC currently supports: SPARC, PowerPC/PowerPC64 (some implementations can also be used in little endian mode, but that's not often done in practice), ARM (but it's more often used in little endian mode nowadays).

Jonas