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)

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.

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

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

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.

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.

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.

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?

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

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?