Re: [fpc-devel] strcopy, strlcopy for PWideChar
In our previous episode, Felipe Monteiro de Carvalho said: drdiettri...@aol.com wrote: The mix (or equivalence) of character and byte counts obviously is inappropriate for wide versions. Perhaps sizeof should read Length? Maybe Delphi supports only UCS-2 and not UTF-16 Delphi afaik supports UTF-16 as a stringtype (afaik all routines route to system routines that keep track of surrogates), but only provides 2-byte array level access for [] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stellaris Update
On 16 Aug 2011, at 04:39, John Clymer wrote:
So, after some work, I have a compiler working for the LM3S8962 board (a
successful Blinking LED :-) )
However, as I was going through some of the various datasheets, I see that
all the Stellaris controllers have similar memory maps. That is:
A) Each type of device has a specific spot in the memory map to sit at.
B) If a device has less or no device of a given type, that memory map is
Reserved
C) The SRAM and FLASH memories always start at the same address
As such, I'm leaning towards:
{$FLASH_START x}
{$FLASH_SIZE x }
{$SRAM_START x }
{$SRAM_SIZE x }
By doing this, only 1 config will work for all stellaris parts (as was
originally laid out in the cpuinfo file.)
I'm also looking to do a survey of all STM32 devices to see if a similar
situation exists. I think, for all Cortex M3 devices of a particular
manufacturer, a similar scheme can be used. The M3 specs make requirements
that limit the flexibility to come up with oddball memory layouts.
It is clear from the ARM cortex m3 tech ref manual that all derivatives (all
manufacturers) have internal code starting at $ and ram starting at
$2000, so only two parameters are required for all possible cortex m3
parts, written either as ram top, flash top, or ram size, flash size.
Geoffrey
John Clymer
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stellaris Update
Am 16.08.2011 05:39, schrieb John Clymer:
So, after some work, I have a compiler working for the LM3S8962 board (a
successful Blinking LED :-) )
However, as I was going through some of the various datasheets, I see
that all the Stellaris controllers have similar memory maps. That is:
A) Each type of device has a specific spot in the memory map to sit at.
B) If a device has less or no device of a given type, that memory map is
Reserved
C) The SRAM and FLASH memories always start at the same address
So why would the directives be needed?
As such, I'm leaning towards:
{$FLASH_START x}
{$FLASH_SIZE x }
{$SRAM_START x }
{$SRAM_SIZE x }
By doing this, only 1 config will work for all stellaris parts (as was
originally laid out in the cpuinfo file.)
What config? Memory layout in the compiler? Even without the directives
mentioned above, mulitple stellaris controllers can share the same
memory layout config in t_embedded?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] strcopy, strlcopy for PWideChar
Am 16.08.2011 07:06, schrieb LacaK: Hans-Peter Diettrich wrote / napísal(a): LacaK schrieb: Or do you not like these wide versions at all ? It's not a matter of liking, I'm afraid. If Delphi has them, we'll have to add them too :-) Can you please add an entry in the bug tracker, so we don't forget ? http://bugs.freepascal.org/view.php?id=19989 Do you think, that it is realistic expect them in 1-2 months ? Supply an patch, to speed up the implementation. Ok, I can try prepare patch, but only generic i.e. which uses only Pascal. It's the prefered way anyways. First, make a good pascal version, if someone needs it, he can look into creating an assembler one for some cpus. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] Including Sorokin's TRegExpr in FPC
On Tue, Aug 2, 2011 at 11:08 AM, Michael Van Canneyt mich...@freepascal.org wrote: If Florian agrees (if I'm correct, he wrote the old unit), we can move the old regexpr to oldregexpr, and move this one into its place. So, Florian, what do you think? thanks, -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] strcopy, strlcopy for PWideChar
Felipe Monteiro de Carvalho schrieb: On Mon, Aug 15, 2011 at 6:41 PM, Hans-Peter Diettrich drdiettri...@aol.com wrote: The mix (or equivalence) of character and byte counts obviously is inappropriate for wide versions. Perhaps sizeof should read Length? Maybe Delphi supports only UCS-2 and not UTF-16 String encodings should not play a role, when e.g. memory has to be allocated or copied (see SetLength). The MaxLen parameter indicates the number of physical units (bytes or words). DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stellaris Update
One of my current fixes i have in place allows using the PPCCROSSARM compiler
to compile Pascal to Assembly. Once in Assembly, the files can be assembled
and
linked like any other program. So, you have the capability to do just about an
exotic configuration you want - you just have to do so via assembly rather than
straight to object code. (If I've missed a way to go directly to an object file
from a pascal file - I'd be very happy - I didn't see any command line switches
to compile and generate .o files.)
To accommodate the compile to assembly option was only a 2 line change to
t_embed.pas.
However, I also agree with the sentiment that the compiler should be
downloadable and able to produce a binary for people not accustomed to command
lines, makefiles, etc. To that end, and to 90% of most conceivable cases, the
{$FLASH_START}, etc [with some sane defaults] mechanism provides enough power
to
accommodate most of the compilers potential users.
John
From: DaWorm daw...@gmail.com
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, August 16, 2011 8:49:51 AM
Subject: Re: [fpc-devel] Stellaris Update
STM32F103 and other ST Micro M3 parts have the ability to remap the vector
table. You can create applications to start anywhere in memory, and use a
bootloader to remap the table and jump to the new power up vector. In IAR C
this is handled in the linker config file. Someone on the list thought it
better not to go that route. However it is done, it should be done at an
individual application level, not tied to the part.___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stellaris Update
Stellaris ALWAYS has the Code starting at $:.
STM32's do something odd where the FLASH starts at $0800:, and the memory
between $: and $07FF: is mappable to either the FLASH or the
built-in boot loader. (Which throws a kink in the works.)
But, as far as the point of catching the 90% of possible uses - one could drop
down to strictly {$FLASH_SIZE} and {$SRAM_SIZE}.
The other option (unless one wants a gazzillion items on the case() statements
in t_embed.pas) - is to set them extremely large so they don't get exceeded.
However, the danger in that is if someone has an 8K part, and the program ends
up spilling over 8K - it won't get picked up.
Also started un-commenting some parts of rtl.cfg in the embedded folder. Is
there any desire to support more of the RTL than the minimum (i.e. have a
default stdin and stdout - so WriteLn, etc work via the serial port ?) Or is
the intent that embedded includes on the bare minimal RTL to bring the machine
up ?
Thanks,
John
From: Florian Klämpfl flor...@freepascal.org
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, August 16, 2011 12:35:03 PM
Subject: Re: [fpc-devel] Stellaris Update
Am 16.08.2011 05:39, schrieb John Clymer:
So, after some work, I have a compiler working for the LM3S8962 board (a
successful Blinking LED :-) )
However, as I was going through some of the various datasheets, I see
that all the Stellaris controllers have similar memory maps. That is:
A) Each type of device has a specific spot in the memory map to sit at.
B) If a device has less or no device of a given type, that memory map is
Reserved
C) The SRAM and FLASH memories always start at the same address
So why would the directives be needed?
As such, I'm leaning towards:
{$FLASH_START x}
{$FLASH_SIZE x }
{$SRAM_START x }
{$SRAM_SIZE x }
By doing this, only 1 config will work for all stellaris parts (as was
originally laid out in the cpuinfo file.)
What config? Memory layout in the compiler? Even without the directives
mentioned above, mulitple stellaris controllers can share the same
memory layout config in t_embedded?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stellaris Update
Sorry, missed the second set of questions
I was able to get the stellaris part setup in t_embed.pas and cpuinfo.pas, then
I got build errors when I build an executable - it was missing the Controller's
startup file - these are in rtl\embedded\arm. Once FPC finishes compiling the
program, it wants to link with a unit with the same name as the Controller.
So,
if each controller gets supported separately, then that folder is going to be
chock full of controller specific startup files - most of which will be
duplicates inside the same family.
Unless I'm missing something, in order to get a binary for the LM3S8962, using
that specific controller as the target, I had to have a file in that folder
with
that same name - and with the unit inside named the same as the microcontroller.
John
From: Florian Klämpfl flor...@freepascal.org
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, August 16, 2011 12:35:03 PM
Subject: Re: [fpc-devel] Stellaris Update
Am 16.08.2011 05:39, schrieb John Clymer:
So, after some work, I have a compiler working for the LM3S8962 board (a
successful Blinking LED :-) )
However, as I was going through some of the various datasheets, I see
that all the Stellaris controllers have similar memory maps. That is:
A) Each type of device has a specific spot in the memory map to sit at.
B) If a device has less or no device of a given type, that memory map is
Reserved
C) The SRAM and FLASH memories always start at the same address
So why would the directives be needed?
As such, I'm leaning towards:
{$FLASH_START x}
{$FLASH_SIZE x }
{$SRAM_START x }
{$SRAM_SIZE x }
By doing this, only 1 config will work for all stellaris parts (as was
originally laid out in the cpuinfo file.)
What config? Memory layout in the compiler? Even without the directives
mentioned above, mulitple stellaris controllers can share the same
memory layout config in t_embedded?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stellaris Update
On 16 Aug 2011, at 11:16, John Clymer wrote:
Stellaris ALWAYS has the Code starting at $:.
STM32's do something odd where the FLASH starts at $0800:, and the memory
between $: and $07FF: is mappable to either the FLASH or the
built-in boot loader. (Which throws a kink in the works.)
But, as far as the point of catching the 90% of possible uses - one could
drop down to strictly {$FLASH_SIZE} and {$SRAM_SIZE}.
The other option (unless one wants a gazzillion items on the case()
statements in t_embed.pas) - is to set them extremely large so they don't get
exceeded. However, the danger in that is if someone has an 8K part, and the
program ends up spilling over 8K - it won't get picked up.
Also started un-commenting some parts of rtl.cfg in the embedded folder. Is
there any desire to support more of the RTL than the minimum (i.e. have a
default stdin and stdout - so WriteLn, etc work via the serial port ?) Or is
the intent that embedded includes on the bare minimal RTL to bring the
machine up ?
In my case I was trying for the bare minimum, particularly as some of the
Stellaris parts have masked ROM ('Stellarisware') containing useful drivers for
various functions including USB and ethernet and these are easily called from
FPC. This saves flash code space.
Geoffrey
Thanks,
John
From: Florian Klämpfl flor...@freepascal.org
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, August 16, 2011 12:35:03 PM
Subject: Re: [fpc-devel] Stellaris Update
Am 16.08.2011 05:39, schrieb John Clymer:
So, after some work, I have a compiler working for the LM3S8962 board (a
successful Blinking LED :-) )
However, as I was going through some of the various datasheets, I see
that all the Stellaris controllers have similar memory maps. That is:
A) Each type of device has a specific spot in the memory map to sit at.
B) If a device has less or no device of a given type, that memory map is
Reserved
C) The SRAM and FLASH memories always start at the same address
So why would the directives be needed?
As such, I'm leaning towards:
{$FLASH_START x}
{$FLASH_SIZE x }
{$SRAM_START x }
{$SRAM_SIZE x }
By doing this, only 1 config will work for all stellaris parts (as was
originally laid out in the cpuinfo file.)
What config? Memory layout in the compiler? Even without the directives
mentioned above, mulitple stellaris controllers can share the same
memory layout config in t_embedded?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stellaris Update
Am 16.08.2011 12:24, schrieb John Clymer: Sorry, missed the second set of questions I was able to get the stellaris part setup in t_embed.pas and cpuinfo.pas, then I got build errors when I build an executable - it was missing the Controller's startup file - these are in rtl\embedded\arm. Once FPC finishes compiling the program, it wants to link with a unit with the same name as the Controller. So, if each controller gets supported separately, then that folder is going to be chock full of controller specific startup files - most of which will be duplicates inside the same family. This files are needed anyways to provide the declartions for hardware access. Common declarations/startup code can be easily placed in commonly used include files, and, see below. Unless I'm missing something, in order to get a binary for the LM3S8962, using that specific controller as the target, I had to have a file in that folder with that same name - and with the unit inside named the same as the microcontroller. This could be changed in the compiler, this is why we have controllerunitstr and it proved to work well for me when working with LPCs. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stellaris Update
Am 16.08.2011 12:16, schrieb John Clymer:
Stellaris ALWAYS has the Code starting at $:.
STM32's do something odd where the FLASH starts at $0800:, and the
memory between $: and $07FF: is mappable to either the FLASH
or the built-in boot loader. (Which throws a kink in the works.)
But, as far as the point of catching the 90% of possible uses - one
could drop down to strictly {$FLASH_SIZE} and {$SRAM_SIZE}.
The other option (unless one wants a gazzillion items on the case()
statements in t_embed.pas) - is to set them extremely large so they
don't get exceeded. However, the danger in that is if someone has an 8K
part, and the program ends up spilling over 8K - it won't get picked up.
Also started un-commenting some parts of rtl.cfg in the embedded
folder. Is there any desire to support more of the RTL than the minimum
(i.e. have a default stdin and stdout - so WriteLn, etc work via the
serial port ?) Or is the intent that embedded includes on the bare
minimal RTL to bring the machine up ?
The idea is to have a minimum default. Users needing more can uncomment
the needed parts and recompile the rtl.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stellaris Update
Am 16.08.2011 12:16, schrieb John Clymer:
Stellaris ALWAYS has the Code starting at $:.
STM32's do something odd where the FLASH starts at $0800:, and the
memory between $: and $07FF: is mappable to either the FLASH
or the built-in boot loader. (Which throws a kink in the works.)
But, as far as the point of catching the 90% of possible uses - one
could drop down to strictly {$FLASH_SIZE} and {$SRAM_SIZE}.
The other option (unless one wants a gazzillion items on the case()
statements in t_embed.pas)
Better than some wrecked programs because somebody put a wrong
FLASH_SIZE/SRAM_SIZE somewhere. Pascal tries to prevent the user to
shoot himself into the foot. *_SIZE /*_START is a good possibility to
shoot oneself into the foot while if it is once put into the compiler,
it just works.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] Including Sorokin's TRegExpr in FPC
Am 16.08.2011 10:53, schrieb Felipe Monteiro de Carvalho: On Tue, Aug 2, 2011 at 11:08 AM, Michael Van Canneyt mich...@freepascal.org wrote: If Florian agrees (if I'm correct, he wrote the old unit), we can move the old regexpr to oldregexpr, and move this one into its place. So, Florian, what do you think? I think mine is already replaced by something written by Joost? I talked with Benjamin about including his regexpr engine as well and to me it looks very good. Maybe we can just offer multiple ones. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] Including Sorokin's TRegExpr in FPC
On Tue, 16 Aug 2011, Florian Klämpfl wrote: Am 16.08.2011 10:53, schrieb Felipe Monteiro de Carvalho: On Tue, Aug 2, 2011 at 11:08 AM, Michael Van Canneyt mich...@freepascal.org wrote: If Florian agrees (if I'm correct, he wrote the old unit), we can move the old regexpr to oldregexpr, and move this one into its place. So, Florian, what do you think? I think mine is already replaced by something written by Joost? I talked with Benjamin about including his regexpr engine as well and to me it looks very good. Maybe we can just offer multiple ones. I think that would be best. Maybe some speed comparisions can be done. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpvectorial xml docs
Hello, I added xml docs for fpvectorial (fpdocs/fpvectorial.xml). It would be excellent if someone added it to the standard fcl help build. I searched a little, but I couldn't find how to do it. I see that one can add it to the makefile, but I'm not sure what is really needed to add it to the toplevel fcl html page. thanks, -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
Am 15.08.2011 10:52, schrieb Michael Schnell: On 08/15/2011 12:39 AM, Graeme Geldenhuys wrote: On 14 August 2011 20:21, Sven Barth wrote: Just curious: Do you still plan to port it to Pascal? Definitely! Hmm, in the end giving us the choice between LCL/VCL, Firemonkey, fpGUI designer, and MiGLayout (and...). Maybe too many alternatives What is the main difference between the fpGUI designer and MiGLayout ? If I understand that correctly, than MiGLayout is just a layout manager and can be used above any GUI widgetset. So if we've had a Pascal implementation of it, we could use it for LCL/VCL, Firemonkey, fpGUI any every other possible widgetset set. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stellaris Update
I was missing something then ! Thanks. (It's usually the obvious things - staring me right in the face - that I miss) Given that one controller unit file can be re-used amongst multiple controllers, that leaves a giant case() statement - which I can live with. And, there is a 2 line patch to allow the compiler to compile to assembly - then use binutils to assemble and patch. This gives the flexibility to accommodate non-standard setups. Expecting to provide a patch set in about a week to include a huge number of stellaris parts support. John From: Florian Klämpfl flor...@freepascal.org To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Tue, August 16, 2011 2:46:06 PM Subject: Re: [fpc-devel] Stellaris Update Am 16.08.2011 12:24, schrieb John Clymer: Sorry, missed the second set of questions I was able to get the stellaris part setup in t_embed.pas and cpuinfo.pas, then I got build errors when I build an executable - it was missing the Controller's startup file - these are in rtl\embedded\arm. Once FPC finishes compiling the program, it wants to link with a unit with the same name as the Controller. So, if each controller gets supported separately, then that folder is going to be chock full of controller specific startup files - most of which will be duplicates inside the same family. This files are needed anyways to provide the declartions for hardware access. Common declarations/startup code can be easily placed in commonly used include files, and, see below. Unless I'm missing something, in order to get a binary for the LM3S8962, using that specific controller as the target, I had to have a file in that folder with that same name - and with the unit inside named the same as the microcontroller. This could be changed in the compiler, this is why we have controllerunitstr and it proved to work well for me when working with LPCs. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
