Re: [fpc-pascal] Shared libraries and threadvars
Am 26.06.2012 20:09 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > One final question if I may: noting Ludo's example elsewhere: > > > In the project.lpr add the following code: > > > > Procedure qt_startup_hook;export; > > Begin > > End; > > > > Exports qt_startup_hook; > > Can such an alternative entry point in the main unit be called by a shared library, i.e. either resolved at load time or with the main binary reopened like a library? Or is the only way to pass a main-program entry point to a shared library by using it as a parameter to a procedure? > > I've used such things in a Windows-style .exe so a loader/binder would know how to generate absolute code for an embedded system, but have never tried exploiting it with a "real" OS. I can't tell you for *nix systems as I'm not experienced enough regarding their dynamic linkers, but I can tell you for Windows systems: If you export functions from a executable (not a DLL) you can get access to these methods from within a library the same way you'd do with a DLL (though I don't know what happens if you load a unrelated executable). As your executable is already loaded no further "instance" of it will be created. There is also the possibility that you link to the executable at link time (in Pascal using the "procedure bla; external 'your.exe' name 'bla'" mechanism). I don't know whether you can build a circle here (in the sense of having the exe depend on that DLL as well) as I have not tested that that mechanism yet. Also there is only one case that I definitely know of that uses this link time variant: drivers on NT based systems (which are simply DLLs) link to ntoskrnl.exe and the kernel loads them dynamically. You can see this if you look into the ndk.pas unit of my Native NT port where the constant NTDLL is set to 'ntoskrnl.exe' instead of 'ntdll.dll' if it is compiled with KMODE defined. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Variable alignment in arm-embedded
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 + 15; > > But to enable the interrupt you have to use the constant itself : > > NVIC_EnableIRQ(EXTI0_IRQn); // enable interrupt from rot.sensor > > Maybe adding some constants for the place in the vector table would be > better ? > Yes, I forgot to mention that. I use it exactly like you have it with the + 15 Koenraad Lelong-2 wrote > > P.S. Did you work already with interrupts ? I found I needed to clear > the "Pending" bit of the interrupt at the end of the interrupt-routine. > Otherwise I never left the interrupt-routine, or so it seemed. I tried > with event-mode but that seemed no solution. > > GPIO_EXTILineConfig(GPIO_PortSourceGPIOA, GPIO_PinSource0); > EXTI_StructInit(EXTI_InitStructure); > EXTI_InitStructure.EXTI_Trigger:=EXTI_Trigger_Rising_Falling; > EXTI_InitStructure.EXTI_Line:=EXTI_Line0; > EXTI_InitStructure.EXTI_LineCmd:=ENABLED; > //EXTI_InitStructure.EXTI_Mode:=EXTI_Mode_Event; > EXTI_Init(EXTI_InitStructure); > Yes, I'm using the following interrupts in one of my projects. USART1, USART2, Systick, Timer1, Timer2, Timer3 and two of the EXTI You need to enable the EXTI interrupt as well. Here is an example for EXTI1. I haven't tried with Event mode yet. I'll give you feedback on this a bit later. Maybe there is also a small problem with the ported library to pascal? and then you need My interrupt procedure looks like follow Thus far my projects are running without any problems or issues and the interrupt are working great. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Variable-alignment-in-arm-embedded-tp5709962p5710183.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Shared libraries and threadvars
Apologies for my lousy message threading, but some are vanishing in the spamtrap. >> OK, so to emphasise that: library B's data will be common, >> irrespective of the location of the calling routine. Does this >> apply if the load is being done at runtime, i.e. the program is >> using dl (or whatever) to load A and B, and A also uses dl to >> load B? > > It does not matter whether the library is loaded at program start > or at runtime. It's always the same mechanism with the exception > that in the first case your main function has not yet been called > (which normally doesn't matter either). Just being cautious :-) One final question if I may: noting Ludo's example elsewhere: > In the project.lpr add the following code: > > Procedure qt_startup_hook;export; > Begin > End; > > Exports qt_startup_hook; Can such an alternative entry point in the main unit be called by a shared library, i.e. either resolved at load time or with the main binary reopened like a library? Or is the only way to pass a main-program entry point to a shared library by using it as a parameter to a procedure? I've used such things in a Windows-style .exe so a loader/binder would know how to generate absolute code for an embedded system, but have never tried exploiting it with a "real" OS. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Shared libraries and threadvars
Am 26.06.2012 17:15 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > > Mark Morgan Lloyd wrote: >>> >>> I'm currently tinkering with shared libraries, using cmem, mainly on Linux. In one case the main-program code is multithreaded, but so far I'm not moving data between threads inside the library. >>> >>> Am I correct in believing that unit-level variables in a shared library might end up being shared between multiple instances of the library, or are they guaranteed to be distinct? >>> >>> If my belief is correct, I presume that I could get around this by using threadvars. But in this case, how would I best implement a variable that I wanted to be common across related threads (e.g. to track the number of a particular object being allocated/deallocated), but distinct across program invocations (i.e. two programs using the same shared library wouldn't clash)? >>> >>> The discussion of libraries in ch16 of the Language reference guide is rather quiet on the semantics. > > > > > A programs memory always belongs to itself (exceptions through mmap or > > kernel related thing excluded) and libraries are loaded into the > > program's memory. Their code sections might only exist once if the OS > > detects that it had already loaded the library somewhere, but it's > > data sections and also the memory it allocates during its lifetime > > belong to the program's memory. > > Thanks Sven. So to summarise: code might be shared, but this generally won't be relevant since it should be read-only. Data- local or global- won't be shared. Correct. Shared code sections shouldn't matter normally. > > > > This means for you: normal global variables in your library are not > > shared with other "instances" of this library (note: if a program > > loads library A and B and library A also loads B then there is only > > one "instance" of the library and its data). They are shared by all > > threads that use this library though. Having variables shared between > > different "instances" of a library is a different topic altogether. > > OK, so to emphasise that: library B's data will be common, irrespective of the location of the calling routine. Does this apply if the load is being done at runtime, i.e. the program is using dl (or whatever) to load A and B, and A also uses dl to load B? It does not matter whether the library is loaded at program start or at runtime. It's always the same mechanism with the exception that in the first case your main function has not yet been called (which normally doesn't matter either). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Shared libraries and threadvars
Mark Morgan Lloyd wrote: I'm currently tinkering with shared libraries, using cmem, mainly on Linux. In one case the main-program code is multithreaded, but so far I'm not moving data between threads inside the library. Am I correct in believing that unit-level variables in a shared library might end up being shared between multiple instances of the library, or are they guaranteed to be distinct? If my belief is correct, I presume that I could get around this by using threadvars. But in this case, how would I best implement a variable that I wanted to be common across related threads (e.g. to track the number of a particular object being allocated/deallocated), but distinct across program invocations (i.e. two programs using the same shared library wouldn't clash)? The discussion of libraries in ch16 of the Language reference guide is rather quiet on the semantics. > > A programs memory always belongs to itself (exceptions through mmap or > kernel related thing excluded) and libraries are loaded into the > program's memory. Their code sections might only exist once if the OS > detects that it had already loaded the library somewhere, but it's > data sections and also the memory it allocates during its lifetime > belong to the program's memory. Thanks Sven. So to summarise: code might be shared, but this generally won't be relevant since it should be read-only. Data- local or global- won't be shared. > This means for you: normal global variables in your library are not > shared with other "instances" of this library (note: if a program > loads library A and B and library A also loads B then there is only > one "instance" of the library and its data). They are shared by all > threads that use this library though. Having variables shared between > different "instances" of a library is a different topic altogether. OK, so to emphasise that: library B's data will be common, irrespective of the location of the calling routine. Does this apply if the load is being done at runtime, i.e. the program is using dl (or whatever) to load A and B, and A also uses dl to load B? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc arm-embedded suitable for cortex-m4 ?
On 26-06-12 09:45, Jeppe Græsdal Johansen wrote: The FPU is single precision only, as far as I remember. That made it a little hard to work with in fpc, and last I took a stab at it there weren't any affordable chips around with support even. Hi Jeppe, Would this be a good candidate to port fpc to cortex-m4 : http://be.farnell.com/stmicroelectronics/stm32f4discovery/board-eval-stm32f4-discovery/dp/2009276 I could sponsor one if you like ;-) And there is no hurry. I need to finish my cortex-m3 project first and see if that processor is fast enough. Regards, Koenraad Lelong ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Shared libraries and threadvars
Am 26.06.2012 14:02 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > > I'm currently tinkering with shared libraries, using cmem, mainly on Linux. In one case the main-program code is multithreaded, but so far I'm not moving data between threads inside the library. > > Am I correct in believing that unit-level variables in a shared library might end up being shared between multiple instances of the library, or are they guaranteed to be distinct? > > If my belief is correct, I presume that I could get around this by using threadvars. But in this case, how would I best implement a variable that I wanted to be common across related threads (e.g. to track the number of a particular object being allocated/deallocated), but distinct across program invocations (i.e. two programs using the same shared library wouldn't clash)? A programs memory always belongs to itself (exceptions through mmap or kernel related thing excluded) and libraries are loaded into the program's memory. Their code sections might only exist once if the OS detects that it had already loaded the library somewhere, but it's data sections and also the memory it allocates during its lifetime belong to the program's memory. This means for you: normal global variables in your library are not shared with other "instances" of this library (note: if a program loads library A and B and library A also loads B then there is only one "instance" of the library and its data). They are shared by all threads that use this library though. Having variables shared between different "instances" of a library is a different topic altogether. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Shared libraries and threadvars
I'm currently tinkering with shared libraries, using cmem, mainly on Linux. In one case the main-program code is multithreaded, but so far I'm not moving data between threads inside the library. Am I correct in believing that unit-level variables in a shared library might end up being shared between multiple instances of the library, or are they guaranteed to be distinct? If my belief is correct, I presume that I could get around this by using threadvars. But in this case, how would I best implement a variable that I wanted to be common across related threads (e.g. to track the number of a particular object being allocated/deallocated), but distinct across program invocations (i.e. two programs using the same shared library wouldn't clash)? The discussion of libraries in ch16 of the Language reference guide is rather quiet on the semantics. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Variable alignment in arm-embedded
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 the vector table you need to add an offset to the constant : procedure Exti0_Proc; interrupt EXTI0_IRQn + 15; But to enable the interrupt you have to use the constant itself : NVIC_EnableIRQ(EXTI0_IRQn); // enable interrupt from rot.sensor Maybe adding some constants for the place in the vector table would be better ? P.S. Did you work already with interrupts ? I found I needed to clear the "Pending" bit of the interrupt at the end of the interrupt-routine. Otherwise I never left the interrupt-routine, or so it seemed. I tried with event-mode but that seemed no solution. GPIO_EXTILineConfig(GPIO_PortSourceGPIOA, GPIO_PinSource0); EXTI_StructInit(EXTI_InitStructure); EXTI_InitStructure.EXTI_Trigger:=EXTI_Trigger_Rising_Falling; EXTI_InitStructure.EXTI_Line:=EXTI_Line0; EXTI_InitStructure.EXTI_LineCmd:=ENABLED; //EXTI_InitStructure.EXTI_Mode:=EXTI_Mode_Event; EXTI_Init(EXTI_InitStructure); Regards, Koen. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc arm-embedded suitable for cortex-m4 ?
The FPU is single precision only, as far as I remember. That made it a little hard to work with in fpc, and last I took a stab at it there weren't any affordable chips around with support even. The DSP instructions will probably need intrinsics to be useful, otherwise I guess they could simply be added as assembler instructions. They are fairly limited in scope anyway Den 26-06-2012 09:37, Koenraad Lelong skrev: Hi, Last week I attended a seminar regarding cortex-m4. I was wondering if fpc works for that processor. AFAIK, the processor is compatible with a cortex-m3, but has a hardware floating point processor and DSP-related instructions. So if fpc would be able to use the floating point processor that would be great. I wouldn't know how to use the dsp-instructions, yet. Thanks for any pointers, Koenraad lelong. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Variable alignment in arm-embedded
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 stm32f1xx_systick.pas >if NewState = DISABLED then > is wrong and should be >if NewState <> DISABLED then > You are correct, I fixed it on my side as well Koenraad Lelong wrote > > Maybe the comments of the c-sources of what the functions do and need as > parameters should be included. > I'm busy adding the library files onto my wepage with version control (git). Then we can add the comments to the source files and continue from there. Koenraad Lelong wrote > > The LCD-unit seems not to specify for which LCD the software is written, > and contains a unit which is not there (defPSPlcd -> PlayStationP LCD ?). > Yes, In my project I'm driving a 4.2" 24bit 480x272 Color LCD, same as you will find in a PlayStation Portable. Thank you for the feedback, does this mean you got the interrupt working with my patches?? -- Anton -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Variable-alignment-in-arm-embedded-tp5709962p5710174.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpc arm-embedded suitable for cortex-m4 ?
Hi, Last week I attended a seminar regarding cortex-m4. I was wondering if fpc works for that processor. AFAIK, the processor is compatible with a cortex-m3, but has a hardware floating point processor and DSP-related instructions. So if fpc would be able to use the floating point processor that would be great. I wouldn't know how to use the dsp-instructions, yet. Thanks for any pointers, Koenraad lelong. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : [fpc-pascal] Variable alignment in arm-embedded
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 should be if NewState <> DISABLED then That's compared to the c-sources, and now it's working for me. Maybe the comments of the c-sources of what the functions do and need as parameters should be included. The LCD-unit seems not to specify for which LCD the software is written, and contains a unit which is not there (defPSPlcd -> PlayStationP LCD ?). If someone is interested in my LCD driver (for the Nokia 6610 display with non-Philips chip, MOD-NOKIA6610 from Olimex) I can post it. I think it should be usable on other cortex-m3 boards than mine. Anyway, thanks for all help. Koenraad Lelong. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
