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
Am Sun, 26 Apr 2015 00:14:42 +
schrieb Mike n...@none.com:
Usage:
auto b = PORTB.load();
PORTB.toggle!PIN0;
PORTB.PIN0 = Level.low;
writeln(PORTB.PIN0);
PORTB.TEST = 0b000;
That's some nice code! and really leveraging D to great effect.
I know that
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 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
Am Sat, 25 Apr 2015 11:38:45 +
schrieb Martin Nowak c...@dawg.eu:
On Saturday, 25 April 2015 at 05:07:04 UTC, Jens Bauer wrote:
I hope to find a good way to use import for microcontroller
libraries, so it'll be easy for everyone. I'm thinking about
something like ...
import
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
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:
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
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
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:
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
On Saturday, 25 April 2015 at 17:11:22 UTC, Johannes Pfau wrote:
Am Sat, 25 Apr 2015 11:38:45 +
schrieb Martin Nowak c...@dawg.eu:
On Saturday, 25 April 2015 at 05:07:04 UTC, Jens Bauer wrote:
import mcu.stm32f439.all
I think that belongs in the makefile/dub.json as
-version=STM32F439.
Am Sat, 25 Apr 2015 18:31:45 +
schrieb Jens Bauer doc...@who.no:
On Saturday, 25 April 2015 at 17:58:59 UTC, Timo Sintonen wrote:
On Saturday, 25 April 2015 at 17:04:18 UTC, Jens Bauer wrote:
I think volatileLoad and volatileStore are intended for this
(please correct me if my
On Saturday, 25 April 2015 at 19:33:05 UTC, Johannes Pfau wrote:
Am Sat, 25 Apr 2015 18:31:45 +
schrieb Jens Bauer doc...@who.no:
I don't want to start another volatile discussion, but to me
it seems an attribute would not be a bad idea.
-And for completeness... read-only, write-only,
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
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
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.
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
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,
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
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 ...
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,
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
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
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
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
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
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
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 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
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
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
On Saturday, 25 April 2015 at 00:33:26 UTC, Steven Schveighoffer
wrote:
http://www.digikey.com/product-search/en?x=0y=0lang=ensite=uskeywords=stm32f429+discovery
This is super tempting @ $24. As someone who is not used to
tinkering with raw hardware, how does one power this thing?
I've
On Saturday, 25 April 2015 at 00:33:26 UTC, Steven Schveighoffer
wrote:
On 4/24/15 7:42 PM, Jens Bauer wrote:
http://www.digikey.com/product-search/en?x=0y=0lang=ensite=uskeywords=stm32f429+discovery
This is super tempting @ $24. As someone who is not used to
tinkering with raw hardware,
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
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
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
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
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:
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).
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:
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
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
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
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
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
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
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.
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
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.
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
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
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
54 matches
Mail list logo
