I wanted to learn .NET Microframework and found that there is (among others) Netduino which is somehow compatible with Arduino. Recently .NET Gadgeteer came to public. There was a lot of enthusiasm, so it looks like important step for .NET Microframework.
Is it possible to compare them somehow? I'm not sure for what tasks is better Netduino and for what tasks Gadgeteer. Or are they in fact completely different beasts?
I'm unable to read this from information available on home pages, because there are mostly marketing materials.
Netduino (and other HW boards, including GHI's FEZ products) are HW devices with an MicroProcessor running .NET Microframework - but in an form factor that resembles Ardunio, meaning you can plug other boards (or shields) on top of the mainboard to extend its functionality.
.NET Gadgeteer is something different:
.NET Gadgeteer Hardware
A .NET Gadgeteer system is composed of a mainboard containing an embedded processor and a variety of modules which connect to the mainboard through a simple plug-and-play interface. There are lots of .NET Gadgeteer modules available today: display, camera, networking, storage, input controls, and more modules are being designed all the time!
The .NET Gadgeteer mainboard's sockets are numbered, and each is labeled with one or more letters which indicate which modules can be plugged into it
CPU is more powerful than Netduino class of devices.
Gadgeteer runtime
Gadgeteer is 100% C# managed code so it is not tied to any firmware (C++ code). http://gadgeteer.codeplex.com/
It is an “Open socket-connections standard".
You can get a module from company x, another module from company y and use both on mainboard from company z, even if you didn't have design files. All will work together nicely. Of course someone may come up with an advanced model that requires special software but mostly modules will simply work.
You can even make your own modules to go on any mainboard...this is the beauty of gadgeteer.
Think of this as "arduino shield like" but better since there is no pin overlapping and you are not limited to couple shields before the board is too long to be usable. You could even take the gadgeteer socket standard and use it on a board that is not running NETMF at all , but you will lose all the nice software gadgeteer provides.
For details about the runtime check out the documents at Codeplex, http://gadgeteer.codeplex.com/releases/view/72208
For more information check out:
http://research.microsoft.com/en-us/projects/gadgeteer/default.aspx
http://channel9.msdn.com/coding4fun/blog/Along-came-a-spider-a-NET-Gadgeteer-FEZ-Spider
http://www.ghielectronics.com/catalog/product/297/
http://channel9.msdn.com/Blogs/Clint/NET-Gadgeteer
Netduino Go was recently released...supporting both Arduino Shield and Gadgeteer module pin compatibility. It also supports plug-and-play go!bus modules.
A few clarifications on Gadgeteer and Netduino:
Gadgeteer, from a hardware perspective, is a pin-assignment technology like Arduino Shields. There's a similar level of simplicity/complexity to it as with Arduino shields (i.e. overlapping pins, peripherals that go away on one socket when you plug in modules on another socket, fixed number of peripheral features, etc.) In contrast to Arduino, only a subset of Gadgeteer modules will work with a given Gadgeteer mainboard. But with Gadgeteer, you get multiple pin interfaces so there's less pin overlapping.
Netduino Go uses plug-and-play style modules. The go!bus protocol that Netduino Go uses is virtual I/O...so when you plug in a go!bus module it auto-enumerates and adds its features to the mainboard. Similar to how USB works on your computer. No overlapping pins or module limitations.
Netduino Go also has a compatibility mode where you can plug in Gadgeteer modules to up to two sockets. Like with other Gadgeteer-compatible boards, plugging in a module disables functionality on one or more other sockets.
Netduino Go has six times the code storage (1MB, 384KB for code), four times the speed (168MHz), and twice the RAM (100KB+) of Netduino Plus.
More info on Netduino Go:
http://forums.netduino.com/index.php?/topic/3867-introducing-netduino-go/
More info on Gadgeteer:
http://gadgeteer.codeplex.com/
Chris
Secret Labs LLC
Netduino is built with the open source hardware movement in mind and is compatible with existing Arduino shields while allowing you to use the .NET Micro framework to program it. This allows you to leverage existing experience with .NET on that platform instead of having to go through another language.
.NET Gadgeteer is a completely different take on the hardware with a specific set of hardware created for it that is modular and standardized.
Think Netduino as an Erector set and .NET Gadgeteer as Legos. You can build stuff with both of them but one is a bit more powerful if you want to apply what you have created to a broader set of problems.
Initial startup costs to get involved are also cheaper with Netduino.
See: http://www.i-programmer.info/news/91-hardware/2819-net-gadgeteer-an-alternative-to-arduino.html
Really the only downside to the Netduino Go is the current lack of networking as at end May 2012.
Chris has already said (elsewhere) that this is only weeks away, and when it ships I suspect the Go will be the go, as it were. It is to Gadgeteer as C# is to Java - more or less the same but done better with the benefit of hindsight. Looking around the forums I see other platforms with either uneven hardware compatibility or mediocre driver quality.
There's also a possibility of onboard RTC. Not a certainty, but you never know your luck in the big city.
Something Chris (and the Gadgeteer guys) don't take enough credit for is the computer-as-a-network approach Gadgeteer and Go both take. The network stack on a single CPU system like the NetduinoPlus can never perform like one that has dedicated CPU with its own buffer, and pushing the network stack onto its own board gets it out of your application code space. I suspect that the Go, running on a Cortex M3 with a supporting cast of Cortex M0s smoothly integrated by the crunchy goodness of baked in virtualisation, is going to feel like developing on a much larger machine.
Some things none of the prototyping boards do well are
Hardware watchdog reboot for hung application code
OTAU (over the air update)
You need both of those for release grade hardware, which I guess means rolling your own. Netduino Go and Gadgeteer expressly support the notion of roll your own modules.
Related
The STM32 supply is very bad at the moment hence I am considering moving away from the STM32 and going for NXP since the supply is much better.
I would like to ask for advice regarding migrating from STM32 to NXP:
Have anyone tried to migrate their project from STM32 to NXP? Can this be done easily if the Core is the same?
What are the major difficulties that I may encounter?
Can I easily just remap pins, copy paste SPI/I2C and other drivers and they will just simply "work"
I have not gone through the migration, but consider that every single peripheral device (timers, Flash, SPI, I2C, etc) between two different micro manufacturers has a completely different register interface. This means that not a single thing works until you've implemented the new register interface. Usually this is handled by the manufacturers HAL, but those also have completely different C interfaces - so you're going to have to implement that, at the very least. So it's going to be a massive change no matter what. People who predict moving their code from one manufacturer to another usually build a porting layer in advance that hides the HAL, and swap out the HALs behind this layer. It mostly moves the development effort to another place (upfront) and starts reducing the work if there are more than 2 ports to maintain.
To get started it's best to have a quick look at the NXP HAL documentation on the peripherals you're using.
Some background:
I am a Computer Engineering major attending school right now, and I just completed a project that created a microprocessor with a super simple instruction set that ran on an FPGA. I chose to implement a simple file storage scheme, a VGA text only display output, and a PS/2 keyboard input. I wrote two main programs, a firmware that was in ROM in the processor and a kernel that provided a bunch of library type functions, and was capable of loading and executing files from the filesystem. This project was challenging and overall a lot of fun.
My Question:
I want to do some super low level programming on a modern computer, but I can't seem to find any resources or documentation that help me get started. To be clear, I want to find the proper documentation that would help me to write a program in C, x86, or x86-64 assembly that I could compile, and format into some form of bootable data. I know this is a daunting task, and typically not something a hobbyist would take on, but I know that it's possible (Terry Davis's TempleOS).
Are there any websites or books that I can read that will contain the specifics needed to make something like this?
Look out, you might just catch the bug. OS Development, though having a very small demographic, is still quite a thriving hobby. Once you start, you may not ever give it up.
Since your subject line states 64-bit and you use the term modern hardware, be advised that modern hardware no longer has the older style BIOS, where the developer wrote the boot process which included the video out, file system in, and other standard routines. Modern hardware now uses an EFI firmware which does all of the booting for you, including the reading from the file system(s). For modern hardware, OS development really starts with the OS Loader, the part that loads the OS, and this is done in a high level language such as C/C++. Very little if any assembly at all, in fact that is its point/purpose.
Don't get too discouraged, currently a lot of computers still allow the old style boot. However, the old style boot starts in 16-bit mode, moves to 32-bit mode, then if desired, moves to long mode (64-bit). There also are emulators that you can use so you don't have to have a separate system, just to test your development. I prefer Bochs myself, but I am a little bias since I wrote some of the code for it, namely most of the (original) USB emulation.
If you wish to dip your toes into this hobby, there are numerous places to start. I personally wrote a few books on the subject. They show you how to start from when the time the POST gives up control to your boot code, up to the point of a minimal Round Robin style task/thread switching OS, with all the necessary hardware and software basics to do so. There is a forum to OS Development, along with its wiki.
Again, a project like this is not for the faint at heart, though it is an enjoyable hobby most have found to be a very good learning experience.
I want to get into OS development. However, I'm not interested in all the quirks with the x86 architecture. I'm interested in the design of the OS.
So I looked around for an (x86, or x86_64 would be even better) OS toolkit. Something that deals with switching to protected mode and configuring interrupts through simple C function calls.
The only thing that I was able to find was this toolkit that hasn't been touched since 2002. Before I get started with my OS, I wanted to make sure that there isn't a more recent/better toolkit to aid in OS development (for x86 or x86-64). So, is there a better toolkit than this, and if I use these kinds of toolkits, what kinds of problems might I encounter along the road (that I wouldn't have run into had I done all the gritty work myself)?
There are no (good) OS toolkits; and I'm not sure a good OS toolkit would make any practical sense (e.g. it'd need to cover all possible OS designs rather than just one, and would be more complex than any single OS could ever be).
The good news is that you probably don't need a toolkit anyway. If you aren't planning to write your own boot code (e.g start with GRUB), then the amount of assembly you need isn't very much and most of it can be taken from elsewhere fairly easily (e.g. http://wiki.osdev.org/Inline_Assembly/Examples).
I probably shouldn't tell you the bad news; but a scheduler is a small part of a kernel, and a kernel is a small part of an OS. For example, a scheduler might be 2000 lines of code, but Linux is about 50 million lines of code, and if you add stuff like Apache, X, Gnome/KDE, Mozilla, etc on top of that then you can imagine how much potential for "gritty work" might be involved in an entire OS... :-)
Are there any technical benefits to Windows/Microsoft as a platform to use while developing, over a Unix dialect such as Linux or Solaris?
I know that companies choose Microsoft at times because there's simply not enough programmers available that know Unix, or that these programmers are much more expensive to hire.
So assuming all developers knew Unix and Microsoft equally well, would there still be cases where you are better off developing in Windows?
To me there's only two arguments for using Windows as a dev platform:
You have to because you're doing .Net/Windows development (or because the company simply gives you no choice); or
The apps, specifically Microsoft Office/Exchange. I'm sorry but OpenOffice is dreadful in comparison to Word/Excel.
Apart from that imho Linux has every other advantage including:
MUCH faster filesystem (particularly important when dealing with lots of small files). Last year I went from a build time of 8-10 minutes to 2-3 just by this switch (ant build of same code base);
Typically your dev environment then matches your production environment (if you're production environment is Windows your dev environment will be Windows almost guaranteed), which can be useful. We've had issues with Java classpath visibility because of differences between JBoss on Windows and Linux; and
A much better set of command line tools (yes I knwo you can use Cygwin, etc but it's not as good).
That's one reason why I find the idea of a Mac as my next dev workstation so appealling: you can look it as either Unix with applications (ie Office) or Windows with a decent filesystem (will be even better if/when OSX adopts ZFS), either way it's a win. The only thing that's really put me off is that Apple does stupid things like delay Java 6 release by a year just so they can put the Leopard Look and Feel in.
Just off the top of my mind:
.NET (even though mono is really great)
Visual Studio - probably the best IDE around
Excellent documentation (The MSDN Library is way much more developer friendly than man pages in my opinion)
Huge userbase (that's more like a business thing but still it is a very important factor)
Binary compatability (it's much easier to support 4-5 kernels and standard C library versions than the infinite number of combinations you can find in Linux distros)
One of the best things you can do is keep your options open. Chopse a platform independant technology and you'll be able to have software for any O/S or implementation. From a technical standpoint, this makes a lot of sense as well as from a business one.
As for specific technical advantages to the Windows platform, other than the large developer community and development information store and widely supported IDE's like Visual Studio, I'd say you'll be hard pressed to find one. Even there, Eclipse can do just as good a job with a platform independant technology.
Microsoft systems tend to have much better integration between different parts - there's a lot less heterogeneity to worry about if you're using binary-only software (x86 and comctl3d is a lot easier to support than everything *nix runs on).
The learning curve on Windows is shallow to begin with but has a longer overall distance. On Unix/Linux the beginning is a struggle but getting stuff done becomes easier later on, when the inner workings of the OS begin to make sense.
At least that's been my experience with them. Windows for quick payoff, Linux if you're going to be doing something much longer-term. And virtual machines if you can't decide :)
I think this question presents a false dichotomy. There's no reason you have to choose windows over unix or vice versa. Virtualization is free and easy. It's the best of both worlds!
One reason we have Windows development platforms (even though our production is on Linux or Solaris) is common environment for all.
That means all the different populations involved in the realization of a softwares:
are not all developers (business, functional people are also concerned with a working environment)
are all on the same platform (Windows)
use all the same tools to write/communicate (as in Word, PowerPoint)
can have their same environment on laptop
In short: uniformity of environment for all (developers and non-developers alike).
The other reason is depreciation: it is easy to manage depreciation for PCs, where the services are lighter than a full-scale Unix server (like a Sun Fire, a F15K or F50K, ...): the latter needs some expensive assistance service contracts (like "bronze", "silver" or "gold" depending on the level needed). A PC is easier to fix/replace, and is not as critical is a developer "mess up" on it and crash it utterly ;)
That being said, the downside of this is you do not change PC every day: it means managing a large parc of desktops, you cannot just decide to upgrade like that (and that goes for Os too).
So where the other answers are all about "virtual machine" whereas your set of PCs is from 2003, with only 40Go of hard-drive and 1, may be 2Go of memory..., you realize "virtualization" is not always an obvious solution.
Hence, some Unix "integration" server are required for developers to test their products in an environment closer to the target. In a way, this is better, since those integration servers are managed in a uniformed way, avoiding the syndrome of "it works for meTM", as opposed to virtual machine, where each developer is the own root/administrator of one's own little world/server ;).
I can give you a common arguments that Windows folks might make, though not one I necessarily agree with.
People sometimes think that Windows boxes at production time are easier to maintain and deploy. That is because there are a lot of visual tools available to the admin. Therefore they prefer .Net or a Windows-specific development language for easy integration.
If your customers or internal clients use all windows desktop computers, some would argue that its less legwork to do stuff with Windows servers. This includes stuff for Microsoft Office document sharing (i.e. sharepoint) or stuff with Windows File Sharing. Obviously its easier to write a .Net application to deal with such Microsoft-specific constraints.
I can't really think of any other reasons. The latter one is probably the most valid -- there just might be some microsoft-specific technology that is hard to integrate with unless you use MSFT development tools.
Peripheral reasons for some specific kinds of development:
you need to see how things look in both firefox and explorer
you're working with flash (which AFAIK you can't develop on linux, and the players are terrible).
you're working on a project that involved MS office integration
you're office has some godawful mail or notes system that you can't log into any other way. ditto for some vpn setups.
I consider all of these things to be regrettable.
Why not use both?
In either scenario, you could use a virtual machine in either Windows or Linux/Unix for basically nothing using Virtual Box or Vmware player. Or you could remote desktop/vnc to the other platform from your development box. If you develop in .net you would probably be better off on Windows for dev. If you develop for LAMP, either Windows/*nix would be fine.
give me apache mysql (ok postgres in a pinch) php and eclipse .. who cares about the OS ..
I recently posted a question about Azure... is it really an OS? I understand the technical details, and I got a lot of fuzzy answers... I really want to know... what do you think is the difference between an OS and a Framework?
Just for reference, Azure will be built on top of Hyper-V servers and the virtual machines will be running vanilla Windows Server 2008. It will run services that creates a cloud on top of the many virtual machines which is called Azure. Windows is calling Azure an OS.
I am trying to understand how to define the difference between an OS and a framework.
Operating System: The infrastructure software component of a computer system
Framework: A re-usable design for a software system (or subsystem).
By these definitions it seems to me, that an operating system can be built using a framework, and a framework can be built to interact with an operating system.
Singularity is an example of an experimental OS that is built using managed code.
Framework is a very broad term, it can be used to describe many types of subsystems. It could even describe an operating system.
Operating System is more specific, it implies facilitation of interaction with a computers or group of computers hardware layer, through the use of human user interfaces. I think Azure fits this description.
It's up to marketing - I don't think the terms have a definite meaning any more.
Is a JVM a framework?
What if it's running on a raw uC or even an FPGA - is it an OS?
An OS is the thing that directly interfaces with the machine, be it virtual or real. It has to expose syscalls that handle input devices, output devices, sound, networking, and all the other things that we take for granted these days. It also often provides some kind of UI which uses these services to make it easy to use/useful for an end-user. It needs to have device drivers to work with video cards, sound cards, etc. (Once again, these can be virtualized).
A framework is... something built on top of the OS. It, too, exposes an API, but they are often not so low-level as the one the OS exposes.
frameworks provide api contracts that oses usually don't - meaning they sit atop the os, hide and manage the differences, and consequently give you that platform independence goodness that can broaden our target audience
A framework thought to be as a development environment,a helping platform for further developments and you can work additively to create some other application using components of framework, while OS is system software is an environment to operate a system.