FEZ In production environment?

My point was, it is possible to implement a Gadgeteer-style system with modern C++, and have all the existing benefits, plus all the benefits of native code, without having to give up a nice, modern programming language.

It doesn’t have to be either-or.

@ godefroi - It is not possible (or rather very difficult) to get runtime debugging over a USB cable on a non-interpreted system. This is one of the main features of NETMF. We also need ot keep in mind that not everything is interpreted, only your application. But then where is the problem is things are interpreted?

Yes native code is much faster but for many application speed is not an issue. One of our important customers make vehicle parking lot system. You know, where you insert your card. They just need an outdoor rated display then add G120/EMX and you are good to go. Another one, they control inventory for places with expensive tools or controlled substances. They even use our gadgeteer 7" display as is, in products! The operator will have to log in and select what they need and then the system unlocks one of the doors…etc.

NETMF is not the answer to every need, nor is anything else. Multi-million dollars in sales and continuous growth says it is a very good thing. So lets be a bit positive please, for the sake of those who are looking into using NETMF and looking at these public discussions. I hope your goal from being part of this community is to help others and to push NETMF/gadgeteer up. There is difference between constructive criticism and there is “let me scare new customers away” :slight_smile:

1 Like

Gus, that’s just plain false. Here I am right now doing runtime debugging of native code, over USB, on a non-interpreted system. This whole system (including the hardware necessary for debugging) was free to me, and costs $15 from retailers here in the US now. It happens to be from ST, but there are similar systems that include debugging hardware from other manufacturers. The software is all completely free, and runs on multiple operating systems. It was not difficult to get set up.

I’m all for NETMF, it’s great, but if you have to resort to half-truths to sell it, then you’re doing it a disservice.

1 Like

@ godefroi

Is that a Discovery board + ST Link + GCC + OOCD ?

The board you are talking about has a second chip that does the debugging. It is an on board JTAG.

Please note that my concerns are not about GHI alone. There are other companies and communities who are big part of netmf.

Your replies are always just too harsh. You even did it again in your very last reply.

Indeed it is. The Stellaris Launchpad has a similar setup, with onboard debugging, and it is even cheaper than the STM32F4DISCOVERY.

I’m aware of that, but it doesn’t make it less true that I’m debugging native code over USB. The onboard STLink can even be used to debug other chips, such as the Cerb40 or Cerbuino Bee.

Gus, if my replies are too harsh, it’s because your replies are too false. There, I’ve done it again.

Ok, so you have a $15 board that you can debug on. Now, design your own board, based on that setup, WITH THE DEBUGGER ONBOARD. Then we can talk again.

Lets look at the Cerb40 for example. If you want to do something similar then you have to add a second cpu, suddenly you double the cost in part, double the cost in PCB space, double the cost of pick&place(double the number of parts to place). Then talk to me about “cost”…

Gus was not being “False”. He was saying that it is very hard to do real time native debugging on a CPU via USB when that same CPU is hosting the USB, ie a single chip solution.

godefroi you have made some great points.

I have read some good examples of where .netmf would serve as an awesome tool, but not every situation is the same. For example, a parking lot system sounds well suited. A few machines here and there. I can only imagine how expensive one of those automated machines are at retail price, making it feasible to utilize more expensive hardware while reducing the development time a great deal (saving large sums of money if you are paying a qualified engineer).

However you should always use the right tool for the right job. There are some negatives to using this platform.

#1. Speed, .NETMF is SLOW. If your device needs to perform low level operations efficiently, then think long and hard

#2. Hardware cost, portability, and potential support issues. If you are using devices with premium libraries you are restricted to one source for supply and support. If there is an issue with either, then you will be stuck between a rock and a hard place… No supply, no support, and unable to easily port to another generic hardware platform (Due to closed source libs).

Just think long and hard.

Remember, this is almost always an issue. Even if you don’t use NETMF, you will still be locked into a vendor, be that ST, Microchip, National Semi, Texas Inst. Yes, there are some portability between chips using the same core, such as Cortex-M3, or what ever, but it is never as plain as flashing your binary image design for TI onto an ST chip. The work involved to port from one vendor to another is hair raising.

Same with development on the PC. If you buy a lib from a third party, because you need control X and it is faster to buy the lib then to write one yourself. Then you are also locked into a single vendor, and it was by choice.

Same with premium libs from GHI. You don’t HAVE to use them, but it makes life SO MUCH EASIER. Is that GHI’s fault? If you need portability then don’t use the premium libs, code everything yourself, and you will still have portability. But it will take you much longer…

everyone has to remember that “it is the craftsman not the tool”.

we can argue which platform would be best for a specific application/product, but without
a context, arguing which platform is the “best” is an emotional exercise not worthy of
craftsmen/engineers.

4 Likes

Why do I need to have the debugger onboard? What benefit does that provide? I can take these two jumpers off the Discovery board, and now it’s a fully-functional STLink/V2 that is perfectly capable of debugging my Cerb40. I can even use the USB functionality while debugging over USB! No USB-serial converter required, and no boot-time hardware configuration required.

That may be what he meant, but it’s not what he said.

Listen, I’m not trying to be divisive here, but as long as noone ever thinks outside the box, and as long as everyone pretends that NETMF is perfect, then it can never improve. Every time someone asks “how do I do X with NETMF” and the answer comes back "oh, just add [some other thing that can do not only X but also everything else the asker is doing with NETMF as well] and connect it to your NETMF board it makes me frustrated.

What makes you think noone thinks outside the box? Having a debug on board at no extra cost IS thinking outside the box. :slight_smile:

Listen, I’m a professional embedded developer. I program, at this point, Microchip PIC18Fs the whole day. I’m using a PICKIT3 as a debugger as it is cheap to replace and the workshop uses it too to load the initial bootloader onto the PICs. And I also use this PIC’s USB for status feedback.

I would have loved to use a USBizi for this project, but it started a few years ago, before I knew about USBizi. All I knew about was $300 netMF boards.

I do agree that NETMF can’t be used everywhere. Mostly where the overhead cant be tollerated, like extreme low power devices. The previous place I worked used MSP430s in a device that had to run 5 years of 6 AA batteries, with a 433MHz radio. They placed the CPU and radio in sleep mode 99% of the time, and they accounted for every microsecond that the CPU or radio was awake. For this application staying awake 1ms longer affected the battery file by 20%. They limited the system to 20uA average, over 1 minute, with wakeups every second and the radio waking up, and looking for something useful on the air, every 5 seconds.

When last have you implemented a preemptive OS in C++? This is what netMF is. If you don’t need an OS then go for C++, and vice versa.

Errol,

Are you using GHI products in any of your commercial end user products?

Not yet, but i’m pushing.

At this time we only have one commercial product. A drop-safe. It is a safe that gets installed in the back office of a shop. The shop takes all its cash on a regular basis and deposits it in the drop safe. This helps minimise losses in the event of an armed robbery as noone in the shop has the ability to open the safe. Only te appointed cash collection team, who has an armoured vehicle, can open the safe. The safe reports all deposits via GPRS to the cash collection company. It also stacks the cash in two plastic bags, which it heat seals.

The safe counts the cash, identifies the denomination of each note, and spits out counterfeit notes. I do the mechatronic programming, controlling all the motors and colecting sensor feedback. This I pass via USB to a small Windows Embedded Standard PC that shows fancy WPF graphics on a 17" touch screen. It also runs SQL server and some other servers.

Unfortunately this project has been running 2 years, and started before I moved over to this company. And we only started installing safes two months ago.

But I’m pushing for G120 modules for the safe maintanance units and safe installation/configuration units.

If it wasn’t for the graphics then I whould have pushed that we change the safe over to a G120, but an Atom 1.4GHz PC with onboard Intel GFX was too slow to handle the graphics, so we had to switch over to a dual core AMD 1.8GHz with Radeon GFX.

I suspect both those are heavily subsidized by the manufacturer as a loss leader to push adoption.

That sounds like a pretty cool system. I wish your company good luck, and it sounds like a g120 module would be suitable for the maintenance tool considering the low production count and overall cost of each maintenance unit.

Of course it is, that’s the whole point. It’s why I got one for free. If you want to pay full price for the standalone ST-Link/v2, it’ll cost you a whopping $21.25, or roughly the cost of an FTDI cable.

If you’re working with Cerberus & family and attempting to build and debug the firmware, it would be a really good investment.

This is definitely possible, but a major, major effort. It could mean designing and implementing an embedded OS with modern languages in mind, and with a solid extensibility mechanism such as Microsoft’s Component Object Model used for the driver API and other core APIs. Providing a robust debugging service is just one of the challenges, no matter whether the code is interpreted or compiled.

We did something like this 15 years ago, a bootable hard real-time Java runtime (with Java bytecode compiled to native code upon class loading, our own TCP stack, debugging support, etc.). You’d need a handful of brilliant and experienced developers. Then, after one to two years, you’d have an end-to-end system working, big success. But unfortunately this would be just the beginning, then for the next five to ten years you would have to add an incredible number of small things that are simply needed, or clean up the shortcuts you have taken, or otherwise do many many small improvements that are necessary but very unsexy. (And then the venture capital people would change strategy and tell you to drop the real-time / embedded stuff in order to focus on easier and more fashionable topics, but that’s another story.)

We considered doing this again and develop our own bootable, compiled, real-time capable .NET runtime. But due to the this prior experience, we instead opted to contribute to NETMF. NETMF is too large and too slow for some applications, but there are definitely many applications where this doesn’t matter, compared to the productivity gains of .NET and Visual Studio. NETMF is also in this “marathon” phase where much development has been done but much more is still needed to smooth out all the kinks, and where this will not be very visible and not very easy to “sell”. However, I don’t know of another (open source) managed code runtime that is similarly far along this curve, that’s why we focus on these difficult quality improvements that are needed to “get to the finish line” (of course there is no such thing).

Whether C++11 is a nice language would be a different topic :wink:

1 Like

^ Well said, thank you for contributing to the topic,.

You’re bringing cost into a presumably feature/merit based argument. - A price which is probably unsupportable from a business standpoint. So it is somewhat moot.

Cuno does a better job responding. I would have just said “Sure, give it a go - and be sure to let us know when you’re done.”