New "Arduino" to beat them all.

Ok,. you may have already heard of it.

86Duino.

http://hackaday.com/2013/12/09/the-40-x86-arduino/

Wow!

I don't see what it adds to the welfare of mankind.

...R

lost_and_confused: Wow!

What problem does it solve?

It adds no more or less to the welfare of mankind than the normal Arduinos.

It also solves just about the same number of problems of man as…you guessed it, the normal Arduinos.

What it does add, is an alternative to ARM and those that know X86 architecture and code will immediately see the advantages instead of just dismissing it out of hand simply because it’s new.

UnoDueTre: those that know X86 architecture and code will immediately see the advantages instead of just dismissing it out of hand simply because it's new.

I'm not saying it's useless, but is it really "Wow!!!"?

Maybe I could get excited if it had a VGA monitor connector or something...

fungus: I'm not saying it's useless, but is it really "Wow!!!"?

The "Wow!!!" factor will vary from person to person. The fact that it's X86 is pretty "Wow!!!" due to the huge code base and tool chains that already exists for that architecture. (obviously not all of it will be useable or even applicable).

As regards a VGA, I have no doubt it will appear in time to come. The decision to leave it out as standard was a good one IMO as many applications will be used "headless" so why add to the cost and complexity of it if it will not be required. Debug printing could be done via the serial port just like with the other Arduinos. Those that need VGA (or other video output) can then add the appropriate "shield".

UnoDueTre:
The fact that it’s X86 is pretty “Wow!!!” due to the huge code base and tool chains that already exists for that architecture.

This is the part I keep seeing as an “advantage” that I understand the least.

What would you cite as an example of something this can do that can’t be done better on eg. Beaglebone or Raspberry Pi (which are about the same price)?

If you can’t recompile the software then there’s no way to use the I/O on this. If you can recompile the software then surely Linux has far more, better “tool chains” than MS-DOS.

Maybe I’m underestimating the amount of x86 assembly language programs that need to be run on new+weird hardware in 2013, but I doubt it.

fungus: What would you cite as an example of something this can do that can't be done better on eg. Beaglebone or Raspberry Pi (which are about the same price)?

This is exactly the question I hoped somebody would answer when I wrote my earlier reply.

Wouldn't the developers have made better use of their time designing something that doesn't repeat things that already exist (or just having a few beers down the pub).

...R

DOS, Windows, Linux, 300 MHz. 128 MB RAM, 8MB Flash, PCIE bus, Ethernet, USB 2.0 host, and an SD card. $40. oh yeah... arduino/86duino.... same thing... lol!

ps note that pcie bus supports vga. and a few other things too.

Great card for all the software weenies out there.
What’s the debug environment for it?

What you all seem to forget is that there are still 1000's of CNC machines out there running on DOS, yes DOS. In fact one can still buy DOS from MicroSoft if you are an OEM or preferred partner. Of course there is also FreeDos which is in active development and Caldera DOS which is far superior to "normal" DOS.

The reason so many of these industrial machines still run DOS is the simplicity of DOS and the fact that it's a real time O.S.

According to the advertising blurb of these 86Duinos, DOS and Windows will run on them, meaning no recompiling required. The other advantage of course is that for TUI apps that use only BIOS interrupts, they will run 100% on it and DOS is only required if the app makes use of DOS interrupts.

These boards will also make for great hobby boards to teach ASM, as all one needs to get is the A86/D86 package and away you go. Then of course there is C, Pascal, Basic and others.

CrossRoads: Great card for all the software weenies out there.

It's all relative ain't it.

What's the debug environment for it?

That is the beauty of the X86, many to choose from, ranging from A86/D86 to Ida to Nasm/Ndisasm to Borland, etc etc. It all depends if one is compiling for DOS, Windows or stand alone (bare metal). Of course there is also countless small Linux distros which will run on it and there one would use Geany as the front-end calling Gcc or even Bacon (via Bash).

It's a completely different kettle of fish to the normal Arduino where one always compiles for a stand-alone environment. Also since the processor used is basically a Pentium, one could compile 16 bit code or 32 bit code or a combination of the two by using different compiler directives.

Well, too much software for my taste. I'll stick with the single chip microcontroller and some shift registers, etc. for embedded stuff.

CrossRoads: Well, too much software for my taste.

It can still be used in stand-alone "mode", which means just compile a simple .com binary which uses the BIOS interrupts as a built-in API. Since 99.99% of BIOS calls are standard for the X86 architecture, the API will be too.

With the Arduino, one is pretty much "stuck" with C++ and in-line ASM, with this board there are plenty more options.

I'll stick with the single chip microcontroller and some shift registers, etc. for embedded stuff.

The 86Duino can also support all of that too. Of course there will be applications where the 86Duino will be a total overkill.

UnoDueTre: Since 99.99% of BIOS calls are standard for the X86 architecture, the API will be too.

That might be useful if the MS-DOS BIOS calls weren't about keyboards, screens, floppy disks, etc., none of which are available for this thing.

UnoDueTre:
What you all seem to forget is that there are still 1000’s of CNC machines out there running on DOS, yes DOS.

True, but they’re already served by all sorts of devices.

UnoDueTre:
That is the beauty of the X86, many to choose from, ranging from A86/D86 to Ida to Nasm/Ndisasm to Borland, etc etc.
It all depends if one is compiling for DOS, Windows or stand alone (bare metal).
Of course there is also countless small Linux distros which will run on it and there one would use Geany as the front-end calling Gcc or even Bacon (via Bash).

It’s a completely different kettle of fish to the normal Arduino where one always compiles for a stand-alone environment.
Also since the processor used is basically a Pentium, one could compile 16 bit code or 32 bit code or a combination of the two
by using different compiler directives.

All of that may be technically true, but none of it seems compelling. For the same money you can have something with connectors for screen, keyboard and mouse.

Maybe I'm slow, but is DOS better than Linux?

...R

fungus:

UnoDueTre:
Since 99.99% of BIOS calls are standard for the X86 architecture, the API will be too.

That might be useful if the MS-DOS BIOS calls weren’t about keyboards, screens, floppy disks, etc., none of which are available for this thing.

Wrong.
MS-DOS calls and BIOS calls are two different things even though some MS-DOS calls do use BIOS.
BIOS has it’s own functions for keyboard, drives, screen and so on which DOS or any other app can choose to use or simply bypass them and use their own.
The fact that the 86Duino has a keyboard even though it’s USB, the BIOS still does the bridging so that the character buffer, leds and so on are still available at the usual addresses.
The same will apply for all other peripherals.
This is true of all X86 based boards and the reason why USB keyboards can still be read as AT keyboards on a modern motherboard running DOS and also why SATA is completely transparent to DOS.

Robin2: Maybe I'm slow, but is DOS better than Linux?

...R

DOS is no where as good as Linux but DOS is real time and much more widespread in the manufacturing sector using older CNC machines amongst others. With Linux one needs a special real time kernel which has other ramifications on loaded modules and such.

fungus: True, but they're already served by all sorts of devices.

Yes these days the G-code is served to the CNC machine by all sorts of devices, but the problem remains in the actual CNC machine. If these commands are not executed in time (because the kernel is busy with another task), the delay could prove to be catastrophic with things like tool posts hitting the chuck, drill bits breaking cause they drilled right thru the work piece and into the bed and so on. This is where a real time OS comes in to prevent exactly that sort of thing.