The Compiler options found in the project options , for arm embedded when you have Target selected as embedded and cpu family as arm and target processor as ARMV7M are not correct , it comes up with -OpARMV7M instead of -Cparmv7m

how can i change this ? is it stored in a XML file or where do i find this.

Kind Regards

Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140715/23f33020/attachment.html>

Justin Smyyth wrote

"Target selected as embedded"

Is there an "official" description what this is supposed to mean ?

Some years ago "embedded" in the Linux Kernel meant that the CPU does not feature a Memory management Unit.

Nowadays, ARM CPUs without MMU seem rather outdated, while a lot of the newly designed "embedded boxes" (e.g. NAS devices) in fact do uses ARM CPUs with MMU.

Hence IMHO the therm "embedded" to select a feature of an ARCH should be avoided.

-Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140716/98ab4896/attachment.html>

If you compile using trunk fpc I need to use -Cparmv7m

-Op is target cpu optimization

And -cp is for choice of instruction set.

The -Op seems wrong to be used in this case, project options are for defining the cpu type not if optimizations are needed.

The two are listed from ppcrossarm.exe -h

-Op<x> Set target cpu for optimizing, see fpc -i for possible values

-Cp<x> Select instruction set, see fpc -i for possible values

See what I mean, the -Op doesn't not make sense to be used from here, it should be -Cp

Ideally I want to place a check box to allow the user (me) to change it from using -Op to -Cp , both are valid commands coming from using -h on the compiler.

As for the arm based board , I am using a NXP LPC 1343 Risc Processor.

http://www.wvshare.com/product/Open1343-Standard.htm

that's the board in question

Kind Regards

Justin

The "official" FPC description: No OS, bare hardware. In case of ARM this also includes the possibility to load a controller file for certain boards we already support.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140716/ecd5a92d/attachment.html>

defining the cpu type not if optimizations are needed.

This was corrected yesterday in Lazarus.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140716/8ee6791d/attachment-0001.html>

Sven Barth wrote

> Is there an "official" description what this is supposed to mean ? The "official" FPC description: No OS, bare hardware.

(and that results in only a barebone RTL)

To me this wording seems just as misleading as the old-style Linux "noMMU" meaning, as nowadays many embedded systems do run a full blown OS (mostly Linux).

-Michael

Marco van de Voort wrote

(and that results in only a barebone RTL)

I do like the term "barebone" a lot more than "embedded" for this option :-)

-Michael

Thanks

I am updating lazarus on my vm now.

I am using trunk FPC 2.6.4 which has the mods for LPC 1343. ( embedded )

I've also made a custom version of GDBMiServerDebugger which adds support for connecting to EABI version of gdb using OpenOCD V8

Also another question , when I am targeting arm based arch , when I start up it complains it cant find classes.ppu - but the program compiles OK can this be supressed if a target is chosen that doesn't use it ?

Is there really no classes.ppu for your arm target?

Mattias

No Classes for Embedded ARM.

If I goto my source dir for Trunk FPC and do a search in RTL I can't find anything for classes.*

Note I am using trunk FPC and not fixes_2_6 ( or what ever the lastest version is) as trunk FPC only supports my lpc board, it doesn't work in fixes_2_6

Kind Regards

Justin

support

> for connecting to EABI version of gdb using OpenOCD V8 > > > Also another question , when I am targeting arm based arch , when I

start up

> it complains it cant find classes.ppu - but the program compiles OK can

this

> be supressed if a target is chosen that doesn't use it ? Is there really no classes.ppu for your arm target?

That's rather likely as Classes is simply too fat...

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140716/936f5504/attachment-0001.html>

[...] > Is there really no classes.ppu for your arm target? That's rather likely as Classes is simply too fat...

On targets with classes the fat makes it a good indicator if fpc was installed right.
For targets without Classes the test needs to be adapted. What targets do not have a classes.ppu?

Mattias

arm-embedded does not have classes.ppu, same with mipsel-embedded (but this target is not yet fully visible in trunk)

arm and mipsel do have definitions in fpc/rtl/embedded/rtl.cfg :

#ifdef CPUARM
-SfSOFTFPU
-SfCLASSES

#ifdef CPUMIPSEL
-SfSOFTFPU
-SfCLASSES

but even with those settings active classes does not get built:

ppcrossarm -MObjFPC -Scghi -al -Ch1024 -Cs1024 -Tembedded -Parm $DEBUG -vewnhix -l -Cparmv7m -O- -WpSTM32F100XC -XParm-none-eabi- -FD/usr/local/bin -a test.pas
Hint: Start of reading config file /etc/fpc.cfg
Hint: End of reading config file /etc/fpc.cfg
Free Pascal Compiler version 2.7.1 [2014/07/12] for arm Copyright (c) 1993-2014 by Florian Klaempfl and others Target OS: Embedded
Compiling test.pas
test.pas(3,3) Fatal: Can't find unit classes used by test Fatal: Compilation aborted

-----

program test;
uses
   classes;
begin
end.

A find . -name "classes*" only shows me classes.ppu for the 'big' platforms i build from trunk, x86_64-darwin and i386-darwin, nothing for arm-embedded and mipsel-embedded

Michael

All targets that don't have a classes.pp in their corresponding RTL directory (e.g. rtl/embedded, rtl/macos, rtl/atari, rtl/emx). Note: Unix platforms like Linux, AIX, the BSDs etc. use the classes.pp in the unix directory.

It's likely better to rely on the system.ppu... :/

Regards,
Sven

[...] It's likely better to rely on the system.ppu... :/

Some users installed fpc with system.ppu and no
classes.ppu. That's why the test was added years ago.

Mattias

How did they manage that?! O.o

Regards,
Sven

Windows units use "win", OS/2 and emx also share some files iirc, as do amiga and morphos.

Hmm... It might be that this was when Classes was not yet part of the RTL. This was changed some years back, so that unit should be available automatically now (except for selected targets). With the recent clean up of the RTL directory a few other units fall now under the category of "might be missing"...

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140717/cdfcb26a/attachment.html>

Whats required to change this behaviour ?

If you can point me in the right direction it would be of great help.

I?ve just gotta remember to switch from VB coding back to pascal I am so use to it , its not funny - I got a job doing VB programming here in Australia back in feb @ www.isis.co.uk

Kind Regards

Justin

Yes. Now that you say it I think too. The RTL is in some cases automatically found, while other units aren't.

That role has mostly been replaced by unit contnrs. If RTL is found and the other packages not, the error is usually for contnrs.