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.
Late last year, we started tinkering with ST's latest silicon...a killer Cortex-M0 chip cut from the same DNA as the Cortex-M4F used on Netduino Go.
We knew that some go!modules would need high-speed throughput and tons of features. The STM8S chip was perfect for low-cost lower-bandwidth modules, and the STM32F2/4 chips were great for running NETMF and for high-end modules. But there was a middle space for modules like Ethernet, SD, and high-speed serial where the cost and power consumption of an STM32F2+ chip was too high.
We evaluated a lot of chips. And this new chip really stood out. We couldn't talk about it until recently because it hadn't been announced. And we didn't want to talk about it because (as we've learned through experience) new chips aren't real until thousands of them show up at our doorstep
That package arrived a few days ago. We're using these chips on the new Ethernet and SD modules, and module builders will be very interested in these as well. 48MHz Cortex-M0, available for <$1 in reel quantity.
Lots of IOs, 12-bit ADCs, PWM, SPI, I2C, USART, and DAC
RTC and battery-backed options, standby/sleep/etc
Capacitive touch support
And more...
Most impressively, the SPI is megabits-fast and has a CRC16 mode that works with DMA. Which will give us the kind of speed we want for high-throughput error-checked data.
Once we finish up the virtual i/o firmware for STM8S, we'll port it over to the STM32F0. For those of you creating early designs for go!modules, I'd recommend sticking with STM8S for now. But if you need high-throughput or lots of power and don't mind hacking away at STM32 code for a while...this chip will be fully supported and we can guide you as to how to hook it up to the go!bus sockets.
Looks nice. And another cheap dev board from ST which has got to help with uptake. In the UK can see the dev board is available at Farnell and there's a book on the Cortex M0, but can't see the IC available via retailers yet. I assume they will be fairly soon though.
Looks nice. And another cheap dev board from ST which has got to help with uptake. In the UK can see the dev board is available at Farnell and there's a book on the Cortex M0, but can't see the IC available via retailers yet. I assume they will be fairly soon though.
Good catch Fred. The 64KB versions just started shipping, 32KB and 16KB should be out soon too.
STM32 Journal Issue 2 (pdf) provides some details about the F0 (Cortex-M0) microcontrollers, including code size reduction comparison table and basic performance chart.
The same author also has a book on the M3 which I found OK to read - not had chance to implement much yet.
I bought the M3 book and found it OK. I can access both the M3 and M0 books via a work Safari Books Online subscription but annoyingly they're excluded from my download allocation.
Nothing in the UK. Anyway - they're so cheap that the transport cost to the seminar would likely be more than the board. You wouldn't do it just for the freebie!
Awesome stuff, deff ordering a few of those
With regards to Ethernet module are there any plans for SSL Client support for initial offering?
As i am interested in either writing a netmf wrapper for polar SSL (as ST have a couple of demo's using it) or seeing if I can get OpenSSL going...
Nak.
With regards to Ethernet module are there any plans for SSL Client support for initial offering?
As i am interested in either writing a netmf wrapper for polar SSL (as ST have a couple of demo's using it) or seeing if I can get OpenSSL going...
8KB of RAM is too small to handle SSL on the Ethernet module, but it's certainly possible to get something like PolarSSL (or OpenSSL) running on the mainboard. We'd have to reduce the amount of codespace from 384KB to fit SSL, but that's not an issue for the majority of applications.
Have you tested the NETMF OpenSSL implementation? Measured how much Flash and RAM it needs? It would be super-cool to get SSL running on Netduino Go. PolarSSL is definitely interesting, but the GPL license makes it a harder sell for some users...
8KB of RAM is too small to handle SSL on the Ethernet module, but it's certainly possible to get something like PolarSSL (or OpenSSL) running on the mainboard. We'd have to reduce the amount of codespace from 384KB to fit SSL, but that's not an issue for the majority of applications.
Have you tested the NETMF OpenSSL implementation? Measured how much Flash and RAM it needs? It would be super-cool to get SSL running on Netduino Go. PolarSSL is definitely interesting, but the GPL license makes it a harder sell for some users...
Thanks for your enthusiasm!
Chris
Hi Chris
Not yet...
Its the next project on my list after I finish off some outstanding personal projects (website, 3axis motor controller, some ND GO tutorials/written up experiments whilst i am familiarising myself with the new platform), and the ND+ based project at work (where SSL would be the KILLER feature for the application, however I may be able to devote some of my "work time" to making that happen and contributing back to the community, if I can convince the MD to switch to GO's for future projects...).
STM32 Journal Issue 2 (pdf) provides some details about the F0 (Cortex-M0) microcontrollers, including code size reduction comparison table and basic performance chart.
If you can also get a free Discovery Kit directly from the STMicroelectronics website. Unfortunately it only seems to be available to anyone in North America. Sorry UK! Discovery kit for STM32 F0 series - with STM32F051 MCU
There should be a "Register for your FREE KIT" button in the Key Features area.
If you can also get a free Discovery Kit directly from the STMicroelectronics website. Unfortunately it only seems to be available to anyone in North America. Sorry UK! Discovery kit for STM32 F0 series - with STM32F051 MCU
There should be a "Register for your FREE KIT" button in the Key Features area.
I signed up for this on Friday and received a shiny new STM32F0 Discovery kit today =D
SPI is great but it requires a selector pin for each SPI device. Call me Mr Silly but if you're building hardware, why wouldn't you use a cheap decoder chip like the 4514 as a sort of address buss so that instead of 16 pins for 16 devices, you'd only need 4 pins? While I can certainly build this myself, it would reach a whole new level of awesomeness if it were directly supported by the built-in virtualisation.It wouldn't be complex to use jumper to determine which of four pins participate in the addressbus. When they aren't controlled they would be pulled low so you could progressively adjust the bitness of the address bus according to need.
SPI is great but it requires a selector pin for each SPI device. Call me Mr Silly but if you're building hardware, why wouldn't you use a cheap decoder chip like the 4514 so that instead of 16 pins for 16 devices, you'd only need 4 pins? While I can certainly build this myself, it would reach a whole new level of awesomeness if it were directly supported by the built-in virtualisation.
Good idea. This could also be done with a 595 shift register, albeit with a bit more latency. That's what we used for the power MOSFET control, so that we didn't tie up 8 pins for the infrequently-accessed power control.
For SPI, we felt that it would be best to use physical pins for each SPI_SS so that we could control them as high, low, high-z, and input pullup/pulldown/disabled. With rapid select/deselect. And to prevent parasitic power to unpowered modules. That may not turn out to be necessary, but we overengineered things a bit to keep our options open (especially with the GPIO/IRQ pins).
I think I need to understand your virtualisation better before I comment further. Certainly if this technique were built up as a module with the SPI bus and 4 digital pins forming a selector bus, it could be treated as a single SPI device for the purposes of writing and the address bus controlled separately. I could wrap the SPI class and add a method SelectDevice(int address) that sets the bus pins appropriately.
Over-engineered - (especially with the GPIO/IRQ pins)
One of the challenges I'm having with some of my modules is the "dance" that needs to take place when the module needs to tell the main board about something.
Module -> IRQ -> MainBoard "I have something for you"
MainBoard -> SPI -> Module "What's Up? and how much do you need to send me"
Module -> SPI -> MainBoard "Message Type XX, payload YYY bytes"
MainBoard -> SPI -> Module "Ok, clock me in your YYY bytes"
Seems somewhat chatty
That statement leads me to belive there might be a better approach to module initiated communications?!?!
Thanks
Kevin...
Kevin D. Wolf
Windows Phone Development MVP
President Software Logistics, LLC
Tampa, FL
That statement leads me to belive there might be a better approach to module initiated communications?!?!
You can make use of the fact that the communication happens in both directions, so the mainboard can receive payload size early enough and can update its data byte counter accordingly to clock out the desired number of bytes from the slave (e.g. BytesToBeReceived += (YYY - PayloadOffset) or something like that). You can use dummy bytes to fill in places where the code needs to get some time for processing, if necessary.
You can make use of the fact that the communication happens in both directions, so the mainboard can receive payload size early enough and can update its data byte counter accordingly to clock out the desired number of bytes from the slave (e.g. BytesToBeReceived += (YYY - PayloadOffset) or something like that). You can use dummy bytes to fill in places where the code needs to get some time for processing, if necessary.
Thanks CW2 - sounds like a good approach. Is there a way I can do this in the standard NETMF SPI class? It seems like the calls "Write and WriteRead" are really atomic and no real way to change the byte counter mid-stream, they are sort-of fire and forget, set the buffers or bytes to read and/or write, then call the methods.
Kevin D. Wolf
Windows Phone Development MVP
President Software Logistics, LLC
Tampa, FL
