On Wednesday, 16 December 2020 at 11:51:52 UTC, Severin Teona
wrote:
Hi again guys!
I have been trying to develop a small-sized DRuntime for
microcontrollers during SAoC2020. My last update is here[1]. At
the moment, I have managed to build a DRuntime that can be
linked with a simple
On Wednesday, 8 April 2020 at 15:52:59 UTC, Severin Teona wrote:
Hello,
I am working with a NUCLEO_f429zi board, architecure ARMv7e-m
and cortex-m4 CPU. I want to cross-compile D code for it from
Ubuntu 18.04 LTS Server. My current GCC version is 9.
How can I do that? What is the best
On Thursday, 1 August 2019 at 03:04:27 UTC, Paul wrote:
I'm trying to build a Bare Bones 'OS' via example. Example
says to compile with
"gdc -c kernel.main.d -o kernel.main.o -g" I'm having trouble
getting GDC all set up..as I'm a rank amateur. So, I tried
compiling the example below with
On Wednesday, 6 December 2017 at 17:17:40 UTC, Luís Marques wrote:
Is there a small druntime/object.d implementation that allows
basic support for classes, without bringing the whole druntime
implementation with it?
https://bitbucket.org/timosi/minlibd
This is mainly targeted to
On Monday, 9 November 2015 at 20:24:05 UTC, Taylor Hillegeist
wrote:
On Monday, 9 November 2015 at 20:09:05 UTC, Timo Sintonen wrote:
On Monday, 9 November 2015 at 19:00:32 UTC, Taylor Hillegeist
wrote:
Maybe I am wrong, But I believe that the low level community
is awaiting the release of
On Monday, 9 November 2015 at 11:39:16 UTC, Kagamin wrote:
On Monday, 9 November 2015 at 10:14:17 UTC, Timo Sintonen wrote:
There are some register definitions but it is far from
complete.
Suggestions and contributions are welcome.
On Monday, 9 November 2015 at 19:00:32 UTC, Taylor Hillegeist
wrote:
Maybe I am wrong, But I believe that the low level community is
awaiting the release of GDC/LDC compatible with 2.067 DMD front
end. This will allow for volatile store/load. and hopefully
begin a new era of D micro
On Monday, 9 November 2015 at 08:49:57 UTC, Andrey wrote:
On Monday, 9 November 2015 at 08:35:01 UTC, Kagamin wrote:
https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study like
this?
Yes. But I mean the real supported library, with header files,
registers declarations and so on... That is
On Friday, 6 November 2015 at 16:21:35 UTC, Suliman wrote:
On Friday, 6 November 2015 at 13:50:56 UTC, Kagamin wrote:
MSVCR is a C runtime. On Linux it will depend on a C runtime
too.
But which part of my App depend on C runtime?
I have an early draft to explain the libraries here:
On Saturday, 2 May 2015 at 02:08:40 UTC, Mike wrote:
I'm totally with you on this. I don't want a better C or a
worse D. I hope that programming in D on these
microcontrollers looks very much like the idomatic D in other
domains. I want dyanamic memory allocation to be available for
sure,
On Saturday, 2 May 2015 at 04:53:51 UTC, Jens Bauer wrote:
The problem I've seen with most C-solutions, is that once
someone uses printf, the binary suddenly grows out of
proportions. (It may be because the programmer included a line
for debugging only, and that causes the otherwise 1K
On Saturday, 2 May 2015 at 09:09:44 UTC, Martin Nowak wrote:
On Saturday, 2 May 2015 at 08:46:56 UTC, Timo Sintonen wrote:
Std.format, as suggested, would be too big. I tis easty to
copy the printf formatter from libc sources. Or just write an
own.
No need to rewrite libc, just link against
On Thursday, 30 April 2015 at 20:54:07 UTC, Martin Nowak wrote:
On 04/30/2015 08:43 AM, Timo Sintonen wrote:
Printf is a little tricky. It is actually a file operation to
stdout and
that is actually a syscall to kernel.
No, you usually have to implement some hook for outputting
yourself,
On Thursday, 30 April 2015 at 11:30:33 UTC, Mike wrote:
Starting from zero appeals to my way of thinking. I've made
several attempts at this both on the PC and for
microcontrollers, so please allow me to offer my thoughts on
the idea:
While this may seem simple to achieve, I think it
On Thursday, 30 April 2015 at 23:49:52 UTC, Jens Bauer wrote:
Most asserts on microcontrollers I've seen are just implemented
as while(1){}
-But one could probably also trigger the debugger (BKPT),
HardFault or RESET if necessary.
Perhaps the default could be while(1){} and then
On Thursday, 30 April 2015 at 23:59:18 UTC, Jens Bauer wrote:
On Thursday, 30 April 2015 at 21:35:44 UTC, Mike wrote:
On Thursday, 30 April 2015 at 21:08:22 UTC, Jens Bauer wrote:
Thus I would expect the hook to be somewhere in vfprintf ?
As Timo said, eventually, what printf needs is the
On Thursday, 30 April 2015 at 00:14:18 UTC, Martin Nowak wrote:
Wonder if it makes more sense to start from zero and add as few
files as
possible.
When I started I did not know D enough to understand what
druntime does. Just picked the easy way. The amount of required
changes has got
On Monday, 27 April 2015 at 10:46:09 UTC, Jens Bauer wrote:
On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
I have also tried for years to build a working multilib
without success. {snip}
Please note: This is the first time ever I have suceeded. This
will not work with any
On Monday, 27 April 2015 at 07:34:52 UTC, Mike wrote:
On Monday, 27 April 2015 at 05:22:55 UTC, Timo Sintonen wrote:
On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
Oops, I forget to uncomment the m4 options. The correct
version is
And I replace the whole
On Monday, 27 April 2015 at 07:55:10 UTC, Martin Nowak wrote:
Great, I tried to find out how GDC binaries are build, but
couldn't find any script.
Instructions here:
http://wiki.dlang.org/GDC/Cross_Compiler/Generic
or here:
https://bitbucket.org/timosi/minlibd/wiki/gdc_cross_compiler
There
On Tuesday, 28 April 2015 at 02:11:06 UTC, Jens Bauer wrote:
On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
The build script:
../gcc/configure --disable-bootstrap \
--enable-languages=c,d --disable-nls --target=arm-eabi \
--without-headers --with-newlib --without-isl
On Tuesday, 28 April 2015 at 02:18:29 UTC, Mike wrote:
On Tuesday, 28 April 2015 at 02:12:11 UTC, Jens Bauer wrote:
On Tuesday, 28 April 2015 at 00:34:42 UTC, Mike wrote:
Given the other replies in this thread, this looks promising.
However, I went to give it a test today, and found out my
On Monday, 27 April 2015 at 07:34:52 UTC, Mike wrote:
The toolchain at https://launchpad.net/gcc-arm-embedded doesn't
require this modification, so I'm wondering if there's another
way. My understanding is that this is unlreated to GDC itself,
so we should be able to follow essentially the
On Sunday, 26 April 2015 at 18:23:47 UTC, Martin Nowak wrote:
The wiki says to disable multilib
(http://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler#Build_GCC),
what's the problem? Maybe ask Iain/Johannes if it's GDC
specific.
I have also tried for years to build a working
On Sunday, 26 April 2015 at 16:09:57 UTC, Martin Nowak wrote:
Nice, minilibd seems to be maintained as well, you happen to
know the
author?
I am the author of minlibd
I'd really like to see binary releases of GDC for arm-none-eabi
that
ship with a patched compiler (iff necessary) and
On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
Oops, I forget to uncomment the m4 options. The correct version is
And I replace the whole gcc/config/arm/t-arm-elf with this:
MULTILIB_OPTIONS +=
mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
mfloat-abi=hard mfpu=fpv4-sp-d16
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
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
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:
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
On Monday, 2 February 2015 at 16:55:59 UTC, Andrei Alexandrescu
wrote:
I think it's time to reopen that negotiation.
+1
So does the argument boil down to better inlining control and
enforcement? -- Andrei
If we reopen this I think we should start at the beginning and
not yet concentrate
On Sunday, 1 February 2015 at 06:37:27 UTC, Walter Bright wrote:
On 1/31/2015 9:21 PM, Mike wrote:
Is D's core team genuinely interested in this domain?
Yes.
If you are genuinely interested, are you committed? And if
so, what direction
would you like to take? So far, my ideas have been
On Sunday, 1 February 2015 at 15:28:25 UTC, Andrei Alexandrescu
wrote:
On 2/1/15 1:38 AM, Timo Sintonen wrote:
The one of major issues is: how to access hardware. We need a
language
feature to access hardware registers.
What features do Rust and Nim provide for such?
Andrei
I was not the
On Friday, 16 January 2015 at 10:04:55 UTC, Jens Bauer wrote:
Has anyone used newlib with a Cortex-M based GDC toolchain ?
As Mike pointed out, my minlibd project is a good starting point.
It contains a fully functional example for stm32f4
Build failed on final gcc.
I normally use newlib
34 matches
Mail list logo
