Well guess, I need to chalk this one up as a learning experience.

I was doing all my work in the RXNE (receive buffer not empty) handler for SPI. As soon as I moved my sending code to a TXE (transmit buffer empty) handler it seems like everything is working great.

So bascially in my previous interrupt handler, I needed to do all my work in the one clock cycle between the byte finishing up coming down from MOSI and the next byte coming in, this was just a few micro seconds and the timing was too tight to have it work reliably

With the working approach -
I receive the first character from the master, then when I queue up the next byte to be sent, enable the TXE SPI interrupt. Then as soon as the transmit buffer is empty (which looks like about 25% through the transmission, the TXE SPI IRQ will fire and I can queue up the next byte to be spent with plenty of time to spare. Then when I know I'm done sending data, I just need to disable the SPI TXE IRQ.

Then first thing in my handler I have code to figure out what needs to happen:

	if(SPI->SR & 0x01)
		GO_ProcessByte(SPI_ReceiveData());
	else if(SPI->SR & 0x02)
		GO_HandleTxe();

So far it seems to work.

Hi Mark - Thank you very much for your response!

DOH! I read the priority bits backwards...for some reason I thought a lower number meant higher priority!

Try setting your other interrupt(s) to a lower priority to see if that fixes the problem. In my code,

Saying that, my first attempt didn't resolve the issue . I'll have to play with it a bit more tomorrow.

In the “real-world usage” of the app, it fails very intermittently, about one out of 50 transmissions are garbled, if I just extend the time in the GPIO handler with something like:

//Spin for a while in my IRQ
u16 count = 0x1FF;
while(count-- > 0);

It fails most of the time.

As another test if I do the following in my GPIO handler:

//Spin for a while in my IRQ
u16 count = 0x1;
while(count-- > 0);

There are no corrupted messages, so this really leads me to believe that the time in the GPIO handler is my issue and if I could bounce into the SPI handler life would be good!

Although I don’t have any hard metrics, it seems like about 1 out of 50 transmissions were corrupted before changing the GPIOD IRQ priority, after it seemed like it might have been about 1 out of 200…not sure if that makes sense?!??! I would almost expect it to work…or not.

Oh well, I was being lazy and guess either way I should probably introduce a CRC byte at the end of the transmission.

Kevin…

I'm doing some testing on one of my modules and it's dropping bytes that are sent back to the GO! mainboard via SPI.

Let's say I want to send the following byte array
0x12 0x34 0x45 0x56

What's getting sent back via SPI is:
0x12 0x34 0x34 0x56

I think I've tracked this down the SPI IRQ not being serviced in time to queue up the next byte to be sent.

In addition, from what I can tell this is happening because I'm measuring pulse width on a GPIO interrupt (long story, but can't use built in timer to measure PWM).

From review of the data sheets, I had though I could set the SPI Interrupt to be a priority so it would get called within the GPIO interrupt but it doesn't seem to be working.

ITC->ISPR3 &= 0xDF;

Which should set the VECT10SPR = 01 which would be a Level 1 priority which in turn should let the SPI IRQ interrupt the GPIO IRQ and queue up the next character, (SPI is Interrupt vector 10).

I'm fairly certain I could solve this by moving into the 32 bit world and DMA, but I'm just not ready to make that jump yet beside, I'm pretty sure this should work. I'm currently using an STM8S207K6

Any thoughts? What am I'm issing?

Kevin...

Hello Mike -

With this in mind I was thinking of getting the sparkfun bus pirate as it's quite cheap. Would you say that this is a worthwhile purchase?

I really don't know too much about the bus pirate, but it looks like it only has one 10PIN connector on it. It might make it a little hard to interface. I guess you could put it in another socket on the same SPI port of the main page, but I use the SPI SS line to do the triggering so different socket wouldn't really work there.

Another option is the Saleae Logic Analyzer it's is a little more expensive, but I've found this thing invaluable for doing development. I'm sure it's saved me countless hours and easily paid for the $149 cost. I like that the eight lines that can be configured independently to measure/trigger off of SPI/I2C/RS232 etc...


Also their software really rocks! I love the feature that lets me check the timing/frequency of the signals.

In fact, I created a little "Man-in-the-Middle" board I've attached to this post that sits between the GO! main board and module with dedicated pins to connect to the analyzer and show SPI info. On a side note this also has a 4 pin JST connector for programming and a LED for showing IRQ status back to the main board. At some point I'm might make these available if there is enough interested.

Kevin...

Hello Chris -

What scenario(s) would this feature be useful to you? We're working on an update to the mainboard and GoBus assembly...so any/all feedback and requests are very timely.

I can think of two scenarios where this might be useful:

1) From a module builders perspective, if my module starts behaving badly it would be nice to toggle power to do a full reset. In some case it would be nice to toggle power to the module to reset peripheral chips in addition to just resetting the uC.
2) From a app perspective, in some cases it might be nice to shut down unused modules to save power

Kevin…

What exactly is this method supposed to do? It looks like it works fine during program startup, but from what I can tell, if I call it later on in the application lifecycle, calls to disable/enable power to a module are ignored. Am I missing something? Thanks Kevin...

Hi Chris -

I'd recommend morse code--there's even a morse code to text interpreter on the Projects page--but that might be a big slow.

Hmmm...sounds like a very interesting project! Must...resist...too many tangents already coming out of my primary effort

Something I might tinker with...I created some common libraries for handling the GO!/Module communication w/ IRQ & SPI. I have a range of messages for system type calls. I think I'll add one with the following exchange:

MODULE->GO : I got something for you!
GO->MODULE : Ok, what is it now?
MODULE->GO : It's a message type XX, and a bunch of characters, will you please send them to your Debug Console?

Obviously this isn't performance happy, but should get the job done and shouldn't be too bad in small doses.

Kevin...

I've got a number of modules up and running which I'll put out some additional information once everything comes together. Right now I thought I'd just let everyone know my favoriate STM8S varient.

Right now my favorite varient is the STM8S207K6T6C it's cheap at $2.50 with a minimum qty of 10. It has a nice 32 pin package with a 0.8mm pitch which is easy to solder and create your own boards to host. It has plenty of storage with a 32K EEPROM, 6K of RAM and a 1K EEPROM. It also runs at 24MHz so it's a bit faster.

For the most part it's pin compatible with the STM8S103K6 and has the same foot print, but you also need to connect up pin 7 to VDD where you don't with the STM8S103 (trust me...that one cost me about 2 hours thinking I had a bad chip/board). Also to use I2C on the STM8S207 you need to set the alternate function for AFR6 to IDC (trust me again...that one costed me 4+ hours of scratching my head).

What is everyone else using for an 8 bit uC? Anyone else have any experiences (good or bad) to share with different 8 bit controllers?

Kevin...

I don't think this is possible

Thanks CW2 - that's what I sort-of figured.

Sorry if this isn't the right forum, but I've looked and I can't find any mechanism to write any data from my STM8 app into the debug log in either IAR Workbench or ST Visual Develop. Is this even possible? Kevin...

Hi Dave -

Curious as to what Quad Copter hardware you are using. I've done some research and there are many out there and many different types of frames from Carbon Fiber to Aluminum to Simple Tube Frame. Curious what you went with and why.

-Dave-

I've attached a picture of what hardware will probably be used for my maiden flight, however I'm fairly certain I'll end up with a different platform. It's made out of laser cut plywood and is pretty light but the quality just isn't there. Seems like it will break pretty easy and some of the alignments on the arms is a bit off. I'll probably end up doing something custom...I'm thinking a stealthy, "black-helicopter" carbon fiber theme.

It's using some brushless motors and ESC's. All this stuff I got at Hobby King. Once I get it all put together I'll do a blog post on the pro's and con's of the approach.


Kevin...

Hi Carb -

Very interesting you considered using Bluetooth and a cell phone. About 5 years ago I put something together that actually worked fairly decent with my NiVek JD project so I can assure you it's actually a valid approach

Are you by any chance working on a Blue Tooth Go Module?

Right now I'm not specifically working on a Bluetooth module, but Seeed offers a Bluetooth bee that could plug into the board I'm creating or you could take a look at what Stefen did to configure WiFi support and potentially get something going a little sooner. Obviously you would have to change software on the GO! side, but the hardware configuration would be similar.

Good luck and let us know how it turns out!

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…

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

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

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.

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

Hi CW2 - not really sure what's different but I went in with a clear head tonight and was able to get TIM2 to work just fine?!?!?!?

Could you please show your code for TIM2? There are more differences between TIM2 and TIM4 (16 bit vs. 8 bit, prescaler range, interrupt vector etc.).

Anyway, here is my code:

	TIM2_DeInit();
	TIM2_TimeBaseInit(TIM2_PRESCALER_128, 0x7D); /* Each tick should be a MS */
		
	TIM2_ITConfig(TIM2_IT_UPDATE, ENABLE);		
		
	TIM2_Cmd(ENABLE);			

With a 16MHz clock this should yield a 1ms period (which I've verified on my scope).

Then since I've configured the interrupt to fire via the timer Update TIM2_IT_UPDATE, the following interrupt handler gets called every 1MS

INTERRUPT_HANDLER(TIM2_UPD_OVF_BRK_IRQHandler, 13)
{
  TIM2_ClearITPendingBit(TIM2_IT_UPDATE);
  /*Do something interesting*/
}

Of course as Matt said, somewhere in your code you need to enable interrupts:

enableInterrupts();		

And since I'm using the standard libraries the files must be added to your project:

stm8s_tim2.h
stm8s_tim2.c

I still need to grok using different channels, especially on TIM1, but getting this timer working moves the ball down the field a little further.

Kevin...

Are you enabling interrupts? If you are using the ST standard peripheral libraries, you can enable interrupts with:

enableInterrupts();

Thanks Matt - I am enabling interrupts and can successfully get them to fire with TIM4, just not with TIM2?!?!?!? Assuming it has something to do with TIM2 having three channels and TIM4 only having one. I'll have to play around a bit with it a little later.

I'm actually using it to do some internal timing on buffering/sending data back to the main board, but PWM is a future task, so thanks for the code.

Kevin...

I often have ST-LINK/V2 connected through a different socket, wires directly plugged into the IDC cable header, I call it "a poor-man's SWIM adapter"

CW2 - Got-it...pretty cool!

Using a different socket, I assume you couldn't have another STM8 on the same side of the GO!BUS, correct? Or unless I'm missing something, you would end up programming two devices or at least get some serious issues with both chips on the SWIM line.

Hmmm...I'll bet you could also use the break out board that I'm using to connect to the logic analyzer, between the main board and the module, and hookup the ST-Link V2 up to that. This would allow us to leave the programming connector off our module! Way kewl!

Might be worth it to get some boards made up similar to...

...but with a socket to plug in the ST-Link V2. Would be a really good way to do development. All sorts of pins to connect a logic analyzer as well as program the device. In this case, you wouldn't tie those lines back to the main board and could have multiple STM8's without having to worry about bus contention.

Great H/W design here on the GO!Bus!!!

Kevin...

Thanks Matt -

This wiki page details most of the hardware/electrical requirements for STM8S-based modules:
http://wiki.netduino...ders-Guide.ashx

This looks like a great asset!

Pin 4 should be connected to SWIM and pin 5 should be connected to NRST

We probably have to assume that those lines are not Hi-Z, so durring development with the ST-Link2 attached, they should be disconnected? I guess a good approach would be cutting those lines in the 10 pin ribbon cable.

Kevin...

What connections are necessary between the GO!Bus and the STM8 to reflash the module similar to the STM32?

Hello Parag

I want to use NGO to develop a sensor platform for a near-space balloon. This will include multiple temperature sensors, pressure sensors, gyros, along with serial interfaces to a GPS and radio modem.

Sounds like a very interesting project!

I'm actually working on a sensor module with the following components:
L3G4200D Digital Gyro
LSM303DLHC Accelerometer/Magnometer
BMP085 Pressure/Temperature Guage
32K Serial EEPROM

This is hosted with a SMT8207K6 chip.

I've attached a pix of my sensor board, it's 60mm x 60mm, I think the final version will be 50x50 so I can order on Seeed

I'm also working on a couple serial/communications boards.

I'm not really in a position to mass-manufacture these, but I can probably make a few extra and make them available to cool projects like the one you are working on.

Also at this point it's my plan to release the details as Open H/W & S/W so you could always make your own.

If you are interested, send me an email.

Kevin...