Getting build environment set up

Sheez! I think you better lay down with those Red Bulls mate! While I understand your frustration about have to upgrade you newly acquired mainboard… I can assure you its quite normal. Just the other day I had to go through the same frustrations with a Bus Pirate board that I bought. Only difference is that there wasn’t such a nice and friendly bunch of people on their forum so willing to help me out. With GHI I have always been incredibly impressed with how much effort they put into giving excellent customer service. If you are willing to relax and give this a proper chance, then you will realize what I’m talking about. Otherwise it is just your loss.

1 Like

If firmware updates are considered normal, then that needs to be well documented! A sign saying “THIS PRODUCT DOESN’T WORK”

It is my expectation that upon buying something new and then going on to use it as intended, that aforementioned product would not require 10 or 12 hours of troubleshooting and repair.

Getting the 3 or 4 part IDE setup for .NET and C# and it taking more than 2 hours? That was my expectation.

Having to reinstall it a few times? That, too, was my expectation.

Having to reinstall it 4 or 5 times and then try on another computer, just to determine that the firmware needs updating? Fail.

Is not this supposed to be a mature product? Would anyone on this forum or at GHI Electronics want to think they have a product that is superior to Arduino? Your reply says otherwise, so if you do not agree that GHI FEZ is inferior to Arduino, then your effort needs to be spent improving it, not telling the excited, frustrated, but experienced new guy to chill out.

Sorry, it’s not going to be my loss… it’s going to be GHI’s loss. You guys keep on loving them; they need you. When new folks come along and are presented with this? That means no growth. Make someone happy and they will tell 1 or 2 people about your brand. Piss them off and they’ll tell 10 or 15 people about that.

Yes, I’ll update the firmware on my brand new GHI product tomorrow. And I’ll try the blink. Twice. Any odds on my efforts to make a Netduino blink? That’s the direct comparison… Earlier today when I installed their SDK, all of their options showed up on the 1st try in Project -> New.

Kiwi? Does that mean from New Zealand? Oy! Kiwis are a tough lot about quality! No other country screams as us more when something is amiss upon opening the box! In fact, Kiwis determine when we stop selling from particular vendors.

I had to smile when I read this. Yup, not a born an bred Kiwi, but already seeing myself as one and quite happy about it.

Anyway, I’m not trying to criticise and certainly do not want to go into a long argument about whether Arduino or Gadgeteer is the better system. But keep in mind these GHI boards offer many things that you cannot do on an Arduino. Like proper debugging and large code space etc. I have worked a little bit on Arduino I really disliked the IDE and the fact that almost all Arduino programs I ever looked at always consisted of one single bulky file which was difficult to extract single modules. But it does not mean I do not say Arduino has many good aspects as well. But using the Gadgeteer system is just so much more fun for me personally. And with the newer and really powerful boards becoming available nowadays you can make really complex projects.

Anyway, we all make our own choices. I’m happy with mine. Wish you luck with yours.

I’m not going to try to get you less worked up - I can’t

Here’s the simple facts. Earlier this week, a new GHI SDK was released. This is the software that has to match the hardware. At the moment, the over-arching netmf SDK version is only relevant to the version of VS you’re using.

When GHI made the device you got, who knows what SDK version they applied to your device - who knows when it was built. The only way to make sure these devices work is to install your software suite, and then install the firmware that is on your PC. The same kind of thing happens the world over, my TV shipped with “current” firmware when it left the factory, but by the time it landed in AU and then I got around to setting it up there was 5 newer versions - but I could have equally been lucky and the firmware hadn’t moved on. Sorry, it’s going to be something that is likely to change. But I can’t blame you for not being aware of the criticality of matching the vendor SDK and the hardware firmware versions. Do I think it could be easier to find information telling you to update the firmware? Probably it could - there’s never an easy way to make sure that happens. We all get wrapped up in the new-shiny-thing and want to get going quickly. Maybe there should be a “step 5” telling you to use the firmware updater you just installed. But again, we’ve tried to help you through this and I actually hope you stick around because there’s lots of great stuff to be found here - but again, I’m not in a position to change your mind, only you are, and good luck however it works out for you

2 Likes

I would like to add that troubleshooting guide (available from the support page) has a lot of good tips, including the mismatched firmware information:

https://www.ghielectronics.com/docs/165/netmf-and-gadgeteer-troubleshooting

I knew I am quasi-trolling with this thread. Please review the attached image. Does this make sense to anyone? Excuse-time is over. I recalled someone mentioned in passing that Netduinos are sold at Radio Shack. So, last night before finally shutting off the laptop in bed, their website said the store on my way to work has a Netduino in stock. Sure enough.

Following this page ( http://goo.gl/ZbP3Oq ) I got the Netduino to blink. On the first compile and connection to the USB. Coincidentally, all of the other *duino things in the picture blinked on my 1st attempts.

From top to bottom:

  1. Freeduino eleven ( Eleven (100% Arduino Uno Compatible) | Freetronics ) interfacing with LSI7166 to read the DRO glass scale on the Timing Belt Measuring bench.
  2. Seeedstudio Mega 2560
  3. chipKIT Uno32
  4. Arduino Mega mounted in beige tray
  5. my 1st Ardunio, an Uno
  6. Arduino Mega with Rugged motor shield and 16x2 LCD which was my TPS testing bench
  7. chipKIT uC32
  8. pro Mini
  9. Seeedstudio Mega 1280 * once I learned it was a 1280, it blinked on 1st try. That took a few minutes, but was not an all day effort
  10. netduino

And again, this FEZ Cerbuino shipped from GHI directly. Update it. Or at least change the card they put in to say “STOP, update your firmware 1st”

I have no doubts about the platform, that’s why I bought it. And I’m really loving the autocompletion in the IDE. I use Geany otherwise, not the Arduino IDE. So, the netduino works, I’m using it to prove the parts and pieces in my project will work in .NET. I believe I’ll end up needing the increased SRAM of the Cerbuino (which is why I bought it).

As a response to your troll… :wink:

Seems like you might have been lucky about the firmware on your netduino being the same as their current SDK requires. Nice. But again, if some in the future that wasn’t the case, or if it had sat on the shelves longer, then you would have had the same situation - mismatch in firmware leads to unexplained issues.

The netduino is an old product with old firmware. I followed steps for it. No problem.

I’d love to see anyone who isn’t already using GHI products buy one and get it working as easily as the other 10 embedded devices in the picture. I am not ever going to accept or agree with your complacency about the firmware. I will consider it as improperly channeled support and loyalty to your favorite brand.

They’ve got a tech guy emailing me who is also somewhat new to .NET. As soon as they’ve got a process for VC2010 figured out for the Cebuino (or the Panda that just came in the mail), I’ll go get a different computer and try it out. I’ve been giving helpful suggestions and so far they have showed concern about my position of not wanting to spend 14+ hours of dev time getting it to blink. Which, by the way, it still hasn’t.

For now, I’m porting my code to work in netduino, which actually worked on the first try and not by coincidence.

so I don’t really understand your point. You had to do the same firmware upgrade process on netduino, but doing on the cerb is a problem? And this isn’t a netduino vs fez thing, there are many people here who are regular users of both - personally I can’t wait to see Chris’ watch turn up at my post box !

If you want to really be of help here, tell us what you think could have been different here. We’re listening.

[quote=“Brett”]
You had to do the same firmware upgrade process on netduino, but doing on the cerb is a problem? [/quote]

No updating of firmware. And now that I think of it, the only device I have ever knowingly and intentionally updated the firmware on is a eye-fi SD Card. None of the microcontrollers pictured have had firmware updates.

I’m already talking to GHI with positive suggestions. Definitely, there needs to be enough information on each product page about how to make that product actually work. Like I said, bought netduino, clicked 5 things, typed, pressed F5 … and it starts blinking the …—… pattern that I programmed in it.

You guys are clinging pretty fantastically to the concept of immediately applying firmware updates to anything you buy. I’ve been programming embedded since about 1996 and this is the first “community” so rallied around the concept. I am genuinely surprised that’s the attitude here.

For the rest of us, at the very least put some tape over the mini usb port and have it say “STOP! Update the firmware before doing anything else!”

And yes, I am a luddite. If 2010 is the simplest platform that will accomplish my needs, that’s what I’ll use. 2012 is a bit much Windows 8 for my tastes and takes too long to load, but my Windows Experience rating of 7.6 might not meet your guys’ needs. So I’ll develop in VC 2010 until it is unable to do what I need.

[quote=“cacycleworks”]

How many of those have just had firmware just released?

Correct me if I am wrong, but neither Netduino or Arduino have recently releases firmware updates.

I got my Dominio and plugged it and it worked. When I got my Spider, I plugged it in and it worked just fine. Both cases, there were no recent firmware updates from MS or GHI.

I agree that several people have been tripped up by this update. But this is not the norm either.

@ cacycleworks - btw, that is a hell of a gas tank you are offering!
:smiley:

This was what led me to believe you talked about firmware updates for the netduino.

I’m also sorry but the one concept you haven’t grasped quite yet here is that the CLR is embedded onto the device, and you then load your app alongside that. In a traditional embedded sense, most things you will deploy are the bare metal code; that’s not the case here. When you develop netmf code, you have to have three things in sync; the netmf SDK version, the proprietary hardware SDK, and the firmware on the processor. If you have mismatches there, then you run into problems, for example calls to functions that don’t exist or that have changed memory locations, all causing issues.

Contrast that to your other scenarios (except netduino), and the only revision that you could get hung up with is silicon revision issues that your compiler didn’t take care of. When you run that close to the metal, you don’t have those layers of abstraction to get in the way or to derail you - in the higher abstracted scenario with netmf, there’s more importance in keeping those things in sync, and that’s the compromise for an abstracted view of hardware. No longer do you need to know how to set up the uart clock registers to get a baud rate you want, you just open it at a speed and go… but the cost is that the functions to do that have to be in known locations and match what your PC knows about etc.

Anyway, glad to hear the GHI guys are helping (I know they would) and as I said earlier I do hope you persist and we see more of you - the project you posted in the other thread does sound interesting.

Whoa, so the CLR could be loosely referred to as an on-target compiler? OK that explains my disconnect with reality with “firmware”. Hmph.

OK, can y’all please suffer helping me figure this out? (yes, I am originally from the South)

We’ve got the .NET version the target’s firmware is designed for
We’ve got the .NET version of Micro Framework (MF)
We’ve got the .NET version of company branded SDK intended to support their boards/targets

Right?

OK, so at work, I uninstalled everything with the date of 8/29 then reinstalled the software that Netduino says to use for their not-2 products:

  1. Microsoft Visual C# Express 2010
  2. .NET Micro Framework SDK v4.1
  3. Netduino SDK v4.1.0 (64-bit)

Since all this is about a year old, would it then be reasonable to expect the Cerbuino Bee I have to work if I then install Feb 13, 2013 Release of NETMF and Gadgeteer Package 2013 R1? This is all kinda annoying in a way in that reading people talk about .NET 4.2 vs 4.1 say that it’s backwards compatible. So is it only backwards compatible if the manufacturer of the target releases new firmware for the 4.1 product to work in 4.2 land?

Why do I ask all this? I was able to get the Netduino to talk with my Sparkfun RTC at work. So I brought stuff home to work on the ST7735. I’d like to introduce GHI stuff into my reality one step at a time. I already am assuming the netduino will not be sufficient and I’ll need the superior specification of the GHI Cerbuino or Panda to make my project work.

Does anyone have like a pictoral diagram flowchart of all this misery? Ugh. This is like GIT version control. Until I saw the diagram here: A successful Git branching model » nvie.com I totally didn’t get it.

ok, I never realized the netduino firmware was still in the 4.1 branch.

The good news is that there is an easy order (although you might not have done it that way, sorry :frowning: )

You install the VS you want - you said you didn’t want/like 2012, that’s cool just get 2010.

You then need to install the netmf 4.2 QFE2 package since that is the “linked” package for VS2010 and current SDKs that you want for Cerb

You then install the GHI 4.2 SDK from this week

You then install the netduino 4.1 SDK. (this is the same as the order that GHI tell you to do this with their 4.1 only devices like the Panda and Domino)

If you have already installed VS, you can safely uninstall the SDKs in the order you install them in. The later netmf (4.2 QFE2) allows you to target the 4.1 framework when you’re using your netduino, and you can still use the latest with Cerb. [ as a total aside, you can do the same with VS 2012, install the 4.3 RTM SDK, install the GHI SDK from this week, install the netduino SDK, and then you’d be able to target anything that has a 4.3 firmware if you got that in the future too! ]

There is one important tool that no one mentioned you should use that would help you debug your board and know what version of the firmware you have and that tool is called MFDEPLOY, located in a folder called tools that is installed where the netmf SDK was installed, please locate it run it, plug your cerbui, and choose USB, then check the device capabilities and report back here by copying and pasting the info, and then we will be able to direct you to the right SDK and all that you need to get up and running…

Cheers.