Argon and Accelerated C#

The Panda II is the most expensive board I’ve ever purchased, and I wouldn’t ever consider paying any more than that for anything. Gadgeteer in general I think is a great idea, but for me, it adds way too much overhead in terms of expense. Simple buttons for $5-$6, $16 for an RGB LED, I think it’s silly. For that kind of money, I wouldn’t be able to own enough stuff to get any useful stuff done.

If I could buy the AOT compiler, I might consider it, depending on price, but if I have to buy an Argon R1, it’ll never happen.

I see, as you say the whole idea of Gadgeteer is to make programming the device easier, and producing projects faster by invoking C# and a managed enviroment, as well as pluggable modules. Of course you will save money by creating a custom PCB, choosing a specific microcontroller for your project and developing in C or C++ to save memory meaning less RAM is required. However for most of these projects Gadgeteer is used for, it is for one off’s or single projects, rather than commercialised production. The new LP1788 board from GHI is a good SoM for higher volume production, but even that is not cost effective when making 1000+ products. There are always pro’s and con’s to each approach, and the key to creating good projects is choosing where to sacrifice some aspects for others.

The reason the Argon is more expensive than other mainboards are the specification it carries, as well as the lower volume manufacture runs than GHI or other manufacturers. There is always a point at which you can no longer reduce a products price, because you will not get a return on your investment in terms of R&D, manufacture, overheads and life cycle.

I hope we can convince you to get an Argon once you see the Accelerated C# performance :slight_smile:

I’m sorry for having derailed the conversation, I didn’t want to make it about Gadgeteer’s price points.

I like to solder, and my time is “free” since this is play for me, I order direct from Digikey, and I’m a competent C programmer. I’m just not in Gadgeteer’s target market. If you released a competitor to the Cerb40, I’d be all over that, though. Even better, a USBizi-style one-chip solution. OSHW doesn’t interest me in the least, unless I can compile the firmware will free tools.

Okay, good feedback about a lower price point board with a lower feature set than the R1.

Hey,

the idea is good, but marking on method and non-object basis has it’s limitations. The whole point of C# and .NET is writing a very structured and easy-to-understand code (as any code is read more times then written). So, even high performance algoithms ideally consist of method calls for data passing and so on. Loosing the ability to really do OOP inside the Accelerated Methods renders it to similar usability as RLP for many but simplest mathemati algorithms - “fast but catastrophic in therms of architecture”.

WIth all the RAM of the emx boards there is actually no real point not to use full AOT in the core feautures of the system (e.g. UI - as glide is not exactly blazing fast as it could be on an 72Mhz arm!). Of cource, implementing full AOT from scratch is quite a challenge - but it would make NETMF really attractive for many projects. (and really - I love c# and so, but using netmf on my EMX board in my bachelor thesis I ran into problems processing data which an AVR gets processed well!).

Bottom line: I’d like to see [Accelerated] attribute on classes rather then methods with OOP support. Reflections are optional, but I don’t see why it should be a problem to reflect precompiled methods as their metadata can be still saved separately.

PS When it comes to prices: Raspberry PI is here, 35$ worth board with quite impressive spec, running full linux with Mono in it, so the full C# support… Add a touchscreen to it and you’ve got emx outperformed and probably outpriced, in every way besides power saving. I love netmf, but it has to get lots of improvement in thems of performance, otherwise it won’t stay long against raspberry-Alike monsters.

It’s even worse than that. Now that the DUE is out, it’s only a matter of time before the cheap $20 knockoffs show up, which, using native code at 84 MHz will blow the doors off of even Hydra. They’ll be easy to use, because they’re Arduino.

NETMF needs an AOT compiler, and it needs it now, if it’s to stay relevant.

I wouldn’t worry about Arduino taking Hydra’s place until it gets more RAM and EEPORM space. Sure you can process quickly and maybe even get some light DSP done at that speed. The DUE still lacks enough RAM to even support a 320x240 screen without outside help.

How long do you think it’ll be until someone pairs up some external RAM and flash with the MCU on the DUE?

@ godefroi - please add some Gadgeteer sockets as well. :wink:

How about this… You can get a Raspberry Pi and a DUE for the price of a Hydra. Should cover all your bases.

Also, there’s no reason that there couldn’t be a native Gadgeteer platform, with C drivers, that could be used from Arduino.

Exactly what I have been thinking recently.

This (Arduino/Pi talks) is what I was thinking of when I suggested to make RLP helpers more robust. http://www.tinyclr.com/forum/topic?id=8493

If GHI made RLP easier to read/write to pins, it would be so much more powerful for the non-embeded developers, imo.

But I guess that’s not their primary target audience.

You can think of Arduino DUE as pure RLP, with really easy reading/writing of pins. No managed code, though.

When we are down to this… How about D programming language ported to ARM? Compatible to pure C (including headers and so on), native and garbage collected!

I’ve been thinking about it for some time. D can be compiled with GCC, and GCC has a backend for ARM. I’m not sure if there’s any reason it wouldn’t work, but I’ve $20 for anyone who can get it working.

I’ve played around a bit with D. It’s like C# but without any framework. Your basic “hello world” compiles down to about 155k, most of which is the statically compiled runtime library and garbage collector, etc. It’s trivial to interface any arbitrary C library, so hardware interfacing would be very easy.

Understood. Having a more robust RLP extensions would be a better hybrid, imo.

There’s currently GPIO.ReadPin, why no Analog.ReadPin?