Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2018-09

ARM embedded for ATSAM

3 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Alfred

Hello,

Intro.

After a long period of using C for writing firmware for Microchip PIC24 and PIC32, I am now switching hardware and software. For future projects, I will use:
* the Atmel/Microchip ATSAM series; these are Cortex M-0/3/4 MPU.
* FPC for writing the firmware.
First tests show a successful use of FPC on ATSAMD14 and ATSAMD21 and ATSAMCx.

Sidenote.

As abstraction-layer, I use the pxl library.
See : https://asphyre.net/products/pxl
This library allows me to use apps, that access hardware, transparent on
nearly all platforms, including Ultibo.
Code using pxl will look like this:
const
   PinLED = 9;
var
   FGPIO : TCustomGPIO;
begin
   FGPIO := TMicroGPIO.Create; //<- for arm embedded on ATSAM.
   //FGPIO := TFastGPIO.Create; //<- for RPi running Linux.
   FGPIO.PinMode[PinLED] := TPinMode.Output;
   FGPIO.PinValue[PinLED] := TPinValue.High;
   FGPIO.Destroy;
end;

Question.

There are many different ATSAM processors. All with many different features and peripherals.
I would like to add (many of) them as embedded targets.

To prevent cluttering of directories, I propose to use small definition units, that use include and switches to make a (rough) differentiation between ATSAM-processors. The switches are used in the include-files to filter features.

************************************************
unit samd10c14;
{$define samd10c14}
interface
const
   FLASH_SIZE            = $4000; //* 16 kB */
   FLASH_PAGE_SIZE       = 64;
   FLASH_NB_OF_PAGES     = 256;
   FLASH_USER_PAGE_SIZE  = 64;
   HMCRAMC0_SIZE         = $1000; //* 4 kB */
{$i atmel/sam/sam-base.inc}
{$i atmel/sam/sam-irq.inc}
{$i atmel/sam/sam-ac.inc}
{$i atmel/sam/sam-adc.inc}
......
end;
************************************************
The {$define samd10c14} is used in the include-files to enable/disable
features.
This allows for a very efficient re-use of code.

Would the above be acceptable to be included in FPC trunk ? Or are there other (better) ways to add ATSAM embedded targets ?

Thanks for your advice.

Reply by email

Michael Ring
to Alfred

definitions for microcontrollers are available in the rtl/embedded/arm directory, there is one (sometimes several) pascal file for a class of microcontrollers of one vendor.

There is some light glue in the compiler/arm/cpuinfo.pas and systems/t_embed.pas directory to make a new microcontroller available.

What I do is to auto-generate the main microcontroller file from the header files of the microcontroller vendor.

On top of this you can then build your own library or extend pxl.

Michael

Alfred wrote 75 lines
Hello, Intro. After a long period of using C for writing firmware for Microchip PIC24 and PIC32, I am now switching hardware and software. For future projects, I will use: * the Atmel/Microchip ATSAM series; these are Cortex M-0/3/4 MPU. * FPC for writing the firmware. First tests show a successful use of FPC on ATSAMD14 and ATSAMD21 and ATSAMCx. Sidenote. As abstraction-layer, I use the pxl library. See : https://asphyre.net/products/pxl This library allows me to use apps, that access hardware, transparent on nearly all platforms, including Ultibo. Code using pxl will look like this: const   PinLED = 9; var   FGPIO : TCustomGPIO; begin   FGPIO := TMicroGPIO.Create; //<- for arm embedded on ATSAM.   //FGPIO := TFastGPIO.Create; //<- for RPi running Linux.   FGPIO.PinMode[PinLED] := TPinMode.Output;   FGPIO.PinValue[PinLED] := TPinValue.High;   FGPIO.Destroy; end; Question. There are many different ATSAM processors. All with many different features and peripherals. I would like to add (many of) them as embedded targets. To prevent cluttering of directories, I propose to use small definition units, that use include and switches to make a (rough) differentiation between ATSAM-processors. The switches are used in the include-files to filter features. ************************************************ unit samd10c14; {$define samd10c14} interface const   FLASH_SIZE            = $4000; //* 16 kB */   FLASH_PAGE_SIZE       = 64;   FLASH_NB_OF_PAGES     = 256;   FLASH_USER_PAGE_SIZE  = 64;   HMCRAMC0_SIZE         = $1000; //* 4 kB */ {$i atmel/sam/sam-base.inc} {$i atmel/sam/sam-irq.inc} {$i atmel/sam/sam-ac.inc} {$i atmel/sam/sam-adc.inc} ...... end; ************************************************ The {$define samd10c14} is used in the include-files to enable/disable features. This allows for a very efficient re-use of code. Would the above be acceptable to be included in FPC trunk ? Or are there other (better) ways to add ATSAM embedded targets ? Thanks for your advice. _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply by email

Alfred
to Michael Ring

Thanks for the advice.
The glue has already been used by me, including glue for the FPC-makefiles. And some glue for Lazarus.

My question was more meant to be a fundamental one about the organization of code.
Embedded is now a very viable target for FPC.
MCU's become powerful enough to be easily used for FPC ( and OOP ). This would mean more targets and a much wider public.

The more targets added, the better.
But it could/should be better organized.
Making adding targets more easy. And strong typing (for peripherals) possible.

------ Origineel bericht ------
Van: "Michael Ring"
Aan:
Verzonden: 7-9-2018 13:39:09
Onderwerp: Re: [fpc-devel] ARM embedded for ATSAM

Show quoted text 16 lines
definitions for microcontrollers are available in the rtl/embedded/arm directory, there is one (sometimes several) pascal file for a class of microcontrollers of one vendor. There is some light glue in the compiler/arm/cpuinfo.pas and systems/t_embed.pas directory to make a new microcontroller available. What I do is to auto-generate the main microcontroller file from the header files of the microcontroller vendor. On top of this you can then build your own library or extend pxl. Michael

Reply by email