So what I'm starting to interpret on the traditional (well soon to be traditional) way a go!bus module is built, there is some standard firmware that runs the STMXX chip and these are configured rather than programmed to really extend the individual module to do certain tasks which in most cases is probably talk to the IO pins. I would expect with the small amount of storage on these devices, this really won’t be managed code, but rather native code. One of the things I’ve been really struggling with in moving to NETMF is understanding how things work under the hood to try to get accurate timings for stuff that needs to be done really, really fast. Something I’m currently fussing with is a Netduino doing the “interesting” stuff as well as talking to something else doing something simple, but doing it really fast (think IMU). So saying this, I guess my question is – for these modules tied to the go!bus, is there some sort of standard protocol? Is the end goal for a go!bus module ONLY something running on an STMXX chip with the standard firmware? Or can my XYZ fancy processor play nicely on the go!bus as long as it plays by the rules? I guess all will be answered in time as more info come out. Until then I picked up a few 511-STM8S103K3T6C chips and an STM32VLDISCOVERY board to see if I can do something simple really, really fast and offer up that info on the SPI bus to be picked up by “something TBD” It seems like with the dirt cheap cost of the STM’s and this sort of architecture, we might have the best of both worlds. Writing really simple stuff that needs to be really, really fast on cheap/dedicated STM processors running directly on the metal. Then writing the “interesting/complex/orchestrated” stuff in a language suited for that sort of stuff in a friendly environment - .NET This sort of stuff makes my day job seem sooooooo boring

STM8S003 used on Netduino Go! modules does not have it.

Do you know if the source for that firmware has been released anywhere yet?

Now for my question/problem. I spent most of Saturday afternoon trying to get the Netduino and STM8 to have a meaningful conversation. It seems like the conversation starts out fine where the first few bytes successfully get sent over. But after that when I read from the STM8’s SP RX register (after checking the receive buffer empty flag) it seemed to the values got out of step. I’m fairly sure it’s some sort of timing issue...hmmm, thinking about it, was it because I was debugging and screwing up my clocks?!?!?!

For most folks building modules it sounds like the Netduino folks have something way easier...but if you really wanna literaly tinker with the bits this stuff is kind-of fun.

Anyway silly Kevin - I was trying to follow some STM8 sample where in a while loop it spun waiting for register status to change and then do an SPI_ReceiveData(), code got "some-what" nasty .

Tonight I went with an interrupt handler and life is good!

To start things off I need to initialize the SPI Peripheral with settings that match my SPI Master

SPI_DeInit();	
SPI_Init(SPI_FIRSTBIT_MSB, SPI_BAUDRATEPRESCALER_2, SPI_MODE_SLAVE, SPI_CLOCKPOLARITY_LOW, SPI_CLOCKPHASE_1EDGE, SPI_DATADIRECTION_2LINES_FULLDUPLEX, SPI_NSS_HARD, 0x07);
SPI_Cmd(ENABLE);

Then configure interrupts, I configured the SPI interrupt to fire when the receive buffer was not empty.

SPI_ITConfig(SPI_IT_RXNE,SET);

And then finally enable interrupts on my chip

enableInterrupts();

Then in stm8s_it.c I find the handler for SPI which is on on vector 10 and create my handler.

INTERRUPT_HANDLER(SPI_IRQHandler, 10)
{
	u8 ch;
	ch = SPI_ReceiveData();
	SPI_SendData(ch);
}

This simply takes the byte received from the RX buffer and places it in the TX buffer so with the next clock that byte is sent back to the master.

Soooooo much easier then what I was screwing with over the weekend.

Next up I'm going to tackle how I2C works on the chip.

This getting fun!

-twb

Update: 4/24/2012 - My scope was helpful, but I didn't realize how cheap logic analyzers where getting. I had delivered today a Saleaa 8 channel logic analyzer for $150 from Amazon it's incredible what this thing can do! If you're doing any of this sort of stuff, this would be an excellent investment.

Well, I don't think you can really debug (step into) an on-going SPI transmission, even if you were able to press the key fast enough, the keyboard scan rate is way too slow

Thanks CW2, yeah, I kind of figured that . I was just setting breakpoints after all the SPI "stuff" had finished and looking at the data. I't just ocurred to me while posting there might be additional overhead of the debugger that could be getting in the way...I'll fuss with it a bit more next week, it just seems pretty straight foward.

Do you know if all the STM8x's have DMA available for SPI? I read an app note specific for the STM8L on using it. My searches on the topic didn't help all that much.

It felt like Christmas last Friday. I received my GO! along with the Nwazet display and shield base modules. I also received a ton of cool stuff from Mouser to include a variety of STM8x discovery boards, a few STM8 chips and some sockets. My goal for the weekend was to try to arrange all this stuff to build a custom module. My intent is to mount an accelerometer, gyro and compass, write some custom software on the STM8 to do the communications with the sensors as well as processing, then finally make that output available to the Netduino GO! over the go!bus. Of course once I finish with my endeavor, I’ll publish the schematic/board and firmware as open source/hardware.

Setting up the STM tool chain was interesting, but not too bad. There are some good docs on the app notes on the pages for the different discovery modules.

My first goal was to just get a standard Netduino (hmmm…is “standard Netduino” the right term- Chris?) talking via SPI to the STM8 with the STM8 configured as an SPI Slave. It started out pretty promising in that the break-points where firing where I expected in ST Visual Develop (the IDE used to write C for the STM8). Here’s my setup.



Now for my question/problem. I spent most of Saturday afternoon trying to get the Netduino and STM8 to have a meaningful conversation. It seems like the conversation starts out fine where the first few bytes successfully get sent over. But after that when I read from the STM8’s SP RX register (after checking the receive buffer empty flag) it seemed to the values got out of step. I’m fairly sure it’s some sort of timing issue...hmmm, thinking about it, was it because I was debugging and screwing up my clocks?!?!?!

I’ve configured the Master SPI w/ NETMF as follows (with I thought was a very slow baud rate):

            var device1 = new SPI.Configuration(Pins.GPIO_PIN_D10, false, 0, 0, false,true, 200, SPI.SPI_module.SPI1);
            using (var bus = new SPI(device1))
            {
                while (true)
                {
                    bus.Write(new byte[] { 0x02, 0x00, 0x00, 0x40, 0x10, 0xAA, 0xBB, 0xCC, 0xDD, 0x05, 0x09, 0x7f });
                    Thread.Sleep(50);
                }
            }

And setup my Slave on the STM8SVL as such:

SPI_Init(SPI_FIRSTBIT_MSB, SPI_BAUDRATEPRESCALER_2, SPI_MODE_SLAVE, SPI_CLOCKPOLARITY_LOW, SPI_CLOCKPHASE_1EDGE, SPI_DATADIRECTION_2LINES_FULLDUPLEX, SPI_NSS_HARD, 0x07);

Then just a while loop that checks the status of the registers and reads characters from the SPI received buffer.

Any thoughts?

Is the source code for the RGB Led module out there yet? Being a nOOb to writing a SPI slave it seems like from a timing perspective and fast baud rates, a "real" modules we probably need to use DMA?

Help!!!

Kevin…

Will the STM32 reflashing app also work for an STM8? If not, how much work would it be to adapt it?

Hello CW2 -

The application for flashing STM8 modules will be available soon - the basic flashing functionality is done

If you're looking for anyone to beta test this or need any help with this, my email is kevinw@software-logistics.com =D

-twb

Very nice Matt - I needed something like this for status on my current project, now I don't have to create one =D Sign me up! -twb

Hi Fabien - well I was one of the unfortunate souls that attempted to flash my module and ended up with my display in "FlashLight" mode. I 100% understand this early in the process, and this is very much to be expected, it's just the way it goes.

Another method is to solder a 10 position FCI connector to the un-populated JTAG pads on the back of the Touch Display module and flashing the module using STLink-v2 from your favorite compiler from the firmware's source code or using ST's DFU utility using the binary version of the firmware.

Anyway, I took your advice, soldered the connector on the back of the board and have ST Visual Programmer chatting with my display board. Now I just need to get the bits on it. I tried opening the project in IAR Workbench, but got an ARM Toolchain error followed by an invalid project. Converting to run w/ ST Visual Develop (the tool I use right now) seems like it might be a bit more of a challenge then I'm ready for with my current lack of knowledge

So I was able to open and convert the file from the BIN format, to the DFU format and then back to a S19 and HEX format. When I opened these files in STVP, it looks like the 8000000 offset disappeared and I received a "Out of range" message and nothing loaded.

I know this is beyound the "call-of-duty" for the display module support, but any chance you can point me in the direction to get the 1's and 0's from the BIN file onto the metal?

Also if there is anything else I can do to help troubleshoot this effort, I have Chris's flashing software along with the ST-Link2 ready to try "stuff". Let me know.

Thanks

Kevin...

Do you need high data rates on any of these modules?

Not sure on that yet, I suspect I'll go through a few propellers, but hopefully not a lot of fingers figuring that out. My plan is to do the time critical stuff on the STM chips and then send the processed data back to GO! to let it figure out where to hand if off to do the actual control. So I envision lots of really small packets via SPI, I ?think? that will be adequate.

Hi Kevin,

I have a solution for you to get out of "Flashlight Mode"

• Connect STLinkv2 to your PC
• Start STVP and configure it for the STM32F205xE chip
• Load the .hex version of the Touch Display firmware from the repository here (I just added it for you)
• Make sure you're on the "Program Memory" tab in STVP and hit CTRL+P (program current tab / active sectors)

That's it.

Let me know how it goes.

Cheers,
-Fabien.

Simple enough - uploaded the bits to the device and I'm back in business, I'm very much looking forward to playing with the non-blocking touch features later today -

Thanks Fabien!

Kevin...

Excellent! Great work! This is HUGE, it opens up lots of doors! What is the best way to get the bits into the STM32 without bricking it?

ByteMaster--now you have me curious, wondering what you're building

Glad this is up and running for you now. If you need anything else, just holler...there's lots of experience and expertise in the community.

Chris

Hi Chris - yeah, I wish I would have posted this question a while ago I've learned a lot from just going through the forums and reviewing some of the beginnings of what's in the Wiki. As I get more into this I'll start adding some stuff that I've learned.

Well my master plan [insert evil laugh emoticon] is to build a Quad Copter off of the Netduino GO! platform. I started off with a standard netduino and it seemed like I'd be pushing it too hard for the update rates I was looking for. So next I started building some AVR based modules to hang off of the first generation Netduino. Needless to say once you guys introduced the GO! platform my plans did a 180 and started to fall in love with the STM chips and for a lack of a better term an "object-oriented" way of building embedded apps.

Anyway here's my current effort that my wife is getting jealous of all the attention I'm giving it as I'm trying to stumble through putting it together:


Top right is a a GPS module based upon the Wi2Wi chip, this one is getting close, I just need to finish up the SPI dance between the STM & GO! This also as a 256K serial EEPROM for logging location data.

Then a module for either an XBee or a RN-XV Wifi device using an STM8S100F3 to do the buffering and communications to GO! via SPI. Eventually my plan is to just get the SMD chip version of the RN-VX this.

Third down is an RTC module based on the PCF8523 chip...it looks sort of dead without any LEDs but the I2C stuff is working so I just need to tie it back to GO!

Finally the two boards not populated, the one on the top is a simple GPIO board with ADC, PWM, etc.. and the one on the bottom will be my IMU board with a Gyro, Compass/Accelerometer and pressure sensors as well as an EEPROM.

Then of course we have the beautiful LCD Touch Module from NWazet and a few button modules to help with the testing.

I'm on vacation this week so I hope to flush out the hardware and then get some real boards on order from Seeed. Once I do so and if anyone is interested, I'd love to get some help with coding some of this stuff up! I'm not really in a position to do manufacturing of this stuff but I'm certainly going to release these as Open H/W S/W as well as a few blog posts on what I've learned.

Then sometime this summer when the firmware is done, the plan is to build Windows Phone and Windows 8 apps to act as the flight controller. Back in my comfort zone

One thing I did find incredibly helpful on when testing this stuff was getting a few of these extenders from GHI, they work really good to tie into the signals to and from the GO! board.


http://www.ghielectr...log/product/273

Anyway, once I get a little further I'll look at adding some stuff on the Wiki.

-twb

Make sure that you're using the proper "alternate function" that SPI_SS needs. This setting is usually set with the fuses in the third tab of the ST Visual Programmer.

Chris

Thanks Chris, this one costed me at least two hours

On the STMS8S103K3 (32 pin) all the fuses were set properly to have SPI work out of the box. If you are working with the STM8S103F3 (20 pin) you need to set AFR1 = Port A3 Alternative Function = SPI_NSS, Port D .....

That looks great - especially the home-etched boards. That's just the sort of stuff I want to do - once I've finished with a non-Microcontroller project I'm in the middle of.

Yup - it really is a lot of fun. Creating these boards and "plopping" the SMD parts on top of it isn't nearly as hard as it looks. A relatively cheap stereoscopic microscope and a somewhat steady hand is all you need. Definately give it a try!

...Or, you could just wait for Chris' firmware flashing application

I hope this helps.

Cheers,
-Fabien.

Now that wouldn't be hacking now, would it?

Thanks for the detailed write-up Fabien!

I recommend using fixed frame sizes and simply "exchanging packets". That would look something like this:

Thanks Chris - I think I'm seeing a trend pointing to using a fixed size frame...it really does solve a lot of problems at the expense of a few clock cycles and will probably just go down that path.

Kevin...

Chris - can you elaborate what you mean by this?

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...

Thanks Gutworks!

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

I guess most cases will be covered by fixed size frames and for high speed data transfers it will go with DMA (?)

Yeah - I'm starting to think that fixed size frames and potentially a paging algorithm will be the simplest (and probably fastest) way to do this.

I don't ?think? the STM8 line has DMA.

My current approach is just starting to get klunky for a couple of modules where the packet size is variable and I might want to push KB's of data. Starting to think I might want to look at the STM32F0 line with the additional RAM and faster CPU/SPI.

_Really_ looking forwared to the standardized/native firmware, I just don't have enough patience though

Kevin...

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.

Hello Hoquet -

I am trying to communicate with the serial port of my netduino Go shield base. However I've read that the serial ports are not released or working with the Netduino Go. Aside from programming directly the shield base, is there any other work around that I am missing?

Funny you should mention Xbee, I just ordered a few boards to act as an XBee host w/ an STM8S207 processor. These don't use the serial port but are a native GO! module.

I'm not really in a position ot manufacture these, but if you want to have a little fun and assemble your own module, I can get you the .BRD file and you can order some of your own boards. You can get three of them for about $15 and not including the XBee module it's about $10 for parts per board. Nothing too small on this one and is pretty easy to hand solder.

-twb

Thanks Chris -

Very nice, ByteMaster!

Here's a pix of a similar module with a RN-171 WiFi module soldered in place. This is the same module on the underside of the RN-VX WiFi module with the same foot print and pin-compatible with XBee modules.

The firmware is starting to become pretty solid, hope to have all the 'stuff' (H/W & S/W) I'm working on published by the end of August.

-twb

I'm working on a set of modules that can be used with the GO! platform to build a quad copter controlled by a Windows Phone and/or Windows 8 tablet. I originally had hoped to have this done in time to bring to TechEd in Orlando next month but at the rate of my progress and the amout of time I've had for this, flying by then might seem doubtful. If you're heading to TechEd stop by the Windows Phone booth, I'll bring what I have and probably be able to demo at least a few of its features.

This afternoon, I got to a point where the firmware in a couple of modules was stable enough to do a little testing. So far I've been focusing on a module that can host either an XBee/XBee Pro or Roving Networks RN-VX WiFi module as well as a module based upon the Wi2Wi GPS chip.

So I was all excited to test this out in the driveway. Well the software/hardware worked great. The GPS sent an IRQ to the main board and then the main board pulled the latest GPS data from the module. Then it displayed it on the GO! Touch Screen and sent it over to the WiFi module to send back to my desktop computer. I've attached some pictures.

Only one slight problem to dampen success...the GPS chip couldn't find any satellites. I think my board design isn't correct to host the chip antenna. Hope to report some success this weekend on a new board.

The other modules I have in various states of completion are a sensor board with a gyro, accelerometer, magnetometer and pressure gauge. I also have a fairly simple real time clock and a GPIO board with PWM, ADC and other fun stuff like that.

Thought I'd just share some of the success and fun I'm having with the GO! platform. The more I play with it, the more I really like the direction it's heading!

Kevin...

Hello Orange -

What's the board that you had "RN-VX WiFi" on top? What type Socket Type/Protocol does it use to talk to Go?

Right now this module is sitting on top of a home-brew PCB with an STM8S103F and some custom firmware. The mainboard just ships down packets of bytes via SPI to the STM8 chip which in turn sends them thru its on-board UART to be sent out via the WiFi module. If the STM8 reads in a byte from the RN-VX via the UART it queues it up in a local buffer and when either the buffer reaches a certain capacity, or a timeout occurs the module notifies the mainboard it has some data and the mainboard clocks the data and makes it available to the NETMF app.

In the near future I’m going to add the capability that Stefen demonstrated to programmatically pick an access point and configure the security. At this time the RN-VX needs to be programmed before it’s added to the module.

In addition since the STM32F0 chips are so cheap, I might replace the STM8S103F to get a little more RAM for buffering and a faster SPI & CLCK.

Eventually I’ll order up a bunch of PCB’s from seeed and make those available as well as the HW & SW to make this stuff work.

Kevin…