Building custom go!bus modules for Netduino Go

I would buy a ten-pack for $9.95. Mouser only sells the thru-holes in quantity 990 at $.55.

This would be for populating the JTAG

You can also get non-shrouded through-hole MiniJTAG male headers from DigiKey or Mouser (i.e. non-shrouded sockets). They're much easier to get.

Having a shrouded header for JTAG would be cool though...would make it hard to plug in the cable backwards.

Chris

http://10rem.net/blo...-to-solder-them

That's very thorough Pete. Thanks for sharing this!

Chris

Hi mcinnes01,

Chris in terms of your temperature sensor, is this going to be an air temperature module or a module you can attach certain probes to.

Air temperature. We need to fill out a few basic modules for kits and we want to leave lots of room for community members to participate in this new ecosystem.

I'd also really like to see a breadboard module that allows you to prototype modules accessing all the features of the STM8 or STM32, but with this part of the circuit already done to safe time. Just an idea but it could also standardise the STM circuit on modules.

That would be very cool. We've tossed this idea around. It would certainly be helpful to develop modules...

Last thing, are there any plans or possibilities for usb peripheral support and also are the new boards capable of processing video i.e. from a usb web cam?

Someone could certainly create a USB Host module, although it would be limited by the profiles supported on it. For video, perhaps it makes more sense to create a serial camera module?

Chris

Having a shrouded header for JTAG would be cool though...would make it hard to plug in the cable backwards.

Chris

I got the unshrouded one from Mouser but was thinking that my Very Cool Black Limited Edition NG0 deserved a shrouded one in a contrasting color.

I have started Netduino GO! Module Builder's Guide draft document on the wiki.

I have started Netduino GO! Module Builder's Guide draft document on the wiki.

Oh nice, thanks CW2.

BTW, one thing to remember: most module builder's won't need to know anything about how C code works on STM8S or STM32 microcontrollers. You'll have standard firmware and associated source code that you can use...and flashing the modules will be painless.

Chris

BTW, one thing to remember: most module builder's won't need to know anything about how C code works on STM8S or STM32 microcontrollers.

Good point. I guess this information should be moved into a separate article then.

I got a few unshrouded headers in both through hole and SMD. I'm intending to use them as both JTAG cnnectors and as Go!bus headers for prototyping. They won't look as nice as the shrouded connectors but should work. My initial attempts will be home milled PCBs with no solder mask so looks are not going to be a priority.

Hi everybody, @Pete: thanks for posting, good to know these alternatives. The same for the Go!bus/Gadgeteer ribbon cables would also be interesting. Does anyone have an alternate part number to the expensive Samtec FFSD-05-D-04.00-01-N? Chris, would you mind telling us which part number you use? Thanks! Cory

BTW, one thing to remember: most module builder's won't need to know anything about how C code works on STM8S or STM32 microcontrollers. You'll have standard firmware and associated source code that you can use...and flashing the modules will be painless.

Chris,

What are the plans for making the standard firmware available? Would be good to get sight of this.

Regards,
Mark

Hi Nevyn,

What are the plans for making the standard firmware available? Would be good to get sight of this.

We're working on this now. In order to ensure a high-quality launch for Netduino Go we used custom profiles on the existing STM8S-based modules...using the go!bus spec enumeration, electrical, reflashing, etc.

Now we're finalizing the virtual i/o features that we want to have in the standardized firmware (adding in things such as callback exceptions and time sync for interruptport events). We're using the Shield Base to finish those up.

Then we'll codify it all in an update to STM8S firmware for the current modules, and you can use it on your own custom modules.

We were planning to wait until all of that was signed off on before talking about custom modules...but a few members started on modules the day that Netduino Go launched, so I figured that it would be much better to include everyone in the process and make sure that hardware got designed in a way that will work properly with go!bus and the standardized firmware.

Chris

I'm developing an RFID transceiver (reader/writer) module that supports ISO15693 as well as GPIO (for triggering reads/writes based on external triggers, or notifying other components of tags that are present). The RFID portion has been under development for 2 years and already works well with many tag types - the last little bit is adding the Go!Bus portion. I'm very excited about it.

The RFID portion has been under development for 2 years and already works well with many tag types - the last little bit is adding the Go!Bus portion. I'm very excited about it.

That's pretty cool. How many pins and what types does this require?

Chris

That's pretty cool. How many pins and what types does this require?

Chris

Currently the module we've developed is a standalone RS232 or USB device with a serial command protocol - it's my hope that creating the interface between the go!bus and the reader wont be too difficult. I may be overstating the simplicity (I'm more of a software guy) but I am assuming the interface (using the STM32) will not need to do much more than receive strings via SPI, then turn around and send them to the device via the uart (and vice versa) - this makes a very basic assumption that I can use the SPI bus to send serial data to the module (thats what it is for... right?)

I will need to look over the existing module code that you recently provided, to see what is supported in terms of sending "command strings" to a module synchronously or asynchronously. I imagine we could use on of the GPIO pins on the module to signal that a response is ready, or even that a tag is present, directly back to the gobus.

Too get maximum range, Im also leaning towards an external 12v adapter for the reader module, instead of trying to power it from the Go!bus 5v. I get about 4" range right now, with the antenna I am using. With Fujitsu, Infineon, NXP tags, anyway. I have a small 1cm x 1cm infineon tag type that has 1K of usable memory on it - and I think there could be many fun applications for it.

When you say "what types" are you referring to .Net class types? I've written a full featured .Net class library and sdk for use with the Compact .net framework (WinMobile 5 and 6, anyway), and I will be looking to see how much I can keep when stripping it down for the micro .net framework. The module has a lot of smarts in it - not just a plain transceiver. There are many filtering options, stand-alone operation modes, full anti-collision, etc. The ISO1563 protocol is completely abstracted, the user doesnt need to know any of that stuff.

I am sure there will be details and minor gotchas that pop up to be solved, but I dont see any real obstacles to making this work, and relatively quickly.

Hi mtylerjr, You should be able to connect the UART pins of the STM8S chip to your RFID circuitry and then just set a few settings (like your power consumption and 128-bit GUID). With the upcoming standard virtual i/o firmware...you shouldn't need to write any code on the chip. Chris

Hi mtylerjr,

You should be able to connect the UART pins of the STM8S chip to your RFID circuitry and then just set a few settings (like your power consumption and 128-bit GUID). With the upcoming standard virtual i/o firmware...you shouldn't need to write any code on the chip.

Chris

That's even better! I thought I had read that the uart pins were only to be used for updating/flashing new code, so I thought they might be off limits. That's great!

So what I'm starting to interpret on the traditional (well soon to be traditional) way a go!bus module is built, there is some standard firmware that runs the STMXX chip and these are configured rather than programmed to really extend the individual module to do certain tasks which in most cases is probably talk to the IO pins. I would expect with the small amount of storage on these devices, this really won’t be managed code, but rather native code. One of the things I’ve been really struggling with in moving to NETMF is understanding how things work under the hood to try to get accurate timings for stuff that needs to be done really, really fast. Something I’m currently fussing with is a Netduino doing the “interesting” stuff as well as talking to something else doing something simple, but doing it really fast (think IMU). So saying this, I guess my question is – for these modules tied to the go!bus, is there some sort of standard protocol? Is the end goal for a go!bus module ONLY something running on an STMXX chip with the standard firmware? Or can my XYZ fancy processor play nicely on the go!bus as long as it plays by the rules? I guess all will be answered in time as more info come out. Until then I picked up a few 511-STM8S103K3T6C chips and an STM32VLDISCOVERY board to see if I can do something simple really, really fast and offer up that info on the SPI bus to be picked up by “something TBD” It seems like with the dirt cheap cost of the STM’s and this sort of architecture, we might have the best of both worlds. Writing really simple stuff that needs to be really, really fast on cheap/dedicated STM processors running directly on the metal. Then writing the “interesting/complex/orchestrated” stuff in a language suited for that sort of stuff in a friendly environment - .NET This sort of stuff makes my day job seem sooooooo boring

Hi ByteMaster,

So saying this, I guess my question is – for these modules tied to the go!bus, is there some sort of standard protocol? Is the end goal for a go!bus module ONLY something running on an STMXX chip with the standard firmware? Or can my XYZ fancy processor play nicely on the go!bus as long as it plays by the rules?

We've build the electrical bus in Netduino Go to support a wide range of microcontroller families. We'll provide standard virtual io (go!bus) firmware for a few of them...but you'll be welcome to use your favorite microcontroller as long as your firmware is compliant with the protocol.

And while you'll be able to use the standard firmware to simply configure which pins you want to use from your Netduino Go mainboard, you'll also be able to read/write data to your module via a Stream...and then use your module's MCU as a sort of coprocessor.

It seems like with the dirt cheap cost of the STM’s and this sort of architecture, we might have the best of both worlds. Writing really simple stuff that needs to be really, really fast on cheap/dedicated STM processors running directly on the metal. Then writing the “interesting/complex/orchestrated” stuff in a language suited for that sort of stuff in a friendly environment - .NET

That's the plan.

Chirs

In full disclosure, here are our short-term plans for modules...

In production now:

• Piezo Buzzer

Going into production soon:

• Ethernet
• MMC/SD Card

Short-term modules planned:

• Photoresistor (light sensor)
• Temperature Sensor
• Accelerometer/Compass/Gyro
• Motor/Servo
• XBee

Chris

Can you provide any details on the Short-term modules planned regarding the specific sensors. Curious to see if the sensors would match up with the current Temp/Humidity, Accelerometer/Compass/Gyro I am designing around for the N+ version of Pandora's Box.

Also, I have been finding it very difficult to find SD cards that are 1 or 2 GIG and work properly with the N+. Are there any improvements around the MMC/SD Card for the GO? Have you considered a Flash Based storage Module (Similar to a Thumb Drive without the need for USB support)?

Hi Dave,

Can you provide any details on the Short-term modules planned regarding the specific sensors. Curious to see if the sensors would match up with the current Temp/Humidity, Accelerometer/Compass/Gyro I am designing around for the N+ version of Pandora's Box.

We're selecting the parts right now. Are there any specs you'd prefer to see?

Also, I have been finding it very difficult to find SD cards that are 1 or 2 GIG and work properly with the N+. Are there any improvements around the MMC/SD Card for the GO? Have you considered a Flash Based storage Module (Similar to a Thumb Drive without the need for USB support)?

There are a lot of 8GB and 16GB cards that work with .NET MF (with the patches that KodeDaemon applied). These will also work with the SD module on Netduino Go...and with the virtualization we may also be able to offer SDXC compatibility some day.

I have heard some rumblings of a storage module (EEPROM and Flash both). That would be really cool.

Chris