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.
Good strategy. And there's an STM32F2 in between the STM32F0 and F4...the Shield Base uses this and it hits a "sweet spot" in price/memory.
With my limited knowledge it seems to be the only way to build a module, is the source for the Shield Base available?
The modules should be flashable via go!bus, no special hardware required. And with the upcoming standard virtual I/O firmware, you'll be able to just say "use pins X, Y, and Z on the STM8S for the following features" and no knowledge of C or STM8S architecture will be required. Those pins/features will simply become "part" of the mainboard.
This, also sounds very promising for someone who will never be able to write code for something like a STM8S.
What features will be available, only GPIO pins, or will there also be hardware busses like I2C, SPI (besides what is used for the go!bus), and ?
I'm thinking of building a temp sensor module that uses I2C temp sensors.
This, also sounds very promising for someone who will never be able to write code for something like a STM8S.
What features will be available, only GPIO pins, or will there also be hardware busses like I2C, SPI (besides what is used for the go!bus), and ?
I'm thinking of building a temp sensor module that uses I2C temp sensors.
Yes, you could use I2C. Just attach your temp sensor to the I2C pins and the upcoming standard io firmware will take care of the rest. You'd build your support library (speaking I2C) in C#, running on the mainboard.
Can anyone tell me if I can get the following IO from the STM8S103F2P3's that I have bought.
Alot of my project relies on temperature readings and the first moule I am planing to make is a relay control board. I know a lot of other people will be doing relay control modules but this one doesn't include the relays the idea being you pick your own for what ever it is you are doing. Any way without babbling too much about the spec...
I need 6 logic
2 pwm
and something to make a 1-wire bus (I guess this is serial right can anyone correct me?)
The problem I am having is I'm not sure what is used by the GO bus on the STM and what this leaves to play with even from reading the datasheet.
Is it possible to achieve 1-wire on an STM and is SWIM 1-wire or is this different and is this required for the GO bus?
Thanks in advance for any info you might have.
Andy
PS the 1 wire is for temperature monitoring and I am intent on using ds18b20s as they are really accurate.
Is it possible to achieve 1-wire on an STM and is SWIM 1-wire or is this different and is this required for the GO bus?
SWIM uses one wire, but it is not Maxim/Dallas 1-Wire protocol; it is required by go!bus to support module firmware update. You can implement Maxim/Dallas 1-Wire protocol on STM8 either by bit-banging (on any pin, a little bit more useful are pins marked as 'True Open-Drain'), or using its UART in [rather unusual] Single Wire Half Duplex mode, the generation of appropriate waveforms is described in Atmel's Application Note AVR318.
The problem I am having is I'm not sure what is used by the GO bus on the STM and what this leaves to play with even from reading the datasheet.
The go!bus protocol requires STM8's reset, SWIM, SPI_MISO, SPI_MOSI, SPI_CLK, SPI_NSS and one pin for GPIO/!IRQ. You can check the Netduino GO! Module Builder Guide for more information and have a look at the schematic of the current modules for inspiration.
TX from the GO goes to RX on the on the module and vice versa, admittedly its confusing but if you look at the go schematic you will see pin 4 is TX on the go, so pin 4 on the module would be RX.
i.e. the transmission (tx) from the go on pin 4 is received (rx) on pin 4 of the module, whilst the module transmits on pin 5 and is received by the go on pin 5.
You find the TX to RX naming/wiring convention being used in lots of 2 wire/channel transmission protocols, such as RS232, MIDI, DMX (i think) etc. etc.
It can also help to think of TX = out and RX = in, and that you need to go out to come in
Here is a SMD socket socket library,
http://3ln.org/blog/...-socket-library
Eagle has a 10 pin footprint, con-leotronics 1365-10, but I have not been able to find a through hole shrouded part with the correct pitch.
Baxter
But nowhere can I find the firmware for the special Go Module chips/Go Bus. The shieldbase, which I think is intended to be the development platform for Go Modules, is still stuck in UART land http://forums.netdui...irmware-beta-6/
I am, still, keen to build modules myself. Please help me.
Several people that have developed modules (including Pete, Fabien, Aarron, Matt, etc) are doing it somehow. Although Pete, too, is waiting for Go Bus 1.5 http://forums.netdui...or-netduino-go/
If you check out the blog post pointed to from the above forum post you will find a link to the GoBus 1.0 firmware for the STM82 is in the conclusion of the post.
Sorry, but I make you read my waffle before giving you links to the goodies.
I also realised 2 things: I don't want to program in C and I haven't being paying attention to Chris.
Reading what Chris has written and thinking about it a bit more, I realised that module building is really simple.
1. Build the stuff on top of a shieldbase. Do all the coding, testing, etc. I can do this now.
2. Take the shieldbase + hardware component sandwich (e.g. an Arduino shield) and convert the sandwich into a module.
The shieldbase part of the sandwich is converted to STM chip + cable socket. Pick the right suppliers and the chip, socket and circuit board could be less than $1 to produce. My hardware mess is added to this, and hey-presto, a module.
The unknown for me is the right STM chip - clearly using the same chip as on the shieldbase will definitely work but that is unnecessarily expensive. I don't yet see how to make that choice or do a hardware design. If I knew the relationship between ST pins + Go Bus pins + D1-13, A1-5, then the thing would be easier e.g. stm32f4 PD5 = Socket pin 1 (I am making this up). Is there a spec sheet somewhere for that?
Another chip option is the one used on nwazet's DAQ, stm32f051R8T6. As the DAQ board is available now, it can be used for prototyping. And Arron's proto board. Both chips are cheaper than the f4 one. I guess it depends on the performance. And there are STM's discovery boards.
Clearly Secret Labs has to provide the right firmware. Hence the shieldbase beta testing.
Reading what Chris has written and thinking about it a bit more, I realised that module building is really simple.
1. Build the stuff on top of a shieldbase. Do all the coding, testing, etc. I can do this now.
2. Take the shieldbase + hardware component sandwich (e.g. an Arduino shield) and convert the sandwich into a module.
I suppose that the route you wish to take really depends upon the a few factors:
Complexity of the module
Speed of the module (i.e. sensor you are using etc.)
Target market
For a simple module then the STM8S is a good choice, it is cheap, reasonably fast and the tools are free. The downside as you have noted is that you really need to use C or be adventurous and try assembler . On the upside, the code in the blog post does isolate you from the comms for GoBus 1.0 so you have a starting point. If you go down this route then the VariableLabs module is a good choice - be prepared to learn C. If there is enough interest I'll be happy to make the modifications to make the firmware work with the ProtoModule.
Now consider speed. For a simple module, say a 16-port output module based upon the 75HC595 then you would not need fast processing. You could then take the Shieldbase and distil this down to a single PCB with the essence of the ShieldBase plus the 75HC595 electronics. The downside is that the cost then escalates as the cost of the ShieldBase hardware then outweighs the cost of the two 74HC595s. So for something simple you really need to consider the STM8S route. If you wanted something faster, say driving a WS2811 LED module then you are again back to the custom code in C (even for Shieldbase hardware) as the comms with the chips is time dependent. By distilling the ShieldBase you have removed the need to use C but have introduced a performance hit.
I am following also Mark. I am hoping to build some GoBus modules down the line for Pandora's Box. While we are not running on NetduinoGO but rather the Netduino Plus 2, we plan to add one GoBus port so we can allow people to attach external sensors via the GoBus port.
. On the upside, the code in the blog post does isolate you from the comms for GoBus 1.0 so you have a starting point. If you go down this route then the VariableLabs module is a good choice - be prepared to learn C. If there is enough interest I'll be happy to make the modifications to make the firmware work with the ProtoModule.
