ByteMaster

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

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 kevinw@software-logistics.com. 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.

Enjoy!

-twb

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?

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) {
			TWB_Sleep(1);
		}
		else{
			if (_rxBytesToReceive == 1){
				/* Disable Acknowledgement */
				I2C_AcknowledgeConfig(I2C_ACK_NONE);		
	
				/* Send STOP Condition */
				I2C_GenerateSTOP(ENABLE);			
	
				/* 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 */
				_rxBytesToReceive--;
			}				
			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 */
				_rxBytesToReceive--;
			}		
		}

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?!?!?!?

Help!

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?