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.
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ł
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.
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.
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?
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.
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.
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).
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
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
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.
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
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.
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
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