April 10, 2015 Re: Creating a microcontroller startup file | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jens Bauer | On Wednesday, 8 April 2015 at 15:25:20 UTC, Jens Bauer wrote: >>> Question number 2: Is it possible to change the VectorFunc to be a real function pointer, rather than a void* ? > >> immutable ISR[3] g_pfnVectors = >> [ >> cast(ISR)&_stack >> , &Reset_Handler >> , &NMI_Handler >> , &HardFault_Handler >> ]; > > In your example, you do not have the initial stack pointer. > The above code gives me the following: > src/test.d:24:13: error: reinterpreting cast from uint* to void()* is not supported in CTFE > cast(ISR)&_stack > ^ > > -That's the only reason I needed to change it to from function() to void*. > Can you successfully cast(ISR)&_stack ? I don't know if that's a constraint of the language or a limitation of the current CTFE implementation, but either way, I never really liked it. I know the C folks do this stuff all the time, but I think it's kinda janky. I know of two potential alternatives: 1) Do it in the linker script (my current method): MEMORY { CCRAM (rxw) : ORIGIN = 0x10000000, LENGTH = 64k } /* Falling stack starts at the end of the CCM */ _stackStart = ORIGIN(CCRAM) + LENGTH(CCRAM); SECTIONS { .text : { LONG(_stackStart); KEEP(YourISRVectorTable); } } 2) Use a union (See pp. 10 here: http://www.state-machine.com/arm/QDK_ARM-Cortex_STM32-GNU.pdf) C Code to be adapted to D: typedef void (*ExceptionHandler)(void); typedef union { ExceptionHandler handler; void *pointer; } VectorTableEntry; __attribute__ ((section(".isr_vector"))) VectorTableEntry const g_pfnVectors[] = { { .pointer = &__c_stack_top__ }, { .handler = &Reset_Handler }, { .handler = &NMI_Handler }, ... ect ... }; Mike |
April 11, 2015 Re: Creating a microcontroller startup file | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike | On Wednesday, 8 April 2015 at 23:18:41 UTC, Mike wrote:
> You may also wnat to compile with -nodefaultlibs -nostdlib -nostartfiles. That removes the cruntime and libgcc.
I forgot about those. Yes, when excluded those and added a /DISCARD/ for the exidx and armexidx, I finally got rid of the huge overhead.
Thank you so much!
I guess that the CTFE optimizes any function calls if they reside in the startup.d file, because if I keep it in the startup.d, then the size stays small, but as soon as I move a called function out from the startup.d into its own file, then the overhead shows up.
-But it's no longer a problem. ;)
|
April 11, 2015 Re: Creating a microcontroller startup file | ||||
---|---|---|---|---|
| ||||
Posted in reply to Artur Skawina | On Thursday, 9 April 2015 at 10:47:42 UTC, Artur Skawina wrote: >>> On Tuesday, 7 April 2015 at 20:33:26 UTC, Jens Bauer wrote: >> >> -It would be neat, if @attribute("weak") and @attribute("alias","function") could be combined into one, but I haven't found a way to do that > > http://forum.dlang.org/post/mailman.2672.1403379235.2907.digitalmars-d@puremagic.com Thank you, Artur. This is what I did (it's very close to the above; just slightly modified): enum weak = gcc.attribute.attribute("weak"); alias Tuple(A...) = A; alias rst = Tuple!(weak, gcc.attribute.attribute("alias", "defaultResetHandler")); alias exc = Tuple!(weak, gcc.attribute.attribute("alias", "defaultExceptionHandler")); So now the code is much easier to read ... @rst extern(C) void Reset_Handler(); @exc extern(C) void NMI_Handler(); @exc extern(C) void HardFault_Handler(); ... ... @exc extern(C) void LTDC_ER_IRQHandler(); @exc extern(C) void DMA2D_IRQHandler(); |
April 11, 2015 Re: Creating a microcontroller startup file | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike | On Friday, 10 April 2015 at 00:05:29 UTC, Mike wrote: > On Wednesday, 8 April 2015 at 15:25:20 UTC, Jens Bauer wrote: > >>>> Question number 2: Is it possible to change the VectorFunc to be a real function pointer, rather than a void* ? >> >> Can you successfully cast(ISR)&_stack ? > > I don't know if that's a constraint of the language or a limitation of the current CTFE implementation, but either way, I never really liked it. I don't really like typecasting myself, but I know a function pointer and a stack pointer are both pointers, thus they're the same size. > I know the C folks do this stuff all the time, but I think it's kinda janky. True, but I need to write my files flexible, so that the majority of people will be able to use it out-of-the-box. I have to keep in mind that there are people who will make a part of their code in C during the transition phase, and I have to keep in mind that those who wrote the library in C, probably won't provide a complete library in D within the first week. ;) I agree with you on the 'minimal' style. I too hate all the junk that's added. 'printf' has always been prohibited in my microcontroller code - I don't have a file system on my microcontroller; no screen, no keyboard and no harddisk, thus I don't want anything that has any connection to printf or a file system. ;) Basically my startup.d will be very similar to the startup.s you already know (I translated my startup.s into a startup.c a long time ago - because I didn't want one for each type of assembler). > I know of two potential alternatives: > 1) Do it in the linker script (my current method): Two things makes me little fond of this solution: 1: The "LONG" type. If it had been "PTR" or "UINT32", then it would be more attractive, but I do not expect those types exist. 2: I like people to be able to define the stack location inside the sources if they want to. That means: Typically the linker script will provide it, but some people need to move the stack, and I don't want them to need to change the linker script (if at all possible). > 2) Use a union (See pp. 10 here: This solution is probably more appealing to me. I'll need to make some more tests. My initial attempt was to create a function, which did the type conversion via a CTFE function, buuut it didn't like that the symbol was undefined and not a constant, so I'll have to make a few more attempts. Thank you again for your valuable help. I hope that my fiddling will bring you something useful too. ;) |
Copyright © 1999-2021 by the D Language Foundation