Stephen Leake wrote:
> Which raises the question; why insist on "bareboard", instead of a
> well supported OS that does what you need?
Because it is hard to find a well supported OS that does what you need?
We are using Linux on ARM underneath an application we are developing at
the moment, but I'm a bit worried about the timing properties of having
a full OS running. We may end up solving the problem by having a
hardware or a kernel-space clock triggering the microcontrollers running
the jitter-sensitive parts of the application. This way we may miss
some measurements, but those we get will be from well-defined times.
In many cases this kind of work-around can be an easier solution than
attempting to create a full/Ravenscar run-time and the drivers required
for an application.
Greetings,
Jacob
-- No trees were killed in the sending of this message.
However a large number of electrons were terribly inconvenienced.
Brian Drummond wrote:
> Yes. Bare metal programming on a Z80 is easy. Ditto PIC, AVR, etc etc,
> and of these only the AVR has an Ada toolchain. It may not be mature
> but it is very usable.
It would be easier to promote, if we could point people to an
easy-to-install IDE, where the less command-line-habituated users could
click and select their way to selecting boards, compiling applications,
and installing them on the boards. It is my impression that GPS and
GNAT AVR are pretty close to this for Microsoft Windows. For Unix there
is still a bit more work to do.
> Or me, unless I get a job offer soon...
I hope you'll get a good offer soon. (Even if more Ada compiler targets
is a good thing.)
> I think with ARM and AVR covered, Ada should be in a better place than
> it is. But even in the Arduino community, AVR-Ada goes almost
> unnoticed. So part of the problem is publicity and exposure, and
> those need not be expensive to address.
I see the two challenges for Ada in the Arduino community as:
1) Not being integrated in the Arduino IDE.
2) Not having a book about Arduino development with Ada.
I'm not sure how hard it would be to integrate Ada in the Arduino IDE
compared with making and packaging an AVR-aware GPS for the same
operating systems as the Arduino IDE is available for.
Once people are on the hook, I think an AVR-aware GPS is the better
tool, but newcomers to Arduino are more likely to download the Arduino
IDE, so from a recruiting point of view, I think it might be worth the
work to make the Arduino IDE Ada-aware.
Greetings,
Jacob
-- "Banning open source would have immediate, broad, and
strongly negative impacts on the ability of many sensitive
and security-focused DOD groups to protect themselves
against cyberattacks" -- Mitre Corp.
Jacob Sparre Andersen wrote:
> It would be easier to promote, if we could point people to an
> easy-to-install IDE, where the less command-line-habituated users could
> click and select their way to selecting boards, compiling applications,
> and installing them on the boards. It is my impression that GPS and
> GNAT AVR are pretty close to this for Microsoft Windows.
You are right, Jacob. I use GNAT AVR on Windows, it's pretty easy to install.
> > I think with ARM and AVR covered, Ada should be in a better place than
> > it is. But even in the Arduino community, AVR-Ada goes almost
> > unnoticed. So part of the problem is publicity and exposure, and
> > those need not be expensive to address.
I guess AVR-Ada is more likely to the Ada community than to the Arduino community. Mainly because many of the Arduino guys are not yet software guys, and Arduino IDE is very intuitive to the ones who never programmed anything. In AVR-Ada you have to build much thing before starting to program the chip. And at first they are just concerned in moving a stepper motor, blinking a led, transmitting some bits; at first they just don't need reliability, safety, strong typing, ... . This is necessary (to these guys) just when they leave the "Arduino paradigm", and go to the "AVR paradigm". Actually now we do not program Arduinos in Ada, we program AVRs; with Arduino IDE, we really program Arduinos, because of the IDE is dependent not to the chip, but to the board.
> I see the two challenges for Ada in the Arduino community as:
> 1) Not being integrated in the Arduino IDE.
Arduino IDE gets the most part of Arduino community. I think Ada [GNAT AVR]-based concurs more with Atmel Studio (which is Visual Studio + Atmel libraries). Even with Ada integrated on Arduino IDE, I would prefer continuing to use GNAT AVR + GPS GPL, but certainly having Arduino IDE with Ada would help to bring part of Arduino community guys to the Ada community.
> 2) Not having a book about Arduino development with Ada.
Yes. I agree. I've been teaching and encouraging much as I can some students and friends to use Ada for the Arduino projects. But the path has been always the same, teach basic Ada, teach Arduino/Arduino IDE/Atmel Studio, teach Ada on AVR, use it now. A book like this is a very good idea.
> I'm not sure how hard it would be to integrate Ada in the Arduino IDE
> compared with making and packaging an AVR-aware GPS for the same
> operating systems as the Arduino IDE is available for.
> Once people are on the hook, I think an AVR-aware GPS is the better
> tool, but newcomers to Arduino are more likely to download the Arduino
> IDE, so from a recruiting point of view, I think it might be worth the
> work to make the Arduino IDE Ada-aware.
I totally agree. I would love to see more Arduino people beginning to program using Ada.
On Thu, 08 Nov 2012 13:36:27 +0400, Jacob Sparre Andersen wrote:
> Brian Drummond wrote:
>> ... the AVR has an Ada toolchain. It may not be mature but it is very
>> usable.
> It would be easier to promote, if we could point people to an
> easy-to-install IDE, where the less command-line-habituated users could
> click and select...
On Unix, even having pre-built binaries rather than building gcc from
source would be a big step in the right direction.
Integrating into an IDE ...
I kept trying with Eclipse (Hibachi and an old-ish Gnatbench) and failing,
a couple of years ago. I don't know if Eclipse has improved any?
There's GPS but I don't know how to set it up for AVR as opposed to
native.
Any other candidates?
>> Or me, unless I get a job offer soon...
> I hope you'll get a good offer soon. (Even if more Ada compiler targets
> is a good thing.)
Hasn't happened yet...
> I see the two challenges for Ada in the Arduino community as:
> 1) Not being integrated in the Arduino IDE.
I agree with you about this one, though the maker community is a bit
bigger than just Arduino users... I may have to take a look at it to see
if there is any way to convince it to speak another language...
> 2) Not having a book about Arduino development with Ada.
My wife is the ML looking after NanoWrimo participants in rural Scotland and she's sometimes hard to ignore. Nevertheless I am making no promises
whatsoever...
> Brian Drummond wrote:
> Yes. Bare metal programming on a Z80 is easy. Ditto PIC, AVR, etc etc,
> and of these only the AVR has an Ada toolchain. It may not be mature
> but it is very usable.
That's not quite true, in that there surely exists a Z80 toolchain (early Janus/Ada) - it just hasn't been updated or supported in more than a decade and it only runs on CP/M. I suppose it might run on some emulator. (Another issue is that I don't think the binary exists on anything other than 8" floppy disks, which might be hard to read today.)
On Thu, 08 Nov 2012 19:24:36 -0600, Randy Brukardt wrote:
>> Brian Drummond wrote:
>> Yes. Bare metal programming on a Z80 is easy. Ditto PIC, AVR, etc etc,
>> and of these only the AVR has an Ada toolchain. It may not be mature
>> but it is very usable.
> That's not quite true, in that there surely exists a Z80 toolchain
> (early Janus/Ada) - it just hasn't been updated or supported in more
> than a decade and it only runs on CP/M. I suppose it might run on some
> emulator. (Another issue is that I don't think the binary exists on
> anything other than 8" floppy disks, which might be hard to read today.)
Depends how you parse "of these" - I did mean "of these latter" when I wrote it, having drooled over the Grey Matter catalogue in my younger days. If the source exists in any modern form, it can probably be compiled on a Z80-CP/M emulator. I would offer to help convert the floppies, but I abandoned a very nice CP/M system in a loft several house moves ago.
I kept a box of 8" floppies though, mostly to see the look on people's faces when they asked to borrow a floppy, and I said "help yourself"!
In any case, there is now an executable claiming to be an Ada compiler for the TI MSP430. Currently it just says "cannot locate system.ads" and falls over, but you have to start somewhere. Now I have to write a system.ads, and (probably more complicated) figure out where to put it...
>> Which raises the question; why insist on "bareboard", instead of a
>> well supported OS that does what you need?
> Because it is hard to find a well supported OS that does what you need?
> We are using Linux on ARM underneath an application we are developing at
> the moment, but I'm a bit worried about the timing properties of having
> a full OS running.
Linux is certainly not suitable for hard realtime. Use VxWorks or Lynx.
On Fri, 09 Nov 2012 07:29:54 -0500, Stephen Leake wrote:
> Jacob Sparre Andersen <spa...@nbi.dk> writes:
>> Stephen Leake wrote:
>>> Which raises the question; why insist on "bareboard", instead of a
>>> well supported OS that does what you need?
>> Because it is hard to find a well supported OS that does what you need?
>> We are using Linux on ARM underneath an application we are developing at
>> the moment, but I'm a bit worried about the timing properties of having
>> a full OS running.
> Linux is certainly not suitable for hard realtime. Use VxWorks or Lynx.
What in your opinion makes VxWorks more suitable? Except that you could
have your own scheduler there is little advantages over Linux. Monolithic
kernel? VxWorks is slightly faster. But as for hard real-time, it depends
on the definition of. With its miserable RT clock support VxWorks is barely
usable for things I do. (This is going to change with the coming version,
AFAIK)
>> That's not quite true, in that there surely exists a Z80 toolchain
>> (early Janus/Ada) - it just hasn't been updated or supported in more
>> than a decade and it only runs on CP/M. I suppose it might run on some
>> emulator. (Another issue is that I don't think the binary exists on
>> anything other than 8" floppy disks, which might be hard to read today.)
> Depends how you parse "of these" - I did mean "of these latter" when I
> wrote it, having drooled over the Grey Matter catalogue in my younger
> days. If the source exists in any modern form, it can probably be
> compiled on a Z80-CP/M emulator. I would offer to help convert the
> floppies, but I abandoned a very nice CP/M system in a loft several house
> moves ago.
I did find part of the source on some ancient 5 1/4" floppies. One disk wasn't readable, unfortunately, and I had tossed the redundant backups in one of our previous moves (I had always keep two copies of every master floppy, but decided to save on space by getting rid of the extra ones). I did retrieve the backend and runtime library, and put those into our version control. I always figured it would make more sense to tie those to a modern front-end rather than try to get the 1985 version running, so they were my primary target anyway.
The 8" floppy versions probably are worthless; I still have one set of 8" floppy drives and our "best" Z-80 computer, but the last time I tried that I couldn't get it to boot -- probably corroded somewhere from sitting around in basements. And I'm sure its in worse shape now (10 or so years later).
I've got the compiler on various weird 5 1/4" formats (like the Apple II CP/M), but probably nothing that a PC could read. If there was enough interest, I dig out all of the disks that we have and see if I can read any of the binaries. Might have to find a CP/M floppy reading program (I expect it exists).
Anyway, if someone is seriously interested, they ought to contact me and I can try to figure out how much work it would be to get it to run and/or find the binary.
> On Sat, 10 Nov 2012 02:05:23 -0600, "Randy Brukardt"
> <ra...@rrsoftware.com> declaimed the following in comp.lang.ada:
>> The 8" floppy versions probably are worthless; I still have one set of 8"
>> floppy drives and our "best" Z-80 computer, but the last time I tried >> that I
>> couldn't get it to boot -- probably corroded somewhere from sitting >> around
>> in basements. And I'm sure its in worse shape now (10 or so years later).
> I'm afraid to look into my old systems... I suspect the R/W head on
> the floppy drive will snap right off if I power up my TRS-80 Model III/4
> (the one with the whopping 128kB of bank-swapped RAM <G>). My Amiga
> A-1000 and A-2000 are probably not much better.
>> I've got the compiler on various weird 5 1/4" formats (like the Apple II
>> CP/M), but probably nothing that a PC could read. If there was enough
>> interest, I dig out all of the disks that we have and see if I can read >> any
>> of the binaries. Might have to find a CP/M floppy reading program (I >> expect
>> it exists).
> Heh... The one place the Amiga was great. Since it did "whole track"
> I/O, rigging it for alternate file systems was strictly software
> decoding. Though I don't have a 5.25" drive for it -- I did have
> CrossDOS to read MS-DOS, and I think CP/M format floppies.
That was true of almost all 5.25" drives, including those in the early IBM PC's. We had a program that wrote some 200 different CP/M 5.25" disk formats. (Why there were so many never made much sense.) I know we sold compilers on many of those formats.
[I wrote such a program in my early days; programming the disk controller chip was relatively easy and the most important thing was making sure that the data got dumped to the controller fast enough.]
However, the Apple II with its variable speed drive motor was not one of those. The only way to copy disks for an Apple II was to use an Apple II. (We used a friend's Apple II; we had to buy him a new disk drive after wearing out one copying a thousand or so disks.) Probably someone did that commercially, and that would have made more sense if we hadfound them, but that was nearly impossible in those pre-Internet days -- you never found out about anything unless you saw an article or ad about something.
On Thu, 08 Nov 2012 12:07:34 +0400
Jacob Sparre Andersen <spa...@nbi.dk> wrote:
> Stephen Leake wrote:
> > Which raises the question; why insist on "bareboard", instead of a
> > well supported OS that does what you need?
> Because it is hard to find a well supported OS that does what you need?
> We are using Linux on ARM underneath an application we are developing at
> the moment, but I'm a bit worried about the timing properties of having
> a full OS running. We may end up solving the problem by having a
> hardware or a kernel-space clock triggering the microcontrollers running
> the jitter-sensitive parts of the application. This way we may miss
> some measurements, but those we get will be from well-defined times.
If you don't need accurate real-time properties, Linux+Ada on ARM
is the easiest and the cheapest way to run Ada on ARM device.
Cheapest ARM boards capable of running Linux(Debian) are something like
24 euros[1], about same as Arduinos and cheaper than Raspberry Pi.
About a year ago I asked from AdaCore how much it would cost
to have GNAT Pro (1y subscription) for bareboard ARM microcontroller
board (cortex-m3). As you can probably guess, the price was high,
which led me to port GNAT to Debian/armhf myself[2]. But at least now,
they (AdaCore) cannot say there has been no demand for ARM. ;)
> About a year ago I asked from AdaCore how much it would cost
> to have GNAT Pro (1y subscription) for bareboard ARM microcontroller
> board (cortex-m3). As you can probably guess, the price was high,
> which led me to port GNAT to Debian/armhf myself[2]. But at least now,
> they (AdaCore) cannot say there has been no demand for ARM. ;)
Hmmm... I think they can say that, since they probably define "demand"
as "demand from customers who are willing to pay our price".
(I don't mean to criticize AdaCore. They have the right to set their own
prices to fit their business model.)
On Tuesday, 20 November 2012 21:25:56 UTC, Tero Koskinen wrote:
> About a year ago I asked from AdaCore how much it would cost
> to have GNAT Pro (1y subscription) for bareboard ARM microcontroller
> board (cortex-m3). As you can probably guess, the price was high,
> which led me to port GNAT to Debian/armhf myself[2]. But at least now,
> they (AdaCore) cannot say there has been no demand for ARM. ;)
Getting Ada on ARM isn't the hard part, the hard part is the zero-cost exceptions.
On Thu, 08 Nov 2012 13:36:27 +0400, Jacob Sparre Andersen wrote:
> Brian Drummond wrote:
>> Yes. Bare metal programming on a Z80 is easy. Ditto PIC, AVR, etc etc,
>> and of these only the AVR has an Ada toolchain. It may not be mature
>> but it is very usable.
> I hope you'll get a good offer soon. (Even if more Ada compiler targets
> is a good thing.)
Been playing... It turns out that msp-gcc builds remarkably easy with Ada enabled, it only needed one additional patch to build gnattools without building libada...
Next I stole the AVR-Ada RTS and tried building it with minimal changes for just one family of MSP430 processor.
Now I *really* don't know what I am doing with setting up project files, so there is a horrid sequence of commands to build an executable with these tools...
but I have a "port" of the AVR "blinky" example running away on an MSP430!
It actually tried to work first time, except that I didn't know that the watchdog timer is enabled by default on an MSP...
I have a feeling that the difficult part will be packaging all the peripherals for 450 different processor models...
Don't know if there will be any interest in Ada on the MSP430?
Brian Drummond <br...@shapes.demon.co.uk> writes:
> Don't know if there will be any interest in Ada on the MSP430?
Yes! What you've done is way cool. I got a TI Launchpad recently and
haven't had time to set it up yet, but it would be awesome to program it
in Ada. Can the compiler make code for something that small? The
bigger of the two cpu's (it comes with two) has 16k of program flash and
512 bytes of ram, and the smaller has 2k/128b.
On Tue, 25 Dec 2012 01:29:04 -0800, Paul Rubin wrote:
> Brian Drummond <br...@shapes.demon.co.uk> writes:
>> Don't know if there will be any interest in Ada on the MSP430?
> Yes! What you've done is way cool. I got a TI Launchpad recently and
> haven't had time to set it up yet, but it would be awesome to program it
> in Ada. Can the compiler make code for something that small? The
> bigger of the two cpu's (it comes with two) has 16k of program flash and
> 512 bytes of ram, and the smaller has 2k/128b.
Well, my own target device has 2k/128B (MSP430F20102) so, yes.
I haven't even begun to trim executables, so "Blinky" is about 300 bytes vs 65 for AVR-Ada. But you lose 32 bytes to interrupt vectors, there's a 74 byte section full of unnecessary strings, and a full C startup so there's room for improvement...
The entire Ada program is 77 bytes with no optimisation flags. I don't know how MSP430 code density generally compares to AVR, but as a starting point this looks hopeful.
On Tue, 25 Dec 2012 12:11:41 +0200, Niklas Holsti wrote:
> On 12-12-17 18:33 , Brian Drummond wrote:
>> Don't know if there will be any interest in Ada on the MSP430?
> Very possibly. See
On Sunday, October 7, 2012 1:34:51 PM UTC-4, Patrick wrote:
> Does anyone have some more ideas?
Yes. I'll probably piss off a lot of the community here by saying this...the GNAT system SHOULD be just as portable as it's GCC counterpart.
Fortunately I'm learning all about the internals of the GNAT runtime environment. Writing my own verions of some of the low level code.
Resisting the temptation to dive in and chop, chop, chop the codebase up and make my own derived Compiler/Runtime.
Really, as long as all the low level primitives produce behavior that is consistent with the RM, your good to go.
The other good news though is that AdaCore has been making strides in breaking the Compiler and Runtime down into more manageable pieces. Kudos to them.
Yes, you can cross compile with Ada, but you need to take some time out and understand how it's done.
