Is it possible to make an Go port out of the jtag header?, or are we getting an Go Shield?

I haven't looked at the schematic but my guess is no. The mini jtag is probably wired to the STM chip. Go ports require SPI and GPIO pins which I doubt are part of the jtag spec.

As for a Go Port shield - that would be cool! It would really unify all the products - use any of them with any of the boards you might have. +1 to that idea!

Does this board have an hibernate feature?

I believe the STM chip has different power modes but I think NETMF is limited in what it can do. Maybe this should be a feature request?

I personally would love to have a low power profile such that at boot up all the shield power pins are off. If I have threads all asleep the MCU should go into low power mode. I'd like to be able to tell the MCU to go down and wait for an interrupt before waking up to do work.

Hi x893,

We used RVCT (ARM RVDS 4.1) to compile the Netduino Go firmware.

CW2 did quite a bit of work to get it to compile under GCC (using Yagarto...maybe CodeSourcery) as well. This is not tested, but we do want to make sure that everything compiles under the free GCC compiler as well.

Chris

THANK YOU! I tried compiling 4.1 from the NETMF sources but it was a jumbled mess and I couldn't figure it out. After a couple hours I was like: "I has a sad" and gave up. But I still strongly desire to tinker in the native layer to add in some things I think would be useful for me and test them out. I don't like the idea of asking others to make the change to see what happens and I won't blindly send a pull request or merge source that I can't test myself!

Chris - You're my hero for inspiring such awesome people.
CW2 - I will grant you one wish. Within my power to grant. And if it's not too troublesome or very illegal. Unless I'm incapable of making it work again.

If you want to use the go!bus compatibility logo, you'll need to use go!bus IO virtualization firmware on your chip (STM8S and STM32 supported soon, AVR and others hopefully supported in the future). It does fun things like let us know how much power you need and lets you build a super-low-cost-module with both tons of intelligence and plug and play ease.

BTW, the STM8S chips are thirty-something-cents in reels. I kid you not.


The on-module processor is there to speak the go!bus protocol and virtualize your IOs. So that your driver on the Netduino Go mainboard sees its IOs, SPI bus, I2C bus, UARTs, PWMs, ADCs, etc. as its own. We can take a small number of developers into our module builder's group for the next few months...once we feel that everything is ready for widespread module building we'll open it up to everyone. 100% cross-board compatibility is our utmost concern.

Will there be a module development board making its way out of that builder's group? I think it'd be good for developers to have a standardized module for creating their go!bus compatible modules. Sure we could use the shield base but that will be flashed specifically for the shield. Would a board with the micro, a go!bus socket, maybe some DIP switches for any configurable settings (power requirements you mentioned...?) and breakouts of pins from the micro be feasible and more useful than the shield base itself?

Heck, this might even be easier for creating limited run modules for special purposes if you offered some cases that fit around the module with a hole for the bus cable. It'd be a heck of a lot easier than designing the PCB, sources the electronics (without bulk pricing! oh noes!) etc. Then if it turns into something people want en masse, the work to turn it into a real and true module could be done at that time.

Is there already an offering or alternative I've failed to consider?

The firmware source patch for GCC-based toolchains will be released soon. Please stay tuned.

Tease.

I got to see the sample on-hand at Maker Faire. It's really compact! I've heard some of the issues that have cropped up and had to be worked out. They're being really thorough and as anxious as I am to get my hands on the final production module, I'm much happier knowing the module will work well when it is available. I think we're in the final stretch! I just hope there isn't too much delay between the announcement and shipping. I know some delivery services in NYC are still not operating in parts of the city. There are fuel shortages, power is still out in some places and infrastructure has been damaged. Fingers crossed this won't have too much of an effect!

I was at the booth for a short time yesterday and from overhearing just a few people it was clear people were very happy to know they could use just one board and the hub to use all the modules. It would seem there was some frustration with the number of choices out there. The dilema of choice. I'm incredibly excited to see a unifying solution! I really think this will be overall a very good thing for users. Kudos.

SparkFun has a couple EL Wire controller boards which use Triacs to switch high frequency AC from an inverter to the wire. One model has a microcontroller on board and the other is meant to be used as a shield.

I've never looked at the schematics to see how this differs from what I know about SSRs so this is presented as informational and entertainment purposes only. If you learn something it's your own fault.

Enjoy!

As you can see in this thread, one of your customers have no issues figuring out that your modules is not ready for the new firmware yet, and i'm sure they will be soonish, as i can see your are offered all kinds of help on this issue, but i fail completely to see why other projects should wait.

I picked up on that as well. I wanted to escort her out of the thread and thank her for her bug report!

New software usually has some known errata upon release. Most of the times things are found after. This looks like one of those times. I think this might have escalated a bit beyond reason here - though I agree a minor build should not introduce any contract changes, it's hardly damaging at this point. I think, given the report and the reproducibility maybe it would be good to put a notice on the product page(s) saying there is a known issue with this firmware release and that it's not recommended for people using those modules.


In the mean time it seems Chris is offerring resources to help correct the problem. It looks like he's already pointed out some suggestions as to possible issues or at least some best practices. I'd love to see these tidbits incorporated into the Module Builders guide (whatever the actual title or form it might take) but in the mean time I'd say take a step back for the moment. It doesn't really seem like a big deal. If people are using these modules successfully, they wouldn't upgrade to the newest firmware just for giggles. If they did, I'd say they'd have the capability to downgrade back to the last working version just as easily. If this isn't the case, it doesn't seem like they'd be affected at all during the grace period where this is worked out.

This is precisely why corporations don't jump on new OS releases the day they come out. There are always things that will need to be found. It's not really the OS makers' job to ensure compatibility with all software installs available but they should do a reasonable job at documenting any changes and collecting error reports so 3rd parties can issues patches and become compatible. In this case it sounds like Chris is doing a lot to ensure compatibility with a wide variety of modules but as the ecosystem grows it's going to be harder and harder for them to do this - which is why I think it's great there is a community offering support and even Secret Labs resources to help work this out.

Bottom line - yes, it might be an annoyance to users but that's all it is. It's growing pains. On the upside it's not a hardware change - it's just a software release that will likely need to be undertaken. Again, this is not unexpected in a pure software world, mixing it with hardware doesn't exempt us from this situation.

I think this is a good point to thank theTroll for the bug report and close the thread. Further discussions of how to resolve this particular issue would be better suited on a builders board, not the community board. Any resolution from that discussion, if it seems applicable to other module builders, should of course be shared. There is nothing to hide but to many this is just noise and if they found this thread because they hit the problem, they had their answer many, many replies ago.

-Erik

I am actually going to disagree with this one. There is a lot of value to this being discussed on an open thread. Most likely there are other devs that can learn from it and avoiding having the same issues in something they are working on.

tt.

I'm going to disagree with your disagreement.
This discussion isn't really for devs - it's for module developers. There is a different effort being made on establishing best practices and, I think, write up a Module Builders Guide which would benefit from anything learned during this process.

This particular discussion is just noise on the original question now.

Ulrik,

I felt that your reaction was offensive and unfair. I'm only interested in one thing: getting our users unblocked asap and for issues such as this one to never repeat themselves in the future.

Aside from how you perceived his words, it sounds like we had an easy, quick answer to unblock your users. Don't upgrade to 4.2.1 until this bug is worked out. Bugs happen. In all industries. This is not unexpected and to continue to claim this is errant behavior is disingenuous.

Software releases generally follow a process which involves regression testing to mitigate potential user impact when changes are introduced. It's a reasonable thing to ask if regression-testing occurred because it is a standard best practice in our industry. No one should be offended by that and I am confused as to why anyone would perceive my question to be a wrongful attempt at keeping anyone waiting.

It sounds like they did do quite a bit of work to ensure the update did not change the way the spec was designed. From my observation it looks as though the driver were written in such a way that it happened to work through a bug or fluke. It is out of spec. Of course it could break as the spec evolves if it isn't conformant. Please don't put the weight of, what appears to be, a poor implementation of the spec on the designers of said spec. It's just divisive and won't win you any favors in trying to get problems resolved.

This has moved well beyond anything of benefit of the average user at this point. I'm sorry you feel as though you're going to have to move mountains to make your driver work as it should but it's just a bit of software. And there's time - there's no absolute need for your users to move to 4.2.1 immediately. They're in good hands while this gets worked out. Take the time to analyze what went wrong, read over the spec and recommendations on how to implement and mull over how your interactions could change in the future to be more conducive to problem solving and be just all around a bit more civil.

Bon chance!

Based on some hints I had awhile back, all I can say is: I'm very much excited to hear a formal announcement! I don't think anyone will be upset by it.

Pretty interesting reading let slip from Fabien on Twitter.

http://fabienroyer.w...or-netduino-go/

I am eagerly awaiting my LCD module! In fact, I just got an email from my apartment building saying I have a UPS package waiting for me when I get home. I have a couple things on order and the tracking info only shows me from where the package was shipped. The anticipation is killing me! It could be my order from [nwazet or fancy shampoo! Edit: Looks like it's the LCD module (and sundry)! But now I need more cables...

Um, well that's unfortunate and awkward. It would appear that you were accidently blocked. :$ :$ <insert blushing emoticon>

...well at least that's the story I'm sticking with.

You also have a PM with my apologies. Sorry Erik!

Steve

No worries. I'm surprised being blocked means you can still see the tweets but just can't follow. Um...bookmark? Or is that terribly uncool of me to even know the term?

I think hans polders' guess is my favourite so far in his recent Tweet.

@MyNetduino, guess a new board with the name Netduino Kal-El, Runs @1Ghz, 2 cores, produces power instead of consuming and hates kryptonite

Hmm - "You have been blocked from following this account at the request of the user." But I can see the posts. Weird.

Ok - so back to the clues.
People have figured out the gobbledygook was a date.
It's assumed the FRA... is a pointer to Daft Punk Harder, Better, Faster, Stronger.
And the latest: Faster than a speeding bullet.* And a date.

So, what could the asterisk signify? Internet telephony? Is it to denote something shady like when a record holder was found to be doping?
Better, Faster I'm on board with. Those seem straight forward. Harder? Like - more difficult? This is less awesome. Or is it milled from a solid block of aluminum like MacBooks? Those are pretty awesome and would meet with Stronger too.

Put it all together and ... Holy Crap You Guys - Netduino Phone!*
*Not a real phone.

I'm super in love with today's new clue. If I've interpreted it correctly. Though I'm not sure to what it's referring, I like the message. Seems to fit with the secrecy theme too!

V2l0aCB0aGlzIE5vci1FYXN0ZXIgY29taW5nLCBJIGhvcGUgd2UgaGF2ZSBwb3dlciB0byBmaW5kIG91dCBvbiBOb3YgOC4=

That's actually a good point!

SSBkZW55IGFsbCBrbm93bGVkZ2UuIEkgZG9uJ3Qga25vdyBhIHRoaW5nLg==

U3RlZmFuIC0gU3RvcCBlZ2dpbmcgcGVvcGxlIG9uISBZb3UncmUgc28gbWVhbiE=

If this thing has tons of GPIO/PWM's, can I just pre-order now? Please?!

Adafruit announced these 16-channel 12-bit PWM boards a few weeks back. Works on 3v3 logic but says is 5v compliant.
They also have solder joints to use as logical addresses so you can chain 62 of them for 992 PWM outputs.
Looks like they recently went out of stock but should be back soon. And it's I2C. I always forget what the status of I2C support is though. Maybe that's a non-starter?

V2lsbCB0aGUgU2hpZWxkIEJhc2Ugc3VwcG9ydCBJMkMgdW50aWwgRmViIDIwMTM/IEluIHByZXNl
bnQgc2l0dWF0aW9uLCBJIG5lZWQgdG8gY2hvb3NlIGJldHdlZW4gc3BlZWQgYW5kIHN1cHBvcnRl
ZCBpbnRlcmZhY2VzIDotKA==

Asking questions this way is unlikely to get a response. I think people are getting burned out on the encoding!

Decoded:

Will the Shield Base support I2C until Feb 2013? In present situation, I need to choose between speed and supported interfaces :-(

Q2hyaXMgd2lsbCBwdWJsaXNoIGEgdmlkZW8gb2YgaGltc2VsZiBzaW5naW5nIERhZnQgUHVuayAt
IEhhcmRlciBCZXR0ZXIgRmFzdGVyIG9uIE5vdiA4IHVzaW5nIHNvbWUgbmV0ZHVpbm8gYmFzZWQg
c3ludGhlc2l6ZXIuDQoNCkRhZnQgUHVuayAtIEhhcmRlciBCZXR0ZXIgRmFzdGVyDQpodHRwOi8v
d3d3LmJpbmcuY29tL3NlYXJjaD9xPUZSQTE4MDUwMTY2MA0KaHR0cDovL3d3dy5nb29nbGUuY29t
L3NlYXJjaD9xPUZSQTE4MDUwMTY2MA==

Now THAT I'd pay money to see!

That was a real thread killer.

Is glass not the best option? I would think it would have low-to-no reaction to the water and - assuming the temperature probe were in direct contract with the glass - it should react fairly quickly to temperature change. Maybe you could just get a long test-tube, affix the sensor to the side near the bottom and submerge. Keep the open end above the water line and cork it. Isn't this how most aquarium heaters are built? For reaction time, I'd try to have the smallest amount of air volume possible - so maybe after affixing the sensor you could use a silicon seal just above the sensor to insulate it from the remaining air column in the tube/vial? This approach should keep everything except the glass completely away from the water for both electronic and fishy health. -Erik