Netduino home hardware projects downloads community

Jump to content

The Netduino forums have been replaced by new forums at This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.


Member Since 25 Feb 2012
Offline Last Active Apr 18 2014 12:13 AM

Topics I've Started

Async SPI on GO!

03 September 2012 - 02:54 PM

I have a timing critical application built on the GO! platform. One of the bottle necks I'm running into is communicating with my modules via SPI. I'm using the "old-fashioned" B) STM8S where an interrupt handler processes the slave's incoming SPI, not one of those "new-fangled" STM32F0 chips with DMA and megabit SPI. Anyway, I might have some possibilities to tune the interrupt handler but it seems like if I run SPI faster than 166KHz, I'm getting corrupted messages. One of my modules sends about 120 characters to be relayed via WiFi, this is taking 3.5ms. Since I'm assuming that the processor really isn't needed full time to send out these characters, I'm wondering if there is any sort of async way to queue up and send a byte buffer to a module. In this case, it could be fire-and-forget, however it also might be nice to get a call back for some other things I'm doing with the response buffer. This would also get interesting since from what I understand there are to SPI channels, each serving 4 GO! bus modules. I love the module approach with the GO! platform, but for communicating in a real-time basis with the modules is starting to seem like it's becoming neck. Thoughts? -twb

NiVek GO! QC1

13 August 2012 - 07:34 PM

As many of you know- in my spare time (which seems to become a valuable commodity) I've been working on a Netduino GO! based Quad Copter.

I've done a full writeup on my blog The Wolf Bytes and my plan is to do a full series of all the "stuff" H/W and S/W that goes into this as blog posts. When I have some faily major progress I'll update this topic and if anyone has any questions on how this stuff works, please ask them here or send me an email at My plan is eventually to release all the H/W and S/W as open source, but I'm also considering some alternatives to sell kits, at least for the electronics.

Thanks to Steve Bulgin (beter known as Gutworks) I was able to figure out how to post a quick and dirty video (read as: one take and no editing) to the forum.

In addition, I've attached a picture of the piggy-back board for the GO! main board that contains a few STM8S207's that power the sensors and the flight controls.



GO! Board Layout

12 August 2012 - 12:36 PM

I want to design a board that has the female 10 pin GO! bus connectors on the bottom of the board so it can "snap" on like the shields on the first gen Netduinos. I'm not able to open the .BRD file, probably since I just have the hobby version of Eagle. Has anyone opened these files and know the exact center location of each of the male GO! bus connectors on the main board?

SPI/I2C Conflict

30 July 2012 - 09:04 PM

I've been fighting with an issue most of the day and I'm hoping that someone here can help me.

I have sensor board where I'm pulling I2C data from a gyro every 10ms, I'm then triggering an IRQ to the GO! board for the GO! board to pull the data via SPI. Most of the time this works great. The challenge is when GO! board is busy and doesn't get around to handling the IRQ for a while and does so when the module is pulling the next data from the gyro. When this happens it appears as if the I2C line will ignore setting the stop condition and my gryo jumps the tracks and kills the I2C bus by keeping the line low.

The SPI communication is done via an interrupt handler and the I2C is initiated by a GPIO IRQ, but just bangs out the I2C communcication sequentially (doesn't use an IRQ). I did set the GPIO IRQ priority lower so it wouldn't interfere with the SPI communcations.

Here is the offending I2C code, note that TWB_GO_GetState() is used to determine if SPI communications is occurring. If so we just spin until we go back into an idle state.

	while(_rxBytesToReceive > 0) {
		if(TWB_GO_GetState() != GO_STATE_Idle) {
			if (_rxBytesToReceive == 1){
				/* Disable Acknowledgement */
				/* Send STOP Condition */
				/* Poll on RxNE Flag */
				while ((I2C_GetFlagStatus(I2C_FLAG_RXNOTEMPTY) == RESET));
				//while (I2C_GetFlagStatus( I2C_FLAG_TRANSFERFINISHED) == RESET) {}
				/* Read a byte from the Slave */
				_rxBuffer[_rxBufferIdx++] = I2C_ReceiveData();					
				/* Decrement the read bytes counter */
			else if (I2C_CheckEvent(I2C_EVENT_MASTER_BYTE_RECEIVED) ){
				/* Read a byte from the I2C Bus and stuff it in the buffer*/
				_rxBuffer[_rxBufferIdx++] = I2C_ReceiveData();
				/* Decrement the read bytes counter */

I know from my logic analyzer that the code with one byte left runs, and blocks on the SPI being active (can tell by the NAK). If you look at the attached capture from the logic analyzer, you can see the I2C lines are low until the SPI communication is done, then you can see the I2C line clocks in the last byte and sends a NAK. The problem is it doesn't send the stop condition after the NAK, it looks like it want's to clock in another byte and this apparently is confusing the heck out of the gyro.

Did that make any sense at all?!?!?!?


Getting Started with 32 Bit

18 July 2012 - 10:06 PM

There seems to be a wealth of knowledge and opensource/free tools for STM8 development, but most roads I started down to play with the STM32 without shelling out a non-trivial amount of cash are leading to a dead-end or 30 day trial. Can anyone recommend anything?

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.