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_IR
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 t
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 stm3
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,
>
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:
http://
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 n
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 u
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
>
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
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 c
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 fin
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 inter
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 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 t
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 ex
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 25
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
> 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-poin
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
Getmem(pReservedBlo
19 matches
Mail list logo
