On 13-06-12 07:01, alrieckert wrote:
...
Just to report back.
I'm making progress with my embedded application. Learning to use the
processor is not easy compared to 8 bit processors.
I found a bug in Anton's library though:
in stm32f1xx_systick.pas
if NewState = DISABLED then
is wrong and
Koenraad Lelong wrote
I'm making progress with my embedded application. Learning to use the
processor is not easy compared to 8 bit processors.
These processors are powerful and cheaper than 8 bit micros :)
Koenraad Lelong wrote
I found a bug in Anton's library though:
in
On 26-06-12 09:38, alrieckert wrote:
Thank you for the feedback, does this mean you got the interrupt working
with my patches??
Hi Anton,
Yes, I got interrupts working now.
It took some experimenting though. Or maybe I'm missing something. To
get the interrupt procedure on the right place in
Koenraad Lelong-2 wrote
Yes, I got interrupts working now.
It took some experimenting though. Or maybe I'm missing something. To
get the interrupt procedure on the right place in the vector table you
need to add an offset to the constant :
procedure Exti0_Proc; interrupt EXTI0_IRQn +
On Wed, June 13, 2012 07:37, alrieckert wrote:
alrieckert wrote
Please just make sure about your starting address for the flash. I'm
using
the STM32F103CBT6 and the start address is 0x0800 and not 0x080
I've just verified it. The starting address for the flash should be
0x0800.
On 13-06-12 07:37, alrieckert wrote:
alrieckert wrote
Please just make sure about your starting address for the flash. I'm using
the STM32F103CBT6 and the start address is 0x0800 and not 0x080
I've just verified it. The starting address for the flash should be
0x0800. The reason
Koenraad Lelong-2 wrote
About that DFU-loader, do you have to do anything special to be able to
use fpc, besides modifying your start-address ? Any links to read more
about it ?
Now I'm using jtag to flash and debug my software.
Hi Koenraad,
I'm using DfuSe USB device firmware upgrade
Tomas Hajny-2 wrote
Sorry for a possibly stupid question, but is this offset (conceptionally)
comparable to the -WB option used for some other targets? If so, it might
make sense to extend it also for your case...
Hi Tomas,
Not a stupid question at all. To be totally honest, I have no
Florian Klämpfl wrote
Better submit a bug tracker entry. This way it cannot get lost.
Hi Florian,
Thank you, I do have an open bug on this issue here
http://bugs.freepascal.org/view.php?id=22146 Freepascal Bug ID 22146
--
Regards
Anton Rieckert
--
View this message in context:
On Wed, June 13, 2012 12:55, alrieckert wrote:
Tomas Hajny-2 wrote
Sorry for a possibly stupid question, but is this offset
(conceptionally)
comparable to the -WB option used for some other targets? If so, it
might
make sense to extend it also for your case...
Hi Tomas,
Not a stupid
On 08-06-12 14:37, Jeppe Græsdal Johansen wrote:
Den 08-06-2012 14:28, Ludo Brands skrev:
Thanks Ludo,
I'll take that as a starting point. I hope I will not need the lost
256 bytes in the future.
I could be wrong but AFAIK if the compiler would do the alignment, the
loss
can also be up to 255
Hi Jeppe,
I've been using the actual ROM based interrupt table for the past month now
in freepascal ad it seems to work great. No need to declare a block of RAM
and pointing the interrupt table to it.
You can code any procedure and just give it the interrupt keyword with an
address index.
For
Am 08.06.2012 14:37, schrieb Jeppe Græsdal Johansen:
Den 08-06-2012 14:28, Ludo Brands skrev:
Thanks Ludo,
I'll take that as a starting point. I hope I will not need the lost
256 bytes in the future.
I could be wrong but AFAIK if the compiler would do the alignment, the
loss
can also be up to
Am 12.06.2012 09:50, schrieb Koenraad Lelong:
On 08-06-12 14:37, Jeppe Græsdal Johansen wrote:
Den 08-06-2012 14:28, Ludo Brands skrev:
Thanks Ludo,
I'll take that as a starting point. I hope I will not need the lost
256 bytes in the future.
I could be wrong but AFAIK if the compiler would
Am 11.06.2012 13:46, schrieb alrieckert:
Hi Jeppe,
I've been using the actual ROM based interrupt table for the past
month now in freepascal ad it seems to work great. No need to declare
a block of RAM and pointing the interrupt table to it.
You can code any procedure and just give it the
On 11-06-12 13:46, alrieckert wrote:
Hi Jeppe,
I've been using the actual ROM based interrupt table for the past month now
in freepascal ad it seems to work great. No need to declare a block of RAM
and pointing the interrupt table to it.
...
Please let me know if you have any questions.
--
Hi Koenraad,
Glad to see more people that want to make use of Freepascal for STM32.
I've had a quick look at your project and everything seems fine. The only
thing I noted is that the interrupt procedures must be in a separate unit.
I've changed your project and recompiled it and now it seems
alrieckert wrote
I'll have a look at why the interrupt procedures needs to be separate and
get back to you.
Ok, the compiler was only scanning the used source files for interrupt
procedures and not the main file as well. I've added the necessary code to
ncgutil.pas that will allow the
alrieckert wrote
Please just make sure about your starting address for the flash. I'm using
the STM32F103CBT6 and the start address is 0x0800 and not 0x080
I've just verified it. The starting address for the flash should be
0x0800. The reason for mine being 0x08003000 is that
On 08-06-12 06:45, Ludo Brands wrote:
Handcrafted alignment:
var
ReservedBlock:array[0..$1FF] of byte;
IntVectors:pointer;
begin
IntVectors:=pointer((ptruint(@ReservedBlock[0])+$100) and not $ff);
End;
Or dynamic:
Var
pReservedBlock,IntVectors:pointer;
begin
Thanks Ludo,
I'll take that as a starting point. I hope I will not need the lost
256 bytes in the future.
I could be wrong but AFAIK if the compiler would do the alignment, the loss
can also be up to 255 bytes. Here you lose 256 bytes in all cases.
I can replace the IntVectors-pointer
Den 08-06-2012 14:28, Ludo Brands skrev:
Thanks Ludo,
I'll take that as a starting point. I hope I will not need the lost
256 bytes in the future.
I could be wrong but AFAIK if the compiler would do the alignment, the loss
can also be up to 255 bytes. Here you lose 256 bytes in all cases.
Yes,
Hi,
I want to make an interrupt-vector-table for the cortex-M3 processor.
When I read the docs of the processor good, the start of that table
needs to be on a multiple of $100 bytes in memory. Since with FPC there
seems no way of getting that table in flash I need to have it in RAM.
But how
Hi,
I want to make an interrupt-vector-table for the cortex-M3 processor.
When I read the docs of the processor good, the start of that table
needs to be on a multiple of $100 bytes in memory. Since with
FPC there
seems no way of getting that table in flash I need to have it in RAM.
24 matches
Mail list logo
