Re: Startup files for STM32F4xx
On Friday, 24 April 2015 at 22:18:22 UTC, tom wrote: On Friday, 24 April 2015 at 13:12:56 UTC, Jens Bauer wrote: On Friday, 24 April 2015 at 07:34:55 UTC, tom wrote: would something like a STM32 NUCLEO-F401RE work? I forgot to give you a proper answer on this one: I think it should work, as it's a STM32F401 microcontroller. ill order a discover, i have to try this out. http://www.digikey.com/product-detail/en/STM32F4DISCOVERY/497-11455-ND/2711743 this one right? Tom, I'm curious - did you get a board ? :)
Re: Startup files for STM32F4xx
Am Sun, 26 Apr 2015 00:14:42 + schrieb Mike n...@none.com: Usage: auto b = PORTB.load(); PORTB.toggle!PIN0; PORTB.PIN0 = Level.low; writeln(PORTB.PIN0); PORTB.TEST = 0b000; That's some nice code! and really leveraging D to great effect. I know that Volatile!(T) took some engineering to get right, so it would be nice to have that as an official type IMO. It should certainly be in druntime in the long term. But first it needs quite some testing. Maybe I'll propose it for std.experimental or I'll create a dub-package first. The remaining problem is performance. (With optimization the generated code is as good as equivalent C code. However, we need to avoid size overhead: e.g. struct initializers and the opX functions shouldn't generate functions in the executable, though tha can be fixed with the linker) I'm not sure I follow how the linker can solve this. Could you elaborate? That was a sloppily written statement, sorry. Performance as in speed / number of instructions / cycles is not an issue with optimization. Default initialization is a problem as even all-zero initializers go into bss right now. So we need n bytes per struct type in the bss section. (For the register wrapper every register is a type). If they went into rodata instead and if the linker merges all-zero symbols then the overhead is limited to the biggest used struct size. I'm not sure if linkers do this optimization. For small functions (the generated properties, operator overloads) the problem is that these are always force-inlined for performance but we still output a complete function (in order to give the function a valid address and similar things). The linker can remove these with -ffunction-sections and --gc-sections. It might still be nice to have 'static (force)inline' / 'extern (force)inline' semantics[1][2][3]. [1] http://stackoverflow.com/a/216546/471401 [2] http://www.greenend.org.uk/rjk/tech/inline.html [3] https://gcc.gnu.org/onlinedocs/gcc/Inline.html
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 17:04:18 UTC, Jens Bauer wrote: I think volatileLoad and volatileStore are intended for this (please correct me if my understanding is wrong). Yes. Actually I am not sure whether they already exist in gdc or not. Try to write for example regs.cmdr |= 0x20 with these functions and guess how many users will move to another language.
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 17:58:59 UTC, Timo Sintonen wrote: On Saturday, 25 April 2015 at 17:04:18 UTC, Jens Bauer wrote: I think volatileLoad and volatileStore are intended for this (please correct me if my understanding is wrong). Yes. Actually I am not sure whether they already exist in gdc or not. Try to write for example regs.cmdr |= 0x20 with these functions and guess how many users will move to another language. Ah, I get the point now. :) I don't want to start another volatile discussion, but to me it seems an attribute would not be a bad idea. -And for completeness... read-only, write-only, read/write and perhaps even 'prohibited access'. I recall that something was marked prohibited in some way in a library once; I forgot how they did it, though.
Re: Startup files for STM32F4xx
Am Sat, 25 Apr 2015 11:38:45 +
schrieb Martin Nowak c...@dawg.eu:
On Saturday, 25 April 2015 at 05:07:04 UTC, Jens Bauer wrote:
I hope to find a good way to use import for microcontroller
libraries, so it'll be easy for everyone. I'm thinking about
something like ...
import mcu.stm32f439.all
I think that belongs in the makefile/dub.json as
-version=STM32F439.
Then you could simply import mcu.gpio or mcu.spi.
We need a better / clever generic approach to solve 'board
configuration' issues. Here version blocks work but you might also
want to specify other configuration options (clock speed if
static, ...) and we don't have -D to define constants.
I think we could use 'reverse' imports but I'm not sure if it's a
horrible hack or a great idea:
When compiling library code:
// board.di (Only 'runtime' config variables)
-
module board.config;
__gshared const int configA;
__gshared const int configB;
-
//library code: lib.d
-
import board.config;
void doFoo() // Function = runtime value
{
auto a = configA;
}
void templateFoo()() // Template = ctfe value
{
auto b = ctfeConfigA; //This value is not in .di = error if
//template is instantiated in the library
}
-
gdc lib.d -Ipath/for/board.di -o lib.o
User code:
// board.d ('runtime' + 'ctfe' config variables)
-
module board.config;
__gshared const int configA = 42;
__gshared const int configB = 42;
enum ctfeConfigA = 42;
-
gdc lib.o board.d
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 16:32:50 UTC, Timo Sintonen wrote: On Saturday, 25 April 2015 at 11:56:55 UTC, Martin Nowak wrote: You better dismiss the idea of using druntime/phobos. The minimum runtime I have made does fit in 64k rom/ 64k ram, which all STM32F4 devices have. With some work it may even fit to the smaller memory of STM32F0. I definitely think it's possible to do this, as I've already been using Timo's minlibd. -But I'm thinking of something even simpler: No file system support at all - and a few other things when I come across them. ;) I have not yet needed anything from libc/phobos in my programs. I think that I should focus on making it possible to ... 1: Use classes (I find this very important) 2: Strings 3: Associative arrays Perhaps a few other important features will be added to the list (I do not know the D language that well yet, so there is most likely something else)
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 16:32:50 UTC, Timo Sintonen wrote: On Saturday, 25 April 2015 at 11:56:55 UTC, Martin Nowak wrote: I have not yet needed anything from libc/phobos in my programs. I think there's a few gems that can be cherry-picked out of Phobos, especially for metaprogramming: std.traits std.typecons std.typetuple There are also a couple things in these libraries that might be useful for programming in general: std.conv std.string std.array Mike
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 16:28:24 UTC, Timo Sintonen wrote: My work is based on the feature that a shared variable is marked as volatile in gcc. This feature is buggy and should not be used in the future. I think volatileLoad and volatileStore are intended for this (please correct me if my understanding is wrong). The official way is to use library functions to access registers but I think this results to horrible looking code. Are these library functions the above mentioned volatileLoad / volatileStore ? Someone might then make an sample driver and after discussion we all could start write drivers the same way. I Agree. It would just be plain typing-till-your-fingers-hurt after that. ;)
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 11:50:19 UTC, Martin Nowak wrote: On Saturday, 25 April 2015 at 07:31:45 UTC, Jens Bauer wrote: Static constructors are possible if you strip down ModuleInfo (requires compiler hacking). You should care about that stuff last. It's way more important to make things work without dynamic memory allocation first. I agree and thanks for reminding me; I don't want to lose my focus. ;) That means 'new' and 'delete' / 'malloc' and 'free' must be able to handle multiple RAM locations (because there's also external SRAM and external SDRAM). IIRC then the C/C++ malloc would simply can your sbrk Heh, I didn't know about sbrk before I almost finished writing mine. This resulted in that mine can be used side-by-side with the standard malloc. (I named mine m_malloc and m_free). implementation, so it only supports a single heap, which should be the external if available. In C++, it's possible to override new and delete on a per-class basis, I'd expect that this is possible in D as well, is this correct ? -If it is, then I think there's no problem, because then the class can handle special cases, when it knows it's working with the DMA. Allocation could default to SDRAM if SDRAM exists; then external SRAM, then CCMRAM and finally fallback to Local on-chip SRAM. (Note: any external RAM needs to be initialized by the microcontroller's firmware, before the external RAM can be used, I do not know if that could be a problem with the linker-generated static constructors).
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 19:33:05 UTC, Johannes Pfau wrote:
volatileLoad is not in gdc yet. I've written the code some
months ago
but I need to update it and then it needs to be reviewed.
It's officially in 2.067.0 for anyone who's wondering.
Volatile!T: http://dpaste.dzfl.pl/dd7fa4c3d42b
Volatile!size_t value;
value += 1;
assert(value == 1);
Register wrapper: http://dpaste.dzfl.pl/3e6314714541
Register definition:
enum Level : ubyte
{
low = 0,
high = 1
}
enum fields = [
Field(PIN0, 0, 0, true, Level, Access.readWrite),
Field(PIN1, 1, 1, true, Level, Access.readWrite),
Field(TEST, 2, 4, false, ubyte, Access.readWrite)];
mixin(generateRegisterType!ubyte(PORT, fields));
pragma(address, 0x25) extern __gshared PORTRegister PORTB;
Usage:
auto b = PORTB.load();
PORTB.toggle!PIN0;
PORTB.PIN0 = Level.low;
writeln(PORTB.PIN0);
PORTB.TEST = 0b000;
That's some nice code! and really leveraging D to great effect.
I know that Volatile!(T) took some engineering to get right, so
it would be nice to have that as an official type IMO.
The remaining problem is performance. (With optimization the
generated
code is as good as equivalent C code. However, we need to avoid
size
overhead: e.g. struct initializers and the opX functions
shouldn't
generate functions in the executable, though tha can be fixed
with the
linker)
I'm not sure I follow how the linker can solve this. Could you
elaborate?
Mike
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 11:34:58 UTC, Martin Nowak wrote: You can very well abstract an SPI, just need to have an abstraction for pins. http://developer.mbed.org/handbook/SPI Considering all the problems involved, I will not be doing any abstraction. What I will provide, is a set of templates and startup-files generated from those templates. The inital LPC17xx and STM32F4xx repositories will be short-lived. I'll be creating a single repository for all startup-files, which also means I will make a tree that looks something like this: mcu/ stm32/ lpc/ kinetis/ tivo/ ... ... common/ Inside each device folder, I'll probably make space for hardware definitions, but I will not provide any classes and further convenience. I'll, however, try to keep things fairly consistent, and in some cases I'll be so annoying that I'll rename the names of the interrupt vectors that the vendors provide. ;)
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 17:11:22 UTC, Johannes Pfau wrote:
Am Sat, 25 Apr 2015 11:38:45 +
schrieb Martin Nowak c...@dawg.eu:
On Saturday, 25 April 2015 at 05:07:04 UTC, Jens Bauer wrote:
import mcu.stm32f439.all
I think that belongs in the makefile/dub.json as
-version=STM32F439.
Then you could simply import mcu.gpio or mcu.spi.
We need a better / clever generic approach to solve 'board
configuration' issues. Here version blocks work but you might
also
want to specify other configuration options (clock speed if
static, ...) and we don't have -D to define constants.
I actually attempted to use version on the exception vector list,
but as you cannot do this ...
@isr_vector VectorFunc[] g_pfnVectors = [
cast(VectorFunc)_stack,
Reset_Handler,
version(USB){
USBActivity_IRQHandler,
} version(CAN){
CANActivity_IRQHandler,
}
];
... I ditched the idea. There might be a good way for doing this,
so that the number of startup files can be reduced, and perhaps
allow for increased convenience.
One thing that's tedious, is when the vendor replaces a single
handler in a later device implementation.
I can't seem to make a chain of weak aliases, eg..
SPI0_Interrupt() defaults to defaultExceptionHandler()
SPI_Interrupt() defaults to SPI0_Interrupt()
implementing SPI_Interrupt() would then automatically use this in
the exception vector, but if also implementing SPI0_Interrupt(),
thene SPI0_Interrupt() would have higher priority and
SPI_Interrupt() should be discarded.
If neither SPI0_Interrupt() nor SPI_Interrupt() is implemented,
then they would fallback to defaultExceptionHandler().
-I could not get such an 'alias-chain' working; perhaps it's just
because I got confused, perhaps it's because the compiler does
not support it. - I don't know yet. ;)
If an alias-chain was possible, I think the startup files could
become fairly pretty, and there wouldn't be problems with using
the wrong handler name on chips where the vendors decided to
rename the handler functions within one chip-family (I won't tell
anyone who you are, NXP - I promise!).
Re: Startup files for STM32F4xx
Am Sat, 25 Apr 2015 18:31:45 +
schrieb Jens Bauer doc...@who.no:
On Saturday, 25 April 2015 at 17:58:59 UTC, Timo Sintonen wrote:
On Saturday, 25 April 2015 at 17:04:18 UTC, Jens Bauer wrote:
I think volatileLoad and volatileStore are intended for this
(please correct me if my understanding is wrong).
Yes. Actually I am not sure whether they already exist in gdc
or not.
Try to write for example
regs.cmdr |= 0x20
with these functions and guess how many users will move to
another language.
Ah, I get the point now. :)
I don't want to start another volatile discussion, but to me it
seems an attribute would not be a bad idea.
-And for completeness... read-only, write-only, read/write and
perhaps even 'prohibited access'. I recall that something was
marked prohibited in some way in a library once; I forgot how
they did it, though.
volatileLoad is not in gdc yet. I've written the code some months ago
but I need to update it and then it needs to be reviewed.
Always using volatileLoad/Store is annoying. The solution is to write a
wrapper:
Volatile!T: http://dpaste.dzfl.pl/dd7fa4c3d42b
Volatile!size_t value;
value += 1;
assert(value == 1);
Register wrapper: http://dpaste.dzfl.pl/3e6314714541
Register definition:
enum Level : ubyte
{
low = 0,
high = 1
}
enum fields = [
Field(PIN0, 0, 0, true, Level, Access.readWrite),
Field(PIN1, 1, 1, true, Level, Access.readWrite),
Field(TEST, 2, 4, false, ubyte, Access.readWrite)];
mixin(generateRegisterType!ubyte(PORT, fields));
pragma(address, 0x25) extern __gshared PORTRegister PORTB;
Usage:
auto b = PORTB.load();
PORTB.toggle!PIN0;
PORTB.PIN0 = Level.low;
writeln(PORTB.PIN0);
PORTB.TEST = 0b000;
The remaining problem is performance. (With optimization the generated
code is as good as equivalent C code. However, we need to avoid size
overhead: e.g. struct initializers and the opX functions shouldn't
generate functions in the executable, though tha can be fixed with the
linker)
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 19:33:05 UTC, Johannes Pfau wrote:
Am Sat, 25 Apr 2015 18:31:45 +
schrieb Jens Bauer doc...@who.no:
I don't want to start another volatile discussion, but to me
it seems an attribute would not be a bad idea.
-And for completeness... read-only, write-only, read/write and
perhaps even 'prohibited access'. I recall that something was
marked prohibited in some way in a library once; I forgot how
they did it, though.
volatileLoad is not in gdc yet. I've written the code some
months ago
but I need to update it and then it needs to be reviewed.
I might be able to do a few tests, but I don't feel qualified for
code reviewing at this time. ;)
Always using volatileLoad/Store is annoying. The solution is to
write a wrapper:
I was hoping for something in that direction.
Volatile!size_t value;
{snip}
Usage:
auto b = PORTB.load();
PORTB.toggle!PIN0;
PORTB.PIN0 = Level.low;
writeln(PORTB.PIN0);
PORTB.TEST = 0b000;
It is much more convenient to use it this way, yes; I think it
will cover most needs.
Regarding performance: If a real high time-critical speed is
needed, people would probably use assembly code anyway. ;)
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 11:38:46 UTC, Martin Nowak wrote: On Saturday, 25 April 2015 at 05:07:04 UTC, Jens Bauer wrote: I hope to find a good way to use import for microcontroller libraries, so it'll be easy for everyone. I'm thinking about something like ... import mcu.stm32f439.all I think that belongs in the makefile/dub.json as -version=STM32F439. Then you could simply import mcu.gpio or mcu.spi. I've had the same thoughts myself, but I do not like forcing the user to modify the Makefile. (I currently have a -complicated- Makefile system, which does not require the Makefile to be modified) I don't want to require the user to edit the linker-script either (though we're not really speaking about that; my point is that I want it to be simple and easy for D-newcomers; whether D is their first or 2nd language). It could be a good solution to use version(Ethernet), version(SPI5), version(LTDC) and version(SAI2) ... to enable interrupt handlers in the modules. -But as I have not really worked with modules yet, there are still a lot of unknowns - I'm only guessing here.
Re: Startup files for STM32F4xx
On Sunday, 26 April 2015 at 00:52:56 UTC, Mike wrote: On Saturday, 25 April 2015 at 16:32:50 UTC, Timo Sintonen wrote: I think there's a few gems that can be cherry-picked out of Phobos, especially for metaprogramming: std.traits std.typecons std.typetuple There are also a couple things in these libraries that might be useful for programming in general: std.conv std.string std.array Mike Yes. This has been in my plans but I have not hurried because: -Import mess. Phobos files import several other files. Some of them cannot be used. Work is going on to remove unnecessary imports and use scoped imports. It is important that imports for unittests are only in unittest blocks. -All functions have to be nogc. Active work is going on also in this area. The files should just be tried one by one to see if they can be compiled.
Re: Startup files for STM32F4xx
On 4/25/2015 10:02 PM, Timo Sintonen via Digitalmars-d-learn wrote: -Import mess. Phobos files import several other files. Some of them cannot be used. Work is going on to remove unnecessary imports and use scoped imports. It is important that imports for unittests are only in unittest blocks. -All functions have to be nogc. Active work is going on also in this area. The files should just be tried one by one to see if they can be compiled. It's important to note that most of the work occurring on these fronts is use-case driven. Not much is happening for the sake of completeness (except to some degree by Walter). So, your needs where they don't overlap with someone else's needs, might well take a long time to get done unless you do some of the driving. Even tackling the improvement of one or two api's helps drive towards completion.
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 06:25:08 UTC, tom wrote: On Saturday, 25 April 2015 at 04:01:47 UTC, Jens Bauer wrote: (still no automatic mirroring, though I've installed https://github.com/miracle2k/gitolite-simple-mirror) it should be fairly simple, check the logs. It's probably something silly being wrong. The logs does not report any errors, except for that stupid line I always get from gitweb: CGI::param called in list context from package main line 874 (they promised that it was fixed in v2.1, but I'm on 2.3.6 and it still spams my Apache error-log). The gitolite-log also seems to be fine. most probably something failing with authentication. I tried a manual clone from the 'd' server's account, it seems to clone without problems (and there's no passphrase blocking it from completing) another approach would be that you just add the github as a second remote repository and push to both (e.g. via a simple shell alias in your shells rc file) So far, I made a small script that mirrors when I run it. I could also add a cron-job on the server until I find a solution; but I think I'll stick to the manual mirror until I find out what the problem is. i'm mostly on os x / archlinux. both contain packages for openocd. i just did a ```brew install openocd --HEAD``` and it installed smoothly. That's great. Did you build GDC or LDC for arm-none-eabi already ? If you have built the compiler too, then I think you're all set. The linker-scripts should work fine and the startup file is ready for use. What's still missing is some kind of portable Makefile. My own Makefile seem to be too complex to port. It might be best to start from scratch with a simple Makefile.
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 05:14:57 UTC, Rikki Cattermole wrote: On 25/04/2015 5:07 p.m., Jens Bauer wrote: I hope to find a good way to use import for microcontroller libraries, so it'll be easy for everyone. I'm thinking about something like ... import mcu.stm32f439.all Ugh, package.d? I don't know ... Maybe, but what I have in mind is a tree like this: mcu/ common/ ... (Cypress Semiconductor here) ... lpc81x/ lpc82x/ lpc15xx/ lpc175x_6x/ lpc177x_8x/ lpc40xx/ lpc43xx/ ... (Freescale Kinetis here) ... stm32f401/ stm32f405/ stm32f407/ stm32f411/ stm32f415/ stm32f417/ stm32f427/ stm32f429/ stm32f437/ stm32f439/ ... (Texas Instruments here) ... -Because there would be some things that can be recycled for all microcontrollers, and there will be a lot of different device types. Things that can be recycled would be carefully written drivers, such as LCD drivers that uses the SPI protocol. The SPI interface itself cannot be recycled, though, as each device has different SPI hardware and different GPIO hardware. It could also be 'minimalistic memory handlers' and other algorithms, which do not know anything about hardware. It might be possible to make a CMSIS which can be recycled as well.
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 04:01:47 UTC, Jens Bauer wrote: (still no automatic mirroring, though I've installed https://github.com/miracle2k/gitolite-simple-mirror) it should be fairly simple, check the logs. most probably something failing with authentication. (btw, for those who don't know it: https://github.com/gogits/gogs more or less a simplified github clone that runs as a single binary, pretty neat) another approach would be that you just add the github as a second remote repository and push to both (e.g. via a simple shell alias in your shells rc file) i'm mostly on os x / archlinux. both contain packages for openocd. i just did a ```brew install openocd --HEAD``` and it installed smoothly.
Re: Startup files for STM32F4xx
On 25/04/2015 7:04 p.m., Jens Bauer wrote: On Saturday, 25 April 2015 at 05:14:57 UTC, Rikki Cattermole wrote: On 25/04/2015 5:07 p.m., Jens Bauer wrote: I hope to find a good way to use import for microcontroller libraries, so it'll be easy for everyone. I'm thinking about something like ... import mcu.stm32f439.all Ugh, package.d? I don't know ... Maybe, but what I have in mind is a tree like this: mcu/ common/ ... (Cypress Semiconductor here) ... lpc81x/ lpc82x/ lpc15xx/ lpc175x_6x/ lpc177x_8x/ lpc40xx/ lpc43xx/ ... (Freescale Kinetis here) ... stm32f401/ stm32f405/ stm32f407/ stm32f411/ stm32f415/ stm32f417/ stm32f427/ stm32f429/ stm32f437/ stm32f439/ ... (Texas Instruments here) ... -Because there would be some things that can be recycled for all microcontrollers, and there will be a lot of different device types. Things that can be recycled would be carefully written drivers, such as LCD drivers that uses the SPI protocol. The SPI interface itself cannot be recycled, though, as each device has different SPI hardware and different GPIO hardware. It could also be 'minimalistic memory handlers' and other algorithms, which do not know anything about hardware. It might be possible to make a CMSIS which can be recycled as well. I was referring to package.d files. And publically importing all below modules/packages. I wonder if you can get e.g. interfaces and classes working. At worse maybe structs + alias this + meta programming for e.g. drivers?
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 07:08:26 UTC, Rikki Cattermole wrote: I was referring to package.d files. And publically importing all below modules/packages. Normally, one would want to import only the most necessary parts. Let's take an example: A microcontroller has USB, LCD controller, Ethernet, U(s)ART, SPI, CAN, I2S, I2C and also supports SDRAM. -But the program being developed only needs the LCD controller and the USART, so the Ethernet should not be imported, because if it's seen by the linker, the linker will include it in the final binary. Thus the final binary will be huge, if all of those interfaces are imported. NXP made some #ifdef in their header files and it was terrible working with these. You couldn't build one library, which would work with all your projects, because then you would have a big lump containing everything, including all the stuff you wouldn't need. I wonder if you can get e.g. interfaces and classes working. I hope I will. ;) I think classes are really a must. The only thing that I (currently) see that could perhaps block this from working, would be missing support for static constructors and a missing memory allocator. The missing memory allocator would be entirely because I would have disabled it; this might be necessary on very small devices (such as 1K RAM devices or worse). Devices that have 64K on-chip memory might be big enough for using new and delete on a regular basis (this is just guesswork). If the programmer is instantiating classes carefully, it should be possible to avoid too many problems. My current startup.d files do not support static constructors. static destructors are obsolete, because a microcontroller never 'exits'. If it's turned off, the constructed data gets deallocated automatically when the power drops too low anyway. ;) In other words: Normally main() never exits. At worse maybe structs + alias this + meta programming for e.g. drivers? When you mention drivers, I'm reminded that on some devices, such as the STM32F4xx, we have two types of on-chip SRAM: CCMRAM and normal local SRAM. The CCMRAM is not accessible by the DMA for instance. That means if objects are allocated here, they cannot be accessed by the DMA. In some cases, it would be desirable to 'prefer' allocating in CCMRAM and if absolutely necessary, allocate in the other local SRAM. That means 'new' and 'delete' / 'malloc' and 'free' must be able to handle multiple RAM locations (because there's also external SRAM and external SDRAM).
Re: Startup files for STM32F4xx
On 25/04/2015 7:31 p.m., Jens Bauer wrote: On Saturday, 25 April 2015 at 07:08:26 UTC, Rikki Cattermole wrote: I was referring to package.d files. And publically importing all below modules/packages. Normally, one would want to import only the most necessary parts. Let's take an example: A microcontroller has USB, LCD controller, Ethernet, U(s)ART, SPI, CAN, I2S, I2C and also supports SDRAM. -But the program being developed only needs the LCD controller and the USART, so the Ethernet should not be imported, because if it's seen by the linker, the linker will include it in the final binary. Thus the final binary will be huge, if all of those interfaces are imported. NXP made some #ifdef in their header files and it was terrible working with these. You couldn't build one library, which would work with all your projects, because then you would have a big lump containing everything, including all the stuff you wouldn't need. If you have problems with too large a binaries, in D then it is a bug in the compiler. Never used code, should not hit the linker. Okay okay, it does happen. There is a trick with empty template bracket which allows for this. But it is a work around. I wonder if you can get e.g. interfaces and classes working. I hope I will. ;) I think classes are really a must. The only thing that I (currently) see that could perhaps block this from working, would be missing support for static constructors and a missing memory allocator. The missing memory allocator would be entirely because I would have disabled it; this might be necessary on very small devices (such as 1K RAM devices or worse). Devices that have 64K on-chip memory might be big enough for using new and delete on a regular basis (this is just guesswork). If the programmer is instantiating classes carefully, it should be possible to avoid too many problems. My current startup.d files do not support static constructors. static destructors are obsolete, because a microcontroller never 'exits'. If it's turned off, the constructed data gets deallocated automatically when the power drops too low anyway. ;) In other words: Normally main() never exits. You could definitely allocate the memory during linking. After all e.g. drivers will be singleton right?
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 08:30:10 UTC, Rikki Cattermole
wrote:
On 25/04/2015 7:31 p.m., Jens Bauer wrote:
Normally, one would want to import only the most necessary
parts. Let's take an example: A microcontroller has USB, LCD
controller, Ethernet, U(s)ART, SPI, CAN, I2S, I2C and also
supports SDRAM. -But the program being developed only
needs the LCD controller and the USART, so the Ethernet
should not be imported, because if it's seen by the linker,
the linker will include it in the final binary.
This is because some drivers implement interrupt routines, which
are weak+alias by default and *always* referenced by the
exception vectors.
Thus: In C: If you compile the C file containing the driver, the
symbol will be found, and thus the code will be included in the
final binary.
If you have problems with too large a binaries, in D then it is
a bug in the compiler. Never used code, should not hit the
linker.
Okay okay, it does happen. There is a trick with empty template
bracket which allows for this. But it is a work around.
It *should* happen (in this case).
Consider void ETH_Handler() to be referenced by my exception
vector (which is just an array of function pointers).
If I do not import mcu.stm32f429.ethernet - then I will not get
the driver.
If, however, I do import mcu.stm32f429.ethernet, then the
function 'void ETH_Handler()' will be bulit and the linker will
see it in one of the .o files, and it will include it in the
final binary.
The developer can choose to use his own driver, because he's
clever enough to write a better one than the one supplied by the
vendor in this case. He then implements his own void
ETH_Handler().
My current startup.d files do not support static constructors.
static destructors are obsolete {...} main() never exits.
You could definitely allocate the memory during linking. After
all e.g. drivers will be singleton right?
I think they will; I don't know if it will always be the case,
but I currently can't think of a case where one would allocate a
driver and then deallocate it, unless it's used only once for a
short while.
This would be a rare case, and in such cases, I believe the user
could probably solve it. ;)
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 07:04:58 UTC, Jens Bauer wrote: Things that can be recycled would be carefully written drivers, such as LCD drivers that uses the SPI protocol. The SPI interface itself cannot be recycled, though, as each device has different SPI hardware and different GPIO hardware. You can very well abstract an SPI, just need to have an abstraction for pins. http://developer.mbed.org/handbook/SPI
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 05:07:04 UTC, Jens Bauer wrote: I hope to find a good way to use import for microcontroller libraries, so it'll be easy for everyone. I'm thinking about something like ... import mcu.stm32f439.all I think that belongs in the makefile/dub.json as -version=STM32F439. Then you could simply import mcu.gpio or mcu.spi.
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 05:07:04 UTC, Jens Bauer wrote: While I remember it ... I had to nullify a number of imports in stdint. They simply do not belong in there. :) Eg. I do not want FILE* if I aks for stdint. But FILE* is forced upon me, because wchar_t includes it. What does a wchar_t need a file-system for ? You better dismiss the idea of using druntime/phobos. They are not optimized for code size and contain a lot of stuff that'll never work. You can replace the core.stdc headers with bindings for nanolib, but again it's not necessary for doing useful stuff and should be done later.
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 07:31:45 UTC, Jens Bauer wrote: I wonder if you can get e.g. interfaces and classes working. I hope I will. ;) I think classes are really a must. The only thing that I (currently) see that could perhaps block this from working, would be missing support for static constructors and a missing memory allocator. Static constructors are possible if you strip down ModuleInfo (requires compiler hacking). You should care about that stuff last. It's way more important to make things work without dynamic memory allocation first. You can still malloc+emplace classes later. That means 'new' and 'delete' / 'malloc' and 'free' must be able to handle multiple RAM locations (because there's also external SRAM and external SDRAM). IIRC then the C/C++ malloc would simply can your sbrk implementation, so it only supports a single heap, which should be the external if available.
Re: Startup files for STM32F4xx
Before you start to write device drivers I remind you that it is not possible to just write and read the peripheral registers via pointers. The compiler will do optimizations like omit reads and writes or reorder them. My very simple uart driver is here: https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/tools/main/uart.d?at=default and gpio driver is here: https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/tools/main/gpio.d?at=default My work is based on the feature that a shared variable is marked as volatile in gcc. This feature is buggy and should not be used in the future. The official way is to use library functions to access registers but I think this results to horrible looking code. This issue has currently stopped my work with device drivers. I would like to hear from compiler developers what is the idiomatic D way to do this. Someone might then make an sample driver and after discussion we all could start write drivers the same way.
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 11:56:55 UTC, Martin Nowak wrote: You better dismiss the idea of using druntime/phobos. They are not optimized for code size and contain a lot of stuff that'll never work. You can replace the core.stdc headers with bindings for nanolib, but again it's not necessary for doing useful stuff and should be done later. The minimum runtime I have made does fit in 64k rom/ 64k ram, which all STM32F4 devices have. With some work it may even fit to the smaller memory of STM32F0. I have not yet needed anything from libc/phobos in my programs.
Re: Startup files for STM32F4xx
On Friday, 24 April 2015 at 07:34:55 UTC, tom wrote:
would something like a STM32 NUCLEO-F401RE work?
I forgot to give you a proper answer on this one: I think it
should work, as it's a STM32F401 microcontroller.
-So basically you get a 'bare metal' setup with no drivers.
However, as you know already, you can use STM's drivers, because
D works quite well with C, so you have a fairly good starting
point.
I hope to add more devices later on, and I also hope to add a few
convenience libraries and perhaps some runtime for bare-metal.
I do have some additional files, which I didn't want to put in
the STM32F4xx repository, since they're not directly D-related.
They include a few linker-scripts and a Makefile (but the
Makefile will probably not be to your liking, as it assumes a lot
of things and is not Windows-compatible).
The current linker-scripts can be downloaded here:
d.gpio.dk/dl/linker-scripts.zip
You may want to cripple the following slightly:
__exidx_start = .;
.ARM.exidx :
{
*(.ARM.exidx* .gnu.linkonce.armexidx.*)
} flash
__exidx_end = .;
by changing it to:
__exidx_start = .;
/* .ARM.exidx :*/
/DISCARD/ :
{
*(.ARM.exidx* .gnu.linkonce.armexidx.*)
} flash
__exidx_end = .;
Both Mike and Timo are the true pioneers here; they have done
very valuable hard work. Johannes made it possible to use the
weak, alias and section attributes, so we have the most important
functionality for microcontroller support.
Note: If anyone wants read/write access, please let me know; send
me an email to the domain name, where you replace the first dot
with @
Re: Startup files for STM32F4xx
On 4/23/15 11:30 AM, Jens Bauer wrote: On Thursday, 23 April 2015 at 12:14:59 UTC, Steven Schveighoffer wrote: You can't use something like this? http://www.floodgap.com/software/tenfourfox/ Wow, I thought they stopped making builds at v20! -I'm pretty sure they said on the Web-site that v20 was the last build. But this is great, thank you for letting me know. I've downloaded it (though a bit slow) it appears to work. No problem :) I was a little surprised firefox proper was not continuing to support power pc Mac, but I guess as they upgrade to use new OS UI features, it would drift the codebase apart. In my attempt to make a read-access on my git repositories, I upgraded both Gitolite and git to latest versions; but I still didn't succeed in making it possible to clone without a SSH key. I was hoping that github access would be possible now with a more modern browser, no? The most important thing, though, is that D-programmers now have a starting point for the STM32F4xx. It should be easy to adapt the same sources to other MCUs. I'm planning on adding support for some of the LPC microcontrollers myself. I want to say, I remember Mike's talk last year, and having worked with ST7 micros (small ones, not even close to being supportable by D), I thought it was the coolest thing. I am very excited to see a possibility of using D for embedded programming. This really could be a niche win for D! -Steve
Re: Startup files for STM32F4xx
On Friday, 24 April 2015 at 07:34:55 UTC, tom wrote: On Thursday, 23 April 2015 at 15:30:18 UTC, Jens Bauer wrote: The most important thing, though, is that D-programmers now have a starting point for the STM32F4xx. It should be easy to adapt the same sources to other MCUs. I'm planning on adding support for some of the LPC microcontrollers myself. this looks pretty cool. i would love to try this out (could't figure out how to clone it though) I've made a tar.gz archive and placed it here: d.gpio.dk/dl/STM32F4xx.tar.gz which board do you use? I'm using STM32F407 Discovery board and a bunch of bare-metal boards I designed (most of them are on breadboards) what devices work? Initially, I've only made files for the F4 family: STM32F401, STM32F405, STM32F407, STM32F411, STM32F415, STM32F417, STM32F427, STM32F429, STM32F437 and STM32F439. I only have STM32F407, STM32F427 and STM32F429 myself though, so I will not be able to test on the other devices in this family. would something like a STM32 NUCLEO-F401RE work? You'll need to modify the exception vector table, which should be quite straightfoward (but may take some time, because it's a line-by-line job). But before you start doing a lot of manual work, look at the template files and the generator script. The generator script is actually dong some of the hard work for you. Just list the exception vectors in the correct order in a file called stm32f103.txt for instance, then add this file to the bin/generate and run that scipt.
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 00:33:26 UTC, Steven Schveighoffer wrote: http://www.digikey.com/product-search/en?x=0y=0lang=ensite=uskeywords=stm32f429+discovery This is super tempting @ $24. As someone who is not used to tinkering with raw hardware, how does one power this thing? I've tinkered with SBCs, but those had full-blown Linux. What hardware is necessary to get this thing running? -Steve It's powered from your PC's USB port (Using one right now, actually). No extra hardware is needed unless you want to add features beyond what the board provides. Due to its large number of pins, and the way they are arranged, they don't plug into breadboards, but you can easily use jumper wires for that: https://www.adafruit.com/products/153. I have a basic D demo for this board here: https://github.com/JinShil/stm32f42_discovery_demo. It's just a blinky app at the moment, but it does all the work of configuring the clocks, flash, etc... before calling the main function. There's quite a few Discovery boards from ST (http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/LN1848?icmp=ln1848_pron_pr-stm32f446_dec2014sc=stm32discovery-pr) as well as boards from other manufacturers (http://www.mikroe.com/stm32/development-boards/). It's quite exciting to see Jens's work and the expressed interest in using D for this domain. I hope to see more. Mike
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 00:33:26 UTC, Steven Schveighoffer wrote: On 4/24/15 7:42 PM, Jens Bauer wrote: http://www.digikey.com/product-search/en?x=0y=0lang=ensite=uskeywords=stm32f429+discovery This is super tempting @ $24. As someone who is not used to tinkering with raw hardware, how does one power this thing? Simply via the USB-port on the computer or a 5V USB-plug power supply. :) I've tinkered with SBCs, but those had full-blown Linux. What hardware is necessary to get this thing running? Virtually just the board itself. -The Discovery boards have a built-in ST-Link v2 SWD programmer, so you can use OpenOCD directly with the board. The only thing you need is the USB-to-USB-mini cable, which is something you can get almost everywhere. ... I now succeeded in making a mirror on GitHub: https://github.com/jens-gpio/STM32F4xx (It was absolutely tedious, because the tutorial on GitHub didn't work for me; I haven't yet added automatic mirroring; hopefully I'll be able to figure it out).
Re: Startup files for STM32F4xx
On Friday, 24 April 2015 at 13:12:56 UTC, Jens Bauer wrote: On Friday, 24 April 2015 at 07:34:55 UTC, tom wrote: would something like a STM32 NUCLEO-F401RE work? I forgot to give you a proper answer on this one: I think it should work, as it's a STM32F401 microcontroller. ill order a discover, i have to try this out. http://www.digikey.com/product-detail/en/STM32F4DISCOVERY/497-11455-ND/2711743 this one right?
Re: Startup files for STM32F4xx
On Friday, 24 April 2015 at 22:18:22 UTC, tom wrote: ill order a discover, i have to try this out. http://www.digikey.com/product-detail/en/STM32F4DISCOVERY/497-11455-ND/2711743 this one right? This board will do nicely, but you may want to get a STM32F29 discovery board, because the STM32F429 support higher speeds, has more features, more on-chip SRAM and more freedom. :) LCD/TFT support and Chrom-ART are two of my favorite features. The STM32F429 discovery board has 64MB external SDRAM as well. http://www.digikey.com/product-search/en?x=0y=0lang=ensite=uskeywords=stm32f429+discovery Also available from newark (06X3667) / farnell (2355377) -But the most important thing is that you have a working toolchain. OpenOCD v0.9.0 just went RC1 today, so it's easy for everyone to build it. Freddie Chopin already made a Windows binary (as usual), so if you're using Windows, I recommend getting his binary from ... http://www.freddiechopin.info/en/download/category/10-openocd-dev ... otherwise you'll need to build it from the git repository. I recommend using v0.9.0 over any previous version, because there are several fixes for STM and LPC in v0.9.0 (OpenOCD also works well on big endian hosts now). -So get all the free stuff working before you make a purchase (including the linker scripts). You should be able to use arm-none-eabi-objdump -D for disassembling your .elf file.
Re: Startup files for STM32F4xx
On 4/24/15 7:42 PM, Jens Bauer wrote: On Friday, 24 April 2015 at 22:18:22 UTC, tom wrote: ill order a discover, i have to try this out. http://www.digikey.com/product-detail/en/STM32F4DISCOVERY/497-11455-ND/2711743 this one right? This board will do nicely, but you may want to get a STM32F29 discovery board, because the STM32F429 support higher speeds, has more features, more on-chip SRAM and more freedom. :) LCD/TFT support and Chrom-ART are two of my favorite features. The STM32F429 discovery board has 64MB external SDRAM as well. http://www.digikey.com/product-search/en?x=0y=0lang=ensite=uskeywords=stm32f429+discovery This is super tempting @ $24. As someone who is not used to tinkering with raw hardware, how does one power this thing? I've tinkered with SBCs, but those had full-blown Linux. What hardware is necessary to get this thing running? -Steve
Re: Startup files for STM32F4xx
On Friday, 24 April 2015 at 12:55:46 UTC, Steven Schveighoffer wrote: I was hoping that github access would be possible now with a more modern browser, no? Actually I was getting sleepy and had to do something else the next day, so I couldn't start right away. But I'll have to learn using GitHub - I've never used it before, due to the problems, so I'm a newbie here (feels strange to be a newbie after being a nerd for so long). I'll try and see if I can find out how to mirror my repository and will post a note here if I succeed. :) I want to say, I remember Mike's talk last year, and having worked with ST7 micros (small ones, not even close to being supportable by D), I thought it was the coolest thing. Mike's examples and talk was very inspiring. If he hadn't made these, I would probably not have gotten hungry for starting my D-support on microcontrollers. -But showing that it's basically possible meant a huge difference. I am very excited to see a possibility of using D for embedded programming. This really could be a niche win for D! I couldn't agree more. D has so many advantages over C and C++ on microcontrollers. :) I hope that I can get a low-cost support for associative arrays. When I say low-cost, I mean something like using a minimal malloc/free, in order to reduce the final binary. (I've written a minimal malloc/free/realloc in C already, it's stress-tested and in use in someone else's application at the moment, so it may be ready for porting already)
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 01:06:16 UTC, Mike wrote:
On Saturday, 25 April 2015 at 00:33:26 UTC, Steven
Schveighoffer wrote:
Due to its large number of pins, and the way they are arranged,
they don't plug into breadboards, but you can easily use jumper
wires for that: https://www.adafruit.com/products/153.
If you can 'afford to wait', you can get those for a very low
price on eBay:
http://shop.ebay.com/dupont%20male%20female
-It may take between 5 days and 2 months before they arrive,
depending on which way the wind is blowing... ;)
There's quite a few Discovery boards from ST {snip}
Yes, the STM32F446 is the newest; I really should have mentioned
this board. It's quite a good chip too.
It's quite exciting to see Jens's work and the expressed
interest in using D for this domain. I hope to see more.
This is most likely where the egg cracks open. i'm pretty sure we
willl see people migrating to using D (at first a mixture between
D and C, because of the libraries from the vendors), but later,
there'll surely be projects which are pure D. -After all, it's
not difficult to convert a library file from C to D. :)
I think I just got automatic mirroring working. It seems it's
only a single line in the Gitolite conf. :)
Re: Startup files for STM32F4xx
On 25/04/2015 12:54 p.m., Jens Bauer wrote: ... I now succeeded in making a mirror on GitHub: https://github.com/jens-gpio/STM32F4xx (It was absolutely tedious, because the tutorial on GitHub didn't work for me; I haven't yet added automatic mirroring; hopefully I'll be able to figure it out). Congrats! Also I found this, https://github.com/defunkt/github-gem
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 02:02:35 UTC, Rikki Cattermole wrote: Congrats! Thank you. :) Also I found this, https://github.com/defunkt/github-gem Looks interesting. Maybe this can make things easier. I created a repository for people who work with LPC17xx: https://github.com/jens-gpio/LPC17xx (still no automatic mirroring, though I've installed https://github.com/miracle2k/gitolite-simple-mirror)
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 04:21:06 UTC, Martin Nowak wrote: The STM peripheral library really sux, verbose boilerplate for the simplest stuff and no type safety for the enums (find the difference of GPIO_PIN4 and GPIO_PinSource4 via debugging). I couldn't agree more. I especially hate the fact that pointers have to be type-casted into uint32_t! I know, I know.. It's always 32-bit on the Cortex-M microcontrollers, but ... it would make it easier to make a sandbox application or some test-suite running on a computer, if not having to type-cast everything. It's also really hard to setup all the startup files, linker scripts and debugger configs. In constrast we could provide a really amazing D experience on those platforms. D is really suitable for microcontrollers; especially because classes no longer cost a payload of memory. This will allow us to make neat User-Interface objects easily, where a minimal UI library would be 5K in C++. I also hope that associative arrays and strings will fit most microcontrollers. I know that there might be problems, when we have little RAM available. I do not know how little memory is realistic at the moment; here I'm especially thinking about fragmentation and the use of the 'new' keyword. I hope to find a good way to use import for microcontroller libraries, so it'll be easy for everyone. I'm thinking about something like ... import mcu.stm32f439.all ... and I'm hoping to have this in a shared location instead of including the library in every source file like it's usually done in C and C++ based projects. But I will wait and see what the more experienced D)everlopers recommend. ;) While I remember it ... I had to nullify a number of imports in stdint. They simply do not belong in there. :) Eg. I do not want FILE* if I aks for stdint. But FILE* is forced upon me, because wchar_t includes it. What does a wchar_t need a file-system for ? Things like these might need a slight cleanup at some point (because normally, you don't have a file system on a microcontroller; thus you will get errors, when trying to import a simple file like stdint).
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 01:32:16 UTC, Jens Bauer wrote: This is most likely where the egg cracks open. i'm pretty sure we willl see people migrating to using D (at first a mixture between D and C, because of the libraries from the vendors), but later, there'll surely be projects which are pure D. -After all, it's not difficult to convert a library file from C to D. :) The STM peripheral library really sux, verbose boilerplate for the simplest stuff and no type safety for the enums (find the difference of GPIO_PIN4 and GPIO_PinSource4 via debugging). It's also really hard to setup all the startup files, linker scripts and debugger configs. In constrast we could provide a really amazing D experience on those platforms.
Re: Startup files for STM32F4xx
On 25/04/2015 5:07 p.m., Jens Bauer wrote: On Saturday, 25 April 2015 at 04:21:06 UTC, Martin Nowak wrote: The STM peripheral library really sux, verbose boilerplate for the simplest stuff and no type safety for the enums (find the difference of GPIO_PIN4 and GPIO_PinSource4 via debugging). I couldn't agree more. I especially hate the fact that pointers have to be type-casted into uint32_t! I know, I know.. It's always 32-bit on the Cortex-M microcontrollers, but ... it would make it easier to make a sandbox application or some test-suite running on a computer, if not having to type-cast everything. It's also really hard to setup all the startup files, linker scripts and debugger configs. In constrast we could provide a really amazing D experience on those platforms. D is really suitable for microcontrollers; especially because classes no longer cost a payload of memory. This will allow us to make neat User-Interface objects easily, where a minimal UI library would be 5K in C++. I also hope that associative arrays and strings will fit most microcontrollers. I know that there might be problems, when we have little RAM available. I do not know how little memory is realistic at the moment; here I'm especially thinking about fragmentation and the use of the 'new' keyword. I hope to find a good way to use import for microcontroller libraries, so it'll be easy for everyone. I'm thinking about something like ... import mcu.stm32f439.all Ugh, package.d? ... and I'm hoping to have this in a shared location instead of including the library in every source file like it's usually done in C and C++ based projects. But I will wait and see what the more experienced D)everlopers recommend. ;) While I remember it ... I had to nullify a number of imports in stdint. They simply do not belong in there. :) Eg. I do not want FILE* if I aks for stdint. But FILE* is forced upon me, because wchar_t includes it. What does a wchar_t need a file-system for ? Things like these might need a slight cleanup at some point (because normally, you don't have a file system on a microcontroller; thus you will get errors, when trying to import a simple file like stdint).
Re: Startup files for STM32F4xx
On Thursday, 23 April 2015 at 15:30:18 UTC, Jens Bauer wrote: The most important thing, though, is that D-programmers now have a starting point for the STM32F4xx. It should be easy to adapt the same sources to other MCUs. I'm planning on adding support for some of the LPC microcontrollers myself. this looks pretty cool. i would love to try this out (could't figure out how to clone it though) which board do you use? what devices work? would something like a STM32 NUCLEO-F401RE work?
Re: Startup files for STM32F4xx
On Thursday, 23 April 2015 at 12:14:59 UTC, Steven Schveighoffer wrote: On 4/23/15 5:54 AM, Jens Bauer wrote: :) When having a PowerPC based Mac, you're living in a land of no support. yikes! time for an upgrade :) :) I'm only staying with my PPC Mac for two reasons: My PCB design software and Photoshop CS2. I don't like Photoshop CS3 and later, so I'll need to stick with this. But my plan is to migrate as much as I can to ARM; then I'll be using a Cortex-A desktop computer. -The Firefly with 4GB RAM is close, but I really want a 88SE9230 S-ATA controller from Marvell too. ;) You can't use something like this? http://www.floodgap.com/software/tenfourfox/ Wow, I thought they stopped making builds at v20! -I'm pretty sure they said on the Web-site that v20 was the last build. But this is great, thank you for letting me know. I've downloaded it (though a bit slow) it appears to work. In my attempt to make a read-access on my git repositories, I upgraded both Gitolite and git to latest versions; but I still didn't succeed in making it possible to clone without a SSH key. The most important thing, though, is that D-programmers now have a starting point for the STM32F4xx. It should be easy to adapt the same sources to other MCUs. I'm planning on adding support for some of the LPC microcontrollers myself.
Re: Startup files for STM32F4xx
On Thursday, 23 April 2015 at 04:59:47 UTC, Rikki Cattermole wrote: On 23/04/2015 4:53 p.m., Jens Bauer wrote: On Thursday, 23 April 2015 at 04:48:16 UTC, Rikki Cattermole wrote: Ehh, maybe you should setup a e.g. vm of e.g. Linux Mint and use e.g. Github via it. :) When having a PowerPC based Mac, you're living in a land of no support. I do not know of any VM, which works on Mac OS X PPC. I do have two ARM Cortex-A based boxes. One is a CS918, which I cannot unbrick; the other is a CubieBoard2, which works quite well with Linux, however, ehm, I have no monitor for it, so I'm using it solely via SSH. There's still a slim chance that I can get GitHub working, because I had to use their API, in order to register; perhaps the API will let me create mirrors, etc. (As you can probably imagine, I was very happy, when I got the D compiler building for my Mac) Setting up the git server for HTTP does not seem too difficult after all, though: http://gitolite.com/gitolite/ssh-and-http.html
Re: Startup files for STM32F4xx
On 23/04/2015 9:54 p.m., Jens Bauer wrote: On Thursday, 23 April 2015 at 04:59:47 UTC, Rikki Cattermole wrote: On 23/04/2015 4:53 p.m., Jens Bauer wrote: On Thursday, 23 April 2015 at 04:48:16 UTC, Rikki Cattermole wrote: Ehh, maybe you should setup a e.g. vm of e.g. Linux Mint and use e.g. Github via it. :) When having a PowerPC based Mac, you're living in a land of no support. I do not know of any VM, which works on Mac OS X PPC. I do have two ARM Cortex-A based boxes. One is a CS918, which I cannot unbrick; the other is a CubieBoard2, which works quite well with Linux, however, ehm, I have no monitor for it, so I'm using it solely via SSH. There's still a slim chance that I can get GitHub working, because I had to use their API, in order to register; perhaps the API will let me create mirrors, etc. (As you can probably imagine, I was very happy, when I got the D compiler building for my Mac) Setting up the git server for HTTP does not seem too difficult after all, though: http://gitolite.com/gitolite/ssh-and-http.html Wow impressive, no full x86 machine!
Re: Startup files for STM32F4xx
On 4/23/15 5:54 AM, Jens Bauer wrote: On Thursday, 23 April 2015 at 04:59:47 UTC, Rikki Cattermole wrote: On 23/04/2015 4:53 p.m., Jens Bauer wrote: On Thursday, 23 April 2015 at 04:48:16 UTC, Rikki Cattermole wrote: Ehh, maybe you should setup a e.g. vm of e.g. Linux Mint and use e.g. Github via it. :) When having a PowerPC based Mac, you're living in a land of no support. yikes! time for an upgrade :) You can't use something like this? http://www.floodgap.com/software/tenfourfox/ -Steve
Startup files for STM32F4xx
I've now created a few startup files for the STM32F4xx microcontrollers. You can grab them here ... http://d.gpio.dk/cgi-bin/gitweb.cgi ... Unfortunately I have no 'read-only' checkout on my git-server, but I'll be happy to make a tar.bz2 archive upon request.
Re: Startup files for STM32F4xx
On Thursday, 23 April 2015 at 04:48:16 UTC, Rikki Cattermole wrote: On 23/04/2015 2:41 p.m., Jens Bauer wrote: ... Unfortunately I have no 'read-only' checkout on my git-server, but I'll be happy to make a tar.bz2 archive upon request. Make a github mirror if you don't want to push it directly there. That might work. I had to create my own git server, because GitHub does not work with any of my Web-browsers. -The only thing I can do with a Web-browser is to fork another repository and post comments. This is basically because GitHub's buttons do not work on my browsers. I'll try and make an attempt to set up a mirror tomorrow, but it might be easier setting up gitolite with HTTP anyway. ;)
Re: Startup files for STM32F4xx
On 23/04/2015 4:53 p.m., Jens Bauer wrote: On Thursday, 23 April 2015 at 04:48:16 UTC, Rikki Cattermole wrote: On 23/04/2015 2:41 p.m., Jens Bauer wrote: ... Unfortunately I have no 'read-only' checkout on my git-server, but I'll be happy to make a tar.bz2 archive upon request. Make a github mirror if you don't want to push it directly there. That might work. I had to create my own git server, because GitHub does not work with any of my Web-browsers. -The only thing I can do with a Web-browser is to fork another repository and post comments. This is basically because GitHub's buttons do not work on my browsers. I'll try and make an attempt to set up a mirror tomorrow, but it might be easier setting up gitolite with HTTP anyway. ;) Ehh, maybe you should setup a e.g. vm of e.g. Linux Mint and use e.g. Github via it. After all, not having a web browser working for it isn't an excuse when all the main ones do ;)
Re: Startup files for STM32F4xx
On 23/04/2015 2:41 p.m., Jens Bauer wrote: I've now created a few startup files for the STM32F4xx microcontrollers. You can grab them here ... http://d.gpio.dk/cgi-bin/gitweb.cgi ... Unfortunately I have no 'read-only' checkout on my git-server, but I'll be happy to make a tar.bz2 archive upon request. Make a github mirror if you don't want to push it directly there.
