www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Startup files for STM32F4xx

reply "Jens Bauer" <doctor who.no> writes:
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.
Apr 22 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Apr 22 2015
parent reply "Jens Bauer" <doctor who.no> writes:
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. ;)
Apr 22 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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 ;)
Apr 22 2015
parent reply "Jens Bauer" <doctor who.no> writes:
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
Apr 23 2015
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
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!
Apr 23 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Apr 23 2015
parent reply "Jens Bauer" <doctor who.no> writes:
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.
Apr 23 2015
next sibling parent reply "tom" <tom srtnwz.com> writes:
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?
Apr 24 2015
next sibling parent "Jens Bauer" <doctor who.no> writes:
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.
Apr 24 2015
prev sibling parent reply "Jens Bauer" <doctor who.no> writes:
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
Apr 24 2015
parent reply "tom" <tom srtnwz.com> writes:
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?
Apr 24 2015
next sibling parent reply "Jens Bauer" <doctor who.no> writes:
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=0&y=0&lang=en&site=us&keywords=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.
Apr 24 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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=0&y=0&lang=en&site=us&keywords=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
Apr 24 2015
next sibling parent reply "Jens Bauer" <doctor who.no> writes:
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=0&y=0&lang=en&site=us&keywords=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).
Apr 24 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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
Apr 24 2015
parent reply "Jens Bauer" <doctor who.no> writes:
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)
Apr 24 2015
parent reply "tom" <tom srtnwz.com> writes:
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.
Apr 24 2015
parent "Jens Bauer" <doctor who.no> writes:
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.
Apr 24 2015
prev sibling parent reply "Mike" <none none.com> writes:
On Saturday, 25 April 2015 at 00:33:26 UTC, Steven Schveighoffer 
wrote:

 http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&keywords=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_dec2014&s =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
Apr 24 2015
parent reply "Jens Bauer" <doctor who.no> writes:
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. :)
Apr 24 2015
parent reply "Martin Nowak" <code dawg.eu> writes:
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.
Apr 24 2015
parent reply "Jens Bauer" <doctor who.no> writes:
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).
Apr 24 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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).
Apr 24 2015
parent reply "Jens Bauer" <doctor who.no> writes:
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.
Apr 25 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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?
Apr 25 2015
parent reply "Jens Bauer" <doctor who.no> writes:
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).
Apr 25 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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?
Apr 25 2015
parent reply "Jens Bauer" <doctor who.no> writes:
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. ;)
Apr 25 2015
parent reply "Timo Sintonen" <t.sintonen luukku.com> writes:
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.
Apr 25 2015
parent reply "Jens Bauer" <doctor who.no> writes:
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. ;)
Apr 25 2015
parent reply "Timo Sintonen" <t.sintonen luukku.com> writes:
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.
Apr 25 2015
parent reply "Jens Bauer" <doctor who.no> writes:
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.
Apr 25 2015
parent reply Johannes Pfau <nospam example.com> writes:
Am Sat, 25 Apr 2015 18:31:45 +0000
schrieb "Jens Bauer" <doctor 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)
Apr 25 2015
next sibling parent "Jens Bauer" <doctor who.no> writes:
On Saturday, 25 April 2015 at 19:33:05 UTC, Johannes Pfau wrote:
 Am Sat, 25 Apr 2015 18:31:45 +0000
 schrieb "Jens Bauer" <doctor 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. ;)
Apr 25 2015
prev sibling parent reply "Mike" <none none.com> writes:
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
Apr 25 2015
parent Johannes Pfau <nospam example.com> writes:
Am Sun, 26 Apr 2015 00:14:42 +0000
schrieb "Mike" <none 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
Apr 26 2015
prev sibling parent reply "Martin Nowak" <code dawg.eu> writes:
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.
Apr 25 2015
parent "Jens Bauer" <doctor who.no> writes:
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).
Apr 25 2015
prev sibling parent reply "Martin Nowak" <code dawg.eu> writes:
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
Apr 25 2015
parent "Jens Bauer" <doctor who.no> writes:
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. ;)
Apr 25 2015
prev sibling next sibling parent reply "Martin Nowak" <code dawg.eu> writes:
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.
Apr 25 2015
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Sat, 25 Apr 2015 11:38:45 +0000
schrieb "Martin Nowak" <code 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
Apr 25 2015
parent "Jens Bauer" <doctor who.no> writes:
On Saturday, 25 April 2015 at 17:11:22 UTC, Johannes Pfau wrote:
 Am Sat, 25 Apr 2015 11:38:45 +0000
 schrieb "Martin Nowak" <code 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!).
Apr 25 2015
prev sibling parent "Jens Bauer" <doctor who.no> writes:
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.
Apr 25 2015
prev sibling parent reply "Martin Nowak" <code dawg.eu> writes:
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.
Apr 25 2015
parent reply "Timo Sintonen" <t.sintonen luukku.com> writes:
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.
Apr 25 2015
next sibling parent "Jens Bauer" <doctor who.no> writes:
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)
Apr 25 2015
prev sibling parent reply "Mike" <none none.com> writes:
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
Apr 25 2015
parent reply "Timo Sintonen" <t.sintonen luukku.com> writes:
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.
Apr 25 2015
parent Brad Roberts via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
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.
Apr 25 2015
prev sibling parent "Jens Bauer" <doctor who.no> writes:
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 ? :)
May 01 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Apr 24 2015
parent "Jens Bauer" <doctor who.no> writes:
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)
Apr 24 2015