It should, with the Hd44780Lcd class.

 

Since the Netduino Plus 2 is so blazingly fast, if you attempt to use this class as-is it will won't work.

 

What you will need to do is hold the clock enable pin high just a little longer rather than just toggling it as was done in the original driver.

 

This happens around line 366 in the _Write4Bits method of Hd44780Lcd.cs.

 

private void _Write4Bits(byte Byte){  	.......	// Enables the pin for a moment        this._CePin.Write(true);        for (var idx = 0; idx < 1000; ++idx) ;                    this._CePin.Write(false);

?

?

?

?

?

?

I haven't experimented too much with the exact number of iterations necessary but 1000 seemed to do the trick.

 

To deploy this you can either update the source code in the tool box and recompile, or just include the file Hd4470Lcd.cs into your project and make the change there.  Either way you'll need to include references for "Toolbox.NETMF.Core" and "Toolbox.NETMF.Hardware.Core" to your project.

 

-twb

The last couple of weeks have been busy with client and family commitments. Over the weekend I had time to assemble NiVek's new electronics and this morning I had a chance to bring the board to life . I've got a little more info on this module on my blog http://www.TheWolfBytes.com but I've attached a few pix. The kewl thing about this module is it snap-ons to the GO! main board similar to the shields on the original Netduino. As you can see in the attached pix, this required the creation of a dev fixture. This allows me to set the jumper for the microcontroller to be programmed as well as connect up a logic analyzer. So far, alll the electronics seem to be working, but time to install it on the quad will probably be limited until this weekend -twb

Here's another update on putting my quad together. In this video, I'm showing the initial test fixture and the methodology I'm using to achieve stable flight. A special thanks to Fabien who "schooled" me on cranking up my SPI clock rate from 166KHz to 667KHz which allowed me to achieve a control loop rate of 5ms or 200 times a second. -twb

Hi Fabien -

The method I used was to put the STM8S into a 'wait for interrupts' mode, waiting for SPI NSS to be asserted, and then retrieved / sent the bytes in a loop using the SPI registers.

Hmmm...sounds interesting, perhaps we can chat about it sometime . It sounds like when the SPI commo is happening, not much else can happen as well?

Guess I'm not so much looking for "real-time" as "real-fast" or even "non-blocking". Just seems sort of a bummer putting the fast processor on hold while the SPI peripheral is doing it's thing.

Very anxious to see the 1.5 stuff...hope it isn't too difficult to retro-fit, I can see the finish line of stable flight with my quad and wanna stay focused!

-twb

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

also check out the dht22, check out the differences: http://learn.adafruit.com/dht

The dht22 looks like a much better fit for what I need with the better accuracy, thanks for sharing!

Hello pdii -

Is there a humidity/temperature module available for the Netduino Go?

I've got a project on deck that will incorporate this into a module, does this one look like it might work for you?

DHT11

-twb

Here's another quick and dirty video of NiVek GO! QC1. In this one, I'm spinning up the four motors on the quad copter although I'm a little timid to try to fly it in the cramped quarters . As noted in the video, I'm seeing a lot of noise in the accelerometer when I power up the motors, but the gyro is clean. Using a complementary filter I'm getting decent attitude readings (pitch/roll), but it's still bouncing around a couple of degrees, if anyone has any suggestions on how to isolate and cleanup the problem, I'd love to hear them Next up is hook in the pitch/roll or error information into the PID controller and see how it flys. Stay tuned! -twb

That is really a cool project. It brings together alot of sensors on top of using wireless to move the data from a main tablet for feedback and supervisory control. I like the Windows 8 tie in also.

Thanks Tombo, it was a lot of fun to put together, in the few spare hours between doing "real-work".

Are the control loops in a fixed timed interrupt ?

The control loop (or really reading the raw data) is initiated by an IRQ from the ITG3200, currently this is at 100Hz, but can probably crank it up a little if necessary. After doing all the math and using the accelerometer to compensate from the gyro's drift, the GO! board is called via an IRQ. Then the GO! board request the processed data and passes it to a different module that uses a PID controller to feed the ESC's that eventually power the motors via PWM. Stay tuned more much more details on this.

Does this thing really fly?

If everything comes together, it looks like I might have some significant time to work on it next week and hope to find out . I'm 100% certain it will fly, I'm just not certain how long it will do so before crashing either way it should be some good video and I've got lots of spare parts!

-twb

Oh, I see why you made your board that size That does stack nicely.

Yeah, turned out kinda cool! I'm working on a design that has female connectors on the bottom of the board so it can "snap on" (of course it would sill be mechanically attached). Any "challenges" you see w/ that?

Really need CW2's STM8 reflashing app to make that one happen though (hint, hint )

-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

See attached jpeg (picture is small to meet file size limits). The Allegro viewer is free. Also this thread may shed some light on the issue. .BRD files

Thanks Chuck - that did the trick!

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?

That's just awesome! Are you considering making a kit of it? I would love to get my hands on such a thing!

Anything is possible

Once I get it 100% I'll figured out I'll evaluate some options and gauge interest. Unfortunately the parts alone are pretty expensive so it’s not going to be all that cheap.

Of course if you want to build your own from scratch, I'll make sure there's a nice write-up, and will make the firmware available. Hand soldering the NiVek control board might be a bit of a challenge though

To wet your appetite, here's a post I did on my progress to-date:
NiVek GO! QC1

-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

I guess I can add my little family's pictures to this thread. I'm building a Netduino powered Quad Copter called NiVek GO! QC1. More details on this to come.

As you can see from Gen1.jpg, my family started out with humble beginnings on some home made PC boards, although this was kind of fun, creating 0.25mm pads for the gyro's was a bit of challenge.

Next came Gen2.jpg, these where some boards I ordered from OSH Park. They have an awesome service where you can upload your .BRD files from eagle and it shows you a preview of what they will look like. They are very inexpensive as well. Pictured in Gen2.jpg is my sensor module w/ Gyro/Accelerometer/Magnometer and Pressure sensors, it also has a 32K EEPROM. Also a WiFi board, a GPIO board that takes PWM as input and provides PWM output to control ESCs for the motors and finally a WiFi and GPS board.

Finally in Gen3.jpg, you can see my combinded board with all the above modules with the shape as the GO! main board. This one sits on top and uses a ribon cable to attach the modules to the GO! board. Next one will use female modular connectors on the bottom of the board to "snap" the modules onto the main board. Sort like the shields for the original Netduino.

I'm actually getting faily close to wrapping up V1 of this, once I do so I'll publish all the HW/SW. Until then if anyone is interested in getting involved and looking at some of my code, PM me and we'll work something out. I might even have a few spare blank PCB's laying around I can send out for you to populate.

-twb

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

Any updates on this? I see the API in place for SetSocketPower and would really love to take advantage of this for failure recovery. Any work around you can think of with the current version? Is the source available for GoBus.dll? Could the update be made there to allow this to work?

-twb

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

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

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

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

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?

I was able to sneak in a little time into this project yesterday and took a couple of _kewl_ pictures. I think the module concept works really well when prototyping the hardware and writing the software, but the final product turns out to be fairly large. In a final version I can see creating one board with multiple processors. -twb

Hi Steve -

I have been anxiously waiting on some progress updates and thought I'd check in to see how things were going. You have some amazing projects "on the Go!" and I'm excited to see what other things you have cooking up.

Unfortunately this projects priority got moved down a bit. With the upcoming launch of Windows 8, a very intersting and what I believe once in a life time opportunity came a long that has been sucking up all my free time .

Saying that however, I did spend a little time on this yesterday and I'm really not that far away. the NiVek GO! copter consists of four boards:
- Sensor Board: ITG3200 3 Axis Gyro, LSM303 Accelerometer & Magnometer, BMP085 Pressure Gauge and a 32K Data logger. I've combined the Gyro and Accelerometer into something that gives very stable Pitch/Yaw and sends that back to the GO! main board. I need write the code to read the pressure (to determine altitude) as well as figure what I'm going to want to log to EEPROM.

- GPIO Board: A standard 5 channel remote control will be used to fly the copter (originally looked at just using WiFi but there was too much latency). This board currenly monitors the pulse width coming in from the RC receiver, it also has four outputs that send PWM signals to the ESC (electronic speed controls) that control the brushless motors. Final task here is to build the PID controller that combines the output from the sensor board and RC inputs to control the motors to produce stable flight.

-GPS Board: Just used to track location, this is pretty much done, my board design/ground plane was incorrect for the PCB antenna, but I got that sorted out.

-WIFI Board: Used to send telemetry from the GO! copter to a Windows Phone/Win8 (see pix of initial WP7 app) flight controller app. Also will be used to do in-flight calibration of the PID algorithm and sensor calibration. This is working but I'd like to get a little better through-put on it.

I've also ordered and received a bunch of manufactured boards from OSH Park to replace my home made ones that will be a little more reliable. Also note in the pictures, the board between the GO! mainboard and my WiFi board, it lets me connect my logic analyzer and ST-Link to help with development.

Once I get all this figured out I'll probably just create one larger board that has all the modules in place.

Anyway - thanks for asking about the status, I was seriously hoping to be flying by now, but oh-well. I have a code camp talk scheduled in September to do a demo so I have a hard deadline.

Finally once I get a little further on in the process I'll make all my "stuff" available to include the source code and Eagle files.

-twb