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. ;)

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

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.

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.

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.

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.

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.

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. ;)

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. ;)

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)