Netduino Go! and I2C - Netduino Go - Netduino Forums
   
Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Netduino Go! and I2C


  • Please log in to reply
20 replies to this topic

#1 2xPa

2xPa

    New Member

  • Members
  • Pip
  • 2 posts

Posted 19 December 2012 - 01:59 PM

Hello all,

For a prototype i work, or rather i attempt to work, i need to connect two devices over I2C (9-axis sensor and RTC clock, to be precise), and thus i wonder is it possible to use .NETMF I2CDevice while working with Netduino Go! by connecting to I2C2 pins on Go!Socket1 and Go!Socket8?

If no chances to get that to work what would be the best way to go? If developing separate module, personally i find it a huge overdo, what would be the best place to start? So far i found few resources:
- http://forums.netdui...sing-the-stm8s/ but that's for go!bus 1.0, will that code work on 1.5 as well?
- what would be best hardware start point:
  • VariableLabs ProtoModule?
  • STM8 or STM32 Discovery board?
  • other?

is there any complete jumpstart guide to module development, as so far i've seen it scattered over web?
Just to mention, I'm .Net software developer, without prior experience with micros.

Regards and thanks in advance for tips and answers
Paweł

#2 Nevyn

Nevyn

    Advanced Member

  • Members
  • PipPipPip
  • 1072 posts
  • LocationNorth Yorkshire, UK

Posted 19 December 2012 - 04:20 PM

For a prototype i work, or rather i attempt to work, i need to connect two devices over I2C (9-axis sensor and RTC clock, to be precise), and thus i wonder is it possible to use .NETMF I2CDevice while working with Netduino Go! by connecting to I2C2 pins on Go!Socket1 and Go!Socket8?

I do not believe that this will work as non of the Go sockets are connected to I2C pins on the Go Board.

- http://forums.netdui...sing-the-stm8s/ but that's for go!bus 1.0, will that code work on 1.5 as well?

From what I understand, if you develop a Go Bus 1.0 module you will still be able to connect it to the GoBus when version 1.5 of the protocol is released. This was confirmed in this post about the 1.5 protocol.

- what would be best hardware start point:

  • VariableLabs ProtoModule?
  • STM8 or STM32 Discovery board?
  • other?

I have used the first two of these and I also put together my own development rig. This contains the STM8S103 I am targeting along with a few other components.

is there any complete jumpstart guide to module development, as so far i've seen it scattered over web?

You can find several resources here in the forums as well as in the Wiki (Have a look at the Netduino GO! Module Firmware Development post). I have also been writing a number of posts titled The Way of the Register. These are targeted at the STM8S platform and discuss how to work with these chips. I'm working my way through the feature set for this microcontroller and trying to give a small tutorial on each feature. BTW: I2C is one of the next items on the list :)

Hope this helps,
Mark

Edit: Found confirmation from Chris Walker that 1.0 and 1.5 modules will work on the same bus. Added link to post.

Edited by Nevyn, 19 December 2012 - 04:36 PM.

To be or not to be = 0xFF

 

Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life

Follow @nevynuk on Twitter


#3 Arron Chapman

Arron Chapman

    Advanced Member

  • Members
  • PipPipPip
  • 289 posts
  • LocationOregon, USA

Posted 20 December 2012 - 09:06 PM

- what would be best hardware start point:

  • VariableLabs ProtoModule?
  • STM8 or STM32 Discovery board?
  • other?


I of course am a fan of the ProtoModule, but as I sell them, I'm certainly biased. A simple alternative though might be the shield base.

When you talk EE use small words, I'm just a Software Developer :)
My Blog/Site and Everything Else

If my post helped you please consider pressing the "Like This" button in the bottom right-hand corner.

 

Oh my. So many things, so little money!!

 


#4 2xPa

2xPa

    New Member

  • Members
  • Pip
  • 2 posts

Posted 15 January 2013 - 09:22 AM

if it comes to STM32 Discovery, do you find it reasonable to build prototype module on it running .NET MF as described in http://singularengin...microframework/?

 

@Arron

can you provide an estimate time and cost of delivery to Poland?

can you share sample code communicating over Go!Bus?



#5 Arron Chapman

Arron Chapman

    Advanced Member

  • Members
  • PipPipPip
  • 289 posts
  • LocationOregon, USA

Posted 17 January 2013 - 12:37 AM

@Arron

can you provide an estimate time and cost of delivery to Poland?

can you share sample code communicating over Go!Bus?

 

Orders shipped the the UK and Norway both took about 10 days.

The best source for info on Go!Bus is Mark Steven's Blog Posts on the subject, along with the protocol spec.

Myself and others are working on simple base implementations of GoBus on the 8S that will make for good starting points for firmware.


When you talk EE use small words, I'm just a Software Developer :)
My Blog/Site and Everything Else

If my post helped you please consider pressing the "Like This" button in the bottom right-hand corner.

 

Oh my. So many things, so little money!!

 


#6 Nevyn

Nevyn

    Advanced Member

  • Members
  • PipPipPip
  • 1072 posts
  • LocationNorth Yorkshire, UK

Posted 17 January 2013 - 07:06 AM

The best source for info on Go!Bus is Mark Steven's Blog Posts on the subject, along with the protocol spec.

Myself and others are working on simple base implementations of GoBus on the 8S that will make for good starting points for firmware.

The article in the blog post mentioned is an implementation of the GoBus 1.0 protocol and it works for me on the relatively simple projects I am working on.  It currently works for the STM8S103F3 and the STM8s Discovery board.  I'm sure it will work on the Protomodule and other chips in the STM8S range.  In fact I think Arron has it running on the Protomodule and I will eventually get around to making the modifications but as always time is against me.

 

Chris has already stated elsewhere in the forums that GoBus 1.0 modules will continue to work with GoBus 1.5 and I believe 2.0 so if you use this code then it should continue to work for the foreseeable future.

 

Hope this helps,

Mark


  • Arron Chapman likes this

To be or not to be = 0xFF

 

Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life

Follow @nevynuk on Twitter


#7 neslekkim

neslekkim

    Advanced Member

  • Members
  • PipPipPip
  • 350 posts
  • LocationOslo, Norway

Posted 23 January 2013 - 12:33 PM

regarding stm8 firmware, was the source for the go-modules, rgbled and so on, ever released?


--
Asbjørn


#8 Lunddahl

Lunddahl

    Advanced Member

  • Members
  • PipPipPip
  • 152 posts
  • LocationEurope, Denmark

Posted 23 January 2013 - 08:55 PM

I have them, but i seem to remember that someone gave them to me in chat, the file is called FirmwareSource.zip

 

I have no clue if they are official released and that's why i'm not posting them here now.

 

- Ulrik Lunddahl



#9 Arron Chapman

Arron Chapman

    Advanced Member

  • Members
  • PipPipPip
  • 289 posts
  • LocationOregon, USA

Posted 23 January 2013 - 09:19 PM

I have them, but i seem to remember that someone gave them to me in chat, the file is called FirmwareSource.zip
I have no clue if they are official released and that's why i'm not posting them here now.
- Ulrik Lunddahl
 

That would have been me :)
 
 

regarding stm8 firmware, was the source for the go-modules, rgbled and so on, ever released?

 
I just got permission to post the firmware.  I'm not going to post it on the wiki just yet because it includes the firmware for several modules in a single IAR Workspace so it doesn't quite fit on any one page well.
 
The attached FirmwareSource.zip contains the source for the RGB LED, Potentiometer and Piezo modules.
The attached FirmwareBinaries.zip contains pre-built binaries for the same modules.

 

These are the firmware versions that are currently shipping with these modules, to the best of my knowledge.

There is a bug in each of them, to do with the way the module GUID is sent, I don't recall the fix off hand but I'll ping a couple people who know it and I'll get updated ZIPs posted.  Look for an edit to this post when I do.

 

These are Go!Bus 1.0 Firmware versions.  The current version of Go!Bus is 1.5, however it is backwards compatible.  Go!Bus 2.0 is currently in the works and will still be backwards compatible with Go!Bus 1.0.

However, I personally recommend building for Go!Bus 1.5, for which you can get the spec doc to work from.

Attached Files


  • Gutworks likes this

When you talk EE use small words, I'm just a Software Developer :)
My Blog/Site and Everything Else

If my post helped you please consider pressing the "Like This" button in the bottom right-hand corner.

 

Oh my. So many things, so little money!!

 


#10 neslekkim

neslekkim

    Advanced Member

  • Members
  • PipPipPip
  • 350 posts
  • LocationOslo, Norway

Posted 23 January 2013 - 09:27 PM

Thanks!!

 

The code do seem to be very easy to understand, wonder how much different 1.5 and 2.0 code would be.


--
Asbjørn


#11 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 23 January 2013 - 10:02 PM

There is a bug in each of them, to do with the way the module GUID is sent, I don't recall the fix off hand but I'll ping a couple people who know it and I'll get updated ZIPs posted.

Well, I would be rather interested in knowing that fix  ;) (and I don't mean it ironically).



#12 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 23 January 2013 - 10:23 PM

Hi neslekkim,
The code do seem to be very easy to understand, wonder how much different 1.5 and 2.0 code would be.
The enumeration is the same. There will be a bit more structure around the frames and error correction...and of course the standardized profiles. CW2 has done a pretty nice job getting the firmware running on the initial STM8S modules. (clapping) Chris

#13 neslekkim

neslekkim

    Advanced Member

  • Members
  • PipPipPip
  • 350 posts
  • LocationOslo, Norway

Posted 23 January 2013 - 10:27 PM

Profiles, what is that really?, when it comes to the actual code? any examples ?


--
Asbjørn


#14 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 23 January 2013 - 11:30 PM

Hi neslekkim,
Profiles, what is that really?, when it comes to the actual code? any examples ?
Profiles are sets of functions that pertain to a certain set of features or MCU feature, such as the SPI profile and the UART profile and the device profile. We are using temporary profiles in the current Shield Base firmware. You can grab that source if you want to get an idea of where we're heading. We're now working on formal standard profiles which can be used by any module (and therefore work with the standard NETMF SPI, SerialPort, InputPort, etc. classes). Chris

#15 neslekkim

neslekkim

    Advanced Member

  • Members
  • PipPipPip
  • 350 posts
  • LocationOslo, Norway

Posted 24 January 2013 - 01:04 AM

I tried to read some of the shieldbase code earlier, but it was kinda complex, the stm8 code is much easier to follow, at leat the ones above here, when all kind of functionality is implemented it's kinda hard to find out what is what, and from what I understand, most of the shieldbase code is based on .net, but stm8 is pure c/c++ code.

The nwazet code seems easier in that way, since that is also c/c++, not .net.


--
Asbjørn


#16 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 24 January 2013 - 01:23 AM

neslekkim, Good point. The GoBus protocol allows a range of sophistication in the module. Basic modules can support just one basic profile (such as ADC or GPIO) and single frame communication (i.e. request, ack, response, request, ack, response). Sophisticated modules can support dozens of profiles, multi-frame communication (for fast streaming of data), etc. This enabled simple inexpensive modules (for things like RGB LEDs and Ambient Light sensors) as well as sophisticated modules (like displays and I/O expanders with lots of features). Chris

#17 Nevyn

Nevyn

    Advanced Member

  • Members
  • PipPipPip
  • 1072 posts
  • LocationNorth Yorkshire, UK

Posted 24 January 2013 - 08:15 AM

Chris,

 

Can you expand on this a little:

 

Basic modules can support just one basic profile (such as ADC or GPIO) and single frame communication (i.e. request, ack, response, request, ack, response).

 

Given the fact that the implementation of the module code leaves the meaning of the packet content to the developer I would have thought multiple profiles (GPIO etc) are down to the developer.  You could talk to a simple module such as a LED/simple sensor or you could use UART, ADC and GPIO to talk to multiple sensors.

 

As for multiple packets, then again, as the implementer has some freedom to define the packet contents and how they are interpreted then I would have thought that multipacket frames should be possible.

 

I thought that GoBus 1.5 and above give you this stuff for free.

 

With GoBus 1.0 you can do this but it is down to the developer to write all of this code themselves.

 

Regards,

Mark


To be or not to be = 0xFF

 

Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life

Follow @nevynuk on Twitter


#18 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 24 January 2013 - 02:15 PM

Hi Mark, You can go either way. By default, GoBus firmware will directly map peripherals to profiles. If a module developer wants to insert custom logic, they can go the extra step and do that. For instance, by default an RGB LED module will expose 3 PWM profile instances. That will represent 3 PWMChannels to the C# driver code, and the C# driver will then wrap those up in a .SetColor(...) method for the user. But the user will still be able to reflect into the 3 PWMChannels if desired. Similarly, the Ambient Light sensor module has an I2C-based dual-band sensor. The C# driver will retrieve that data using the I2C profile, and will then calculate the two values (IR-only and Visible+IR) into a single Luminosity result for the user. The user just calls .GetLuminosity() and then the driver fetches the data via virtual I2C. But if someone wanted to reprogram the Ambient Light sensor module so that it had a single ADC profile instead--returning a single value representing luminosity--they could do that. The calculations to map the two sensors to one value would live on the module. When the module received the ADC profile's GetValue request, it would return the single value. This value could be calculated automatically during idle time by the module or in real-time in response to the ADC GetValue request, if it was fast enough. For most module developers, we'll recommend mapping the peripherals directly. And then putting all the logic in the C# driver code. But for some modules, it will be nice to add extra logic on the modules themselves. And in some cases, such as Komodex's 7-segment display, it's imperative to put some of that logic on the module itself--since it's not appropriate nor would it provide good results to constantly refresh the 7-seg's LEDs multiple times per second from NETMF. Chris

#19 Lunddahl

Lunddahl

    Advanced Member

  • Members
  • PipPipPip
  • 152 posts
  • LocationEurope, Denmark

Posted 24 January 2013 - 11:12 PM

If i layout a RGB module on a breadboard and manage to make a special edition firmware, is there any way to update/reflash existing modules:

 

1. Via a program running on the Go, like the reflasher program for the shield base.

2. Via a custom GoBus to programmer cable.

 

Or are the STM8 MCU flashed before  they are mounted ?

 

- Ulrik Lunddahl



#20 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 25 January 2013 - 12:26 AM

Hi Ulrik, We flash the modules after they're fully assembled. We use an ST-Link/V2 connected to a GoBus breakout. We're experimenting with an STM8S reflashing utility as well. One of our community members has generously put in a bunch of effort and built some early support; we'll share more on that later with his permission. Please note that there are two variants of the STM8S: STM8S0 and STM8S1. The STM8S0 chips are much less expensive and make it possible to have inexpensive $7.95 modules like the potentiometer and piezo buzzer modules which may be updated once or maybe twice in their lifetime. The STM8S1 chips are great for development, since they can be reflashed 10,000s of times...and also for modules which are going to see a lot of in-field updates. Chris




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.