[fpc-devel] Embedded Strings on nRF51-DK
Paul Michell
Paul at michellcomputing.co.uk
Tue Apr 28 18:07:21 CEST 2015
Micheal
On Sunday 19 Apr 2015 17:24:35 Michael Ring wrote:
> I have created a patch for you that adds the interface-unit for the
> nrf51 chips.
I've adapted my build script to generate the cross compiler from your patch.
I've attached the actual script if you want to check that I've applied it
correctly. It installs a ppcrossarm and RTL objects into /usr/lib/fpc/3.1.1/.
When I run ppcrossarm -i I now get:
NRF51822_XXAA,NRF51822_XXAB,NRF51822_XXAC,NRF51422_XXAA,NRF51422_XXAB,NRF51422_XXAC,THUMB2_BARE
at the end of the supported microcontroller list. I have also found the new
nrf51.pp unit which I assume is generated from the CMSIS data you mentioned?
Now I can use this to build a valid Cortex M0 executable without needing to
use ld/make to perform the linking steps. I then use JLinkExe to perform the
actual flashing of the nRF51. So my test build script is now:
ppcrossarm -MObjFPC -Scghi -al -Ch1024 -Cs1024 -Tembedded -Parm -vewnhix -l -
Cparmv6m -O- -WpnRF51822_xxAC -XParm-none-eabi- -a test1.pas
JLinkExe test1.jlink
Which is MUCH tidier than the GCC make script! Test1 is the preverbial
simplest program:
Program test1;
Begin
writeln('Hello World!');
End.
This (as expected) does nothing as writeln is not re-targeted to the UART.
My next test was to write a FPC 'blinky' clone using the TGPIO_Registers
defined in your nrf51.pp unit (test2.pas attached). The main section of this
looks like:
Procedure GPIOTogglePin(PinNumber: LongWord); Inline;
Var
PinBit: LongWord;
Begin
PinBit := LongWord(1) ShL PinNumber;
If (GPIO.OUT And PinBit)=0 Then
GPIO.OUTSET := PinBit
Else
GPIO.OUTCLR := PinBit;
End;
Const
LED1 = 21;
Begin
GPIO.PIN_CNF21_bits.SENSE := 0;
GPIO.PIN_CNF21_bits.DRIVE := 0;
GPIO.PIN_CNF21_bits.PULL := 0;
GPIO.PIN_CNF21_bits.clearINPUT;
GPIO.PIN_CNF21_bits.setDIR;
While True Do
Begin
GPIOTogglePin(LED1);
MillisecondsDelay(1000);
End;
End.
I think this is still easier to read than the equivalent C, although it would
be nicer still to be able to use the pin number as an array index, something
like this:
GPIO.PinConfig[LED1].setDIR;
GPIO.Pin[LED1].Clear;
At this point I decided to split the code into 2 modules so that utilities
such as GPIOTogglePin and MillisecondsDelay were not defined in the main unit.
This gives test3.pas and nRF51Utils.pas. As expected, FPC implicitly built
and linked nRF51Utils. This is a great improvement over having to edit a
makefile every time I want to introduce a new unit!
Next I wanted to enable UART output so that I could do basic debugging.
Unfortunately the fun starts when I try to elaborate this!
In nrf51.h I notice the pin config array is defined as:
PIN_CNF[32];
But the TGPIO_Registers in nrf51.pp defines PIN_CNF0 to PIN_CNF32. Should
that be to PIN_CNF31?
> The CMSIS is a format created by ARM that (as one of it's features)
> describes all registers and fields of an arm chip in a language
> independant way.
>
>
>
> Please check out a fresh copy of fpc-trunk
>
> then apply this patch:
>
> http://temp.michael-ring.org/nrf51.diff
>
> and build the new compiler:
>
> make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm
> SUBARCH=armv6m CROSSOPT="-O2 -gw2" BINUTILSPREFIX=arm-none-eabi-
make buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv6m
CROSSOPT="-O2 -gw2" CROSSBINDIR=/usr/bin/ BINUTILSPREFIX=arm-none-eabi-
>
> install it:
>
> sudo make installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm
> SUBARCH=armv6m CROSSOPT="-O2 -gw2" BINUTILSPREFIX=arm-none-eabi-
sudo make installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm
SUBARCH=armv6m CROSSOPT="-O2 -gw2" BINUTILSPREFIX=arm-none-eabi- PREFIX=/usr
>
> You may need o change BINUTILSPREFIX=arm-none-eabi- when your binutils
> have a different name and sudo is not necessary on windows
>
> Now you have support for the nrf51 chips, ppcrossarm -i should give you:
>
> nRF51822_xxAA,nRF51822_xxAB,nRF51822_xxAC,nRF51422_xxAA,nRF51422_xxAB
> nRF51422_xxAC
>
> as new Microcontroller types.
>
> This unit will help you with raw access to all registers, I am not sure
> if Nordic Semiconductor also offers documentation on this level, so your
> mileage may vary.
>
> But you now have a basis to play arround with linking to the nrf51 libs
> and accessing the bluetooth stack provided by NC in the fpc way.
>
> This is a helpfull way to do the compile:
>
> ppcrossarm -MObjFPC -Scghi -al -Ch1024 -Cs1024 -Tembedded -Parm -vewnhix
> -l -Cparmv6m -O- -WpnRF51822_xxAC -XParm-none-eabi- -a hello.pas -sh
>
> everything is compiled, but not linked.
>
> you can then have a look at link.res, check that all necessary sections
> are included. When happy you can call ppas.sh to do the actual linking.
>
> I also have two nrf51 USB-thumb sticks please keep me posted on your
> success, I wanted to also do a small bluetooth project based on those
> modules. My plan was to do this in C (this is painful, but often the
> faster way) but I may switch to also try to do the project in fpc based
> on your results.....
>
>
> Michael
>
> Am 18.04.15 um 11:16 schrieb Paul Michell:
> > Michael
> >
> > Thanks for the offer of help. I'm totally new to embedded work. I am
> > aware of the FPC embedded compiler target, but I don't yet understand
> > the nRF51 SDK enough to set up the required files. I would like to move
> > to this approach and I have read:
> >
> > http://wiki.freepascal.org/TARGET_Embedded
> >
> > What I am unsure about is how this would work with the RF/Bluetooth
> > firmware of the nRF51. I have deliberately been staying as close to the
> > GCC method as possible so that I can use all of the SDK resources. But
> > if it is possible to use the target embedded approach that would be much
> > better.
> >
> > I don't know what the chip's CMSIS data is. I tried to google it and
> > there is some mention of a 'SDK CMSIS pack' here:
> >
> > http://developer.nordicsemi.com/
> >
> > Does this tell you what needs to be known? Would you need to produce a
> > different controller definition for each SoftDevice configuration?
> >
> > If you think this is worth attempting I would be happy to help set this
> > up.
> >
> > Kind regards,
> >
> > Paul
> >
> > On Friday 17 Apr 2015 08:44:55 Michael Ring wrote:
> >> I can generate the pascal unit for the nrf51 module from the CMSIS Data
> >> of this chip.
> >>
> >> Drop me a note if are you interested, this unit should make your life a
> >> lot easier.
> >
> > _______________________________________________
> > fpc-devel maillist - fpc-devel at lists.freepascal.org
> > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
> _______________________________________________
> fpc-devel maillist - fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BuildFPC.3.1.1.Cross.Arm.Embedded.sh
Type: application/x-shellscript
Size: 974 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20150428/83e7675a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.pas
Type: text/x-pascal
Size: 900 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20150428/83e7675a/attachment.pas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test3.pas
Type: text/x-pascal
Size: 323 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20150428/83e7675a/attachment-0001.pas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nRF51Utils.pas
Type: text/x-pascal
Size: 786 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20150428/83e7675a/attachment-0002.pas>
More information about the fpc-devel
mailing list