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 any of you who might need a 10 pin socket to 0.1" header breakout for prototype module development, take a look at my MakeBread module . The data pins are obviously not labelled the same, but the important ones (3.3V, 5V, and GND) are. If there is enough interest, I would be happy to get a batch made with an updated silkscreen.
In regards to the previous posts on this thread about a prototype module dev kit of some sort, I would love to see a breadboard friendly one.
Another great option; thanks for sharing this with us ransomhall.
are we going to have something similar to this for the go!bus?, at first glance this doc looks awesome.
Something similar, except probably organized on the Wiki and with more design freedom for module builders. Most of the focus should be on interoperability.
Something similar, except probably organized on the Wiki and with more design freedom for module builders. Most of the focus should be on interoperability.
Chris
Good, havent read it all through yet, but there are lot of nice info, which I kinda lack at the moment regarding using shieldbase and stuff, I will find stuff looking through the forums here, so it will work out I guess, but collect stuff at one place would be better (And the wiki, post should be flagged if they are for the atmel series or the st series of cpu'..)
Something similar, except probably organized on the Wiki and with more design freedom for module builders. Most of the focus should be on interoperability.
Chris
I'd prefer a document similar to the Gadgeteer module builder's guide.
I'd prefer a document similar to the Gadgeteer module builder's guide.
We could do that too. Perhaps we can do a short guide (covering the few basic requirements, mostly interoperability-related) and then have a Wiki section for each microcontroller.
This is one of the STM chips Chris said is currently supported on the modules.
Pete
Pete Brown - http://10rem.net (NETMF, C++, Windows, C64, and general geekery) Twitter: @pete_brown I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.
Pete Brown - http://10rem.net (NETMF, C++, Windows, C64, and general geekery) Twitter: @pete_brown I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.
Just wanted to show a preview of my 4-digit seven segment display module. Here's a picture of it running on a breadboard connected to the Netduino Go mainboard:
The hardware is mostly complete, I'm just finishing up a few details with the LED driver at this point. This module is based on the STM8S003F3 microcontroller, the same one used on the RGB LED and potentiometer modules. The firmware and module classes are working quite well and just need to be cleaned up a bit before release.
Here's what the PCB layout currently looks like:
The board is the same height as the RGB LED/potentiometer/button modules, and the same width as the Netduino Go mainboard. I should have some prototypes in within the next week or so, and I'll post some pictures in a new thread as soon as I get those.
Just wanted to show a preview of my 4-digit seven segment display module. Here's a picture of it running on a breadboard connected to the Netduino Go mainboard:
The UART pins are solely used for reflashing modules, and for exclusive-channel support for Gadgeteer "U" modules. We're also using these on the shield base during the beta, in case there are bugs we need to fix (which ensures that they're not NETMF SPI-related).
STM8S microcontrollers are programmed via SWIM, which is basically a single-pin flash-and-debug protocol. You'll be able to reflash your modules via go!bus, or via a SWIM breakout connected to a socket breakout.
Chris,
Just wondering why UART is being used to reflash a module on go!bus and not SWIM.
Just wondering why UART is being used to reflash a module on go!bus and not SWIM.
Good question.
The STM32-based modules are reflashed via TTL UART. For STM8S, CW2 is working on a reflashing procedure which uses the UART peripheral to emulate SWIM. Bit-banging SWIM is also possible.
The makebread looks nice, that one with labels would be way better than the plain one I got from Proto-advantage.
I bought some of these assembled and unassembled. The assembled versions are set up for the Gadgeteer although Eric has indicated that if there is enough interest he will make a GO! Bus silkscreen version. The only real difference is that the socket is set up for Gadgeteer and so the notch points the wrong way. However, if you drop a GO! Bus cable into the socket then the 3.3V, 5V and GND pins are connected correctly.
These arrived this today and this evening I could not resist having a snoop on the GO! Bus. So I set a couple up and wired up the Saleae LA and they worked perfectly.
Next step, move away from the Mini and try to get the Go! talking to the STM8S
I have a few ideas for useful modules but I don’t have the skill to build them, so here are my suggestions. Think of them as more building blocks:
• A micro GO board. Same size as the switch block and just 1 or 2 sockets, full Neduino chip. Ultra low cost, single job board (design based on a stripped down shieldbase or GO board?). Say monitor temperature and then report on it through Ethernet.
• Usb to go!bus. Helps to program the micro GO board, other utility tasks.
• Connector boards(s). 2, 4, 6 or more go!bus connectors. Think of it as a companion to the micro GO board.
Micro GO board + the soon-to-be-released Ethernet module = nanode.
connector board + Micro GO board = Netduino GO.
Micro GO board + shieldbase = Neduino++.
The possibilities are endless!
I really hope that someone in the community takes up these ideas, or is already working on them.
Chris, you and this community have created something brilliant. Do we need another thread on module suggestions?
Jack
I am a relative novice at C# and PowerShell, I understand C less well, and I have a passing interest in electronics. Here's the way I look at this custom module thing:
1) if someone's already built one, I'll buy it.
2) if it's not built, perhaps I'll use C#, NETMF and the STM324F to build it. It's overkill but my time is more valuable than the 5 quid (bucks) for the chip. I'd publish what I'd done openly, hoping that someone else would improve it.
3) If the module had massive appeal, I would get it recoded (if the community had not already) for either the STM32F0 or STM8S chips, depending on processing need.
If I were a electronic designer, or was interested in making money from my designs, I'd go with STM8S first, then STM32F0 and last, and least, STM32F4. I might go for one of the more expensive/full featured processors if I could see in advance that they'd be a better fit for the solution.
I trust the Netduino community to come up with something sensible and easy whatever need I have (like a "simple" way to program and use the STM8S and STM32F0 chips).
What am I missing?
Jack
PS: I read the GHI community's reaction to the Netduino GO. I think they missed the point. Ease of programming, and wide appeal, is what sets the Netduino GO apart.
If I were a electronic designer, or was interested in making money from my designs, I'd go with STM8S first, then STM32F0 and last, and least, STM32F4. I might go for one of the more expensive/full featured processors if I could see in advance that they'd be a better fit for the solution.
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.
I trust the Netduino community to come up with something sensible and easy whatever need I have (like a "simple" way to program and use the STM8S and STM32F0 chips).
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.
