Also, just peeked at current line up of STM32 controllers, there are 150
different controllers available, consisting of 33 possible combinations of
FLASH
memory and SRAM size.
I will try to get the controller specific parts boiled up into record
structures
this weekend, and get some added
Sorry, figured it out -Cpcortexm3
On 08/19/2011 11:05 PM, David Welch wrote:
Actually I would prefer thumb first then thumb2 cpuinfo.pas does not
have an architecture tied to thumb but the cortexm3 and armv7m can be
easily moved to thumb temporarily or create say a cpu_cortexm3_thumb in
the tc
Actually I would prefer thumb first then thumb2 cpuinfo.pas does not
have an architecture tied to thumb but the cortexm3 and armv7m can be
easily moved to thumb temporarily or create say a cpu_cortexm3_thumb in
the tcputype list, etc...
David
On 08/19/2011 11:00 PM, David Welch wrote:
So
Someone pointed me at this page:
http://wiki.freepascal.org/TARGET_Embedded
And I started adding a device (and perhaps more after that), starting
with a cortex-m3 though which is thumb/thumb2 only.
Following the instructions on the page work fine:
fpc -Parm -Tembedded -Wplpc2124 tled1.pp
A
tags 636802 +patch
thanks
Note: jonas's reply was only posted to fpc-devel, not to the debian bug
report , a copy can be found at
http://lists.freepascal.org/lists/fpc-devel/2011-August/025444.html
Jonas Maebe wrote:
Is there a standard for multiarch library path locations and names?
Multi
On 08/19/2011 02:15 PM, David W Noon wrote:
I might do some experiments in C# to see if the thread manager creates
threads with process scope or system scope, as it might be a bit
smarter than Java's "green threads".
I remember that there once was a version of the PThreadLib that used an
interna
On 08/19/2011 02:15 PM, David W Noon wrote:
Threads are not tied to processors.
I do know that in Linux the scheduler tries to keep a thread in a core
if possible (even after re-scheduling the thread after preemption). This
greatly increases cache performance.
This is especially true in
"manag
On 08/19/2011 02:15 PM, David W Noon wrote:
My experience with OpenMP is that it is difficult to write a loop body
large enough that context switching does not overwhelm the benefits of
parallelism.
Hmmm.
If you do a multiplication of a 100*100 Matrix you could spawn 1
threads and this wi
On 08/19/2011 02:15 PM, David W Noon wrote:
That is not my experience. While CIL byte code interprets much faster
than Java byte code, it is still discernibly slower than native object
code.
Hmm. I don't have any personal experience with this, but from what I
read, this idea with CIL is to spli
On 19 Aug 2011, at 14:15, David W Noon wrote:
I might do some experiments in C# to see if the thread manager creates
threads with process scope or system scope, as it might be a bit
smarter than Java's "green threads".
According to wikipedia, Java stopped using the green threads model
after
On Fri, 19 Aug 2011 12:30:43 +0200, Michael Schnell wrote about Re:
[fpc-devel] C++ gets language-internal concurrency support:
>On 08/17/2011 06:49 PM, David W Noon wrote:
>> Perhaps the slower execution speed of CIL (.NET,
>> Mono) byte code masks the context switching overheads and makes this
>
On Aug 19, 2011 7:13 AM, "Geoffrey Barton" wrote:
>
> > Afaik there is a standard for the Cortex platform how to do it, google
> > for "ARM Cortex Microcontroller Software Interface Standard"
>
> there is a generic doc on the arm.com site and a stellaris specific one on
the TI site.
Following th
On 19 Aug 2011, at 11:11, Florian Klämpfl wrote:
> Am 19.08.2011 12:02, schrieb John Clymer:
>> So, consensus is to include the register definitions - then I will work
>> on these. To get all the possible register structures for all possible
>> peripherals will take some time. And naming conven
Hi,
I found this it fpc-pascal mailing list archive (I do not read this mailing
list, so I do not catch this discussion)
Because I think it is worth to continue, I move it into fpc-devel
/ ... I feel the definition
/>/ of SetFieldData/GetFieldData without a length/size parameter
/>/ and string
On 08/17/2011 11:57 PM, Graeme Geldenhuys wrote:
Why define a UI with co-ordinates, then sit with problems like
overlapping components, components that don't scale, locked to a
specific DPI etc.
This is similar to HTML vs PDF.
PDF always looks the same _if_ it can be displayed at all.
HTML (ho
On 08/17/2011 06:03 PM, David W Noon wrote:
I am (reasonably so, at least).
Where is the parallel aspect?
As I said I just did a quick search in the FAQ.
Does C++11 also provide a more "automatic" parallel processing feature
than just something similar to worker threads (Object Pascal TThre
On 08/17/2011 06:49 PM, David W Noon wrote:
Perhaps the slower execution speed of CIL (.NET,
Mono) byte code masks the context switching overheads and makes this
practice look less inefficient.
I doubt that this is the case. AFAIK, CIL code is not necessarily much
slower than native code. (Of
Am 19.08.2011 12:02, schrieb John Clymer:
> So, consensus is to include the register definitions - then I will work
> on these. To get all the possible register structures for all possible
> peripherals will take some time. And naming conventions come into play
> as well.
>
> I prefer having my
So, consensus is to include the register definitions - then I will work on
these. To get all the possible register structures for all possible
peripherals
will take some time. And naming conventions come into play as well.
I prefer having my device registers defined in structures. Other peop
On 19 Aug 2011, at 10:10, Florian Klämpfl wrote:
> Am 19.08.2011 11:07, schrieb Geoffrey Barton:
>>
>> On 19 Aug 2011, at 09:55, Florian Klämpfl wrote:
>>
>>> Am 19.08.2011 10:33, schrieb Geoffrey Barton:
because one is forever re-compiling the compiler when one
switches to a de
Am 19.08.2011 11:07, schrieb Geoffrey Barton:
>
> On 19 Aug 2011, at 09:55, Florian Klämpfl wrote:
>
>> Am 19.08.2011 10:33, schrieb Geoffrey Barton:
>>>
>>> because one is forever re-compiling the compiler when one
>>> switches to a device with a new peripheral, and if your main
>>> activity is
On 19 Aug 2011, at 09:55, Florian Klämpfl wrote:
> Am 19.08.2011 10:33, schrieb Geoffrey Barton:
>>
>> because one is forever re-compiling the compiler when one switches to
>> a device with a new peripheral, and if your main activity is not
>> compiler development but product development one has
Am 19.08.2011 10:33, schrieb Geoffrey Barton:
>
> because one is forever re-compiling the compiler when one switches to
> a device with a new peripheral, and if your main activity is not
> compiler development but product development one has to go back and
> find out how to do it each time. Better
On 19 Aug 2011, at 09:19, Florian Klämpfl wrote:
> Am 19.08.2011 05:28, schrieb John Clymer:
>> Currently, everything is in a handful of giant arrays. Just wondering
>> if it would be better to switch to a record structure for the controller
>> entries - rather than individual arrays. (Add in a
Am 19.08.2011 05:28, schrieb John Clymer:
> Currently, everything is in a handful of giant arrays. Just wondering
> if it would be better to switch to a record structure for the controller
> entries - rather than individual arrays. (Add in a variety of STM parts
> and the other manufacturers, and
there must be a reason why minicom uses O_NDELAY (=O_NONBLOCK) in case
O_NDELAY ist defined. Now i remember that i had the same problem several
years ago with cat file >/dev/ttyUSB0, i think it was Fedora Core 3 or 4.
I assume this does not only happen with a pl2303.
#if defined(O_NDELAY) && de
On 19 Aug 2011, at 04:28, John Clymer wrote:
> Did an analysis of the Stellaris current product lineup, there are over 180
> current Stellaris products on TI's selection guide. Boiling through the
> FLASH and RAM availability, there are 31 unique configuratios of FLASH / SRAM
> between those
27 matches
Mail list logo
