Hi Chris,

Thanks for your quick reply.

I've
converted the original DFU file of the Netduino 2 Firmware (v4.3.0.0
Beta1) to a S19 file. Then I was able to deploy the converted file via
the Flash Loader to the shield base. The settings were default (115200
boud, even parity, echo disabled, timeout 10s).

 

Now I've hit a wall. How do I deploy an application to my shield base? The N2 accepts data from the USB but on the shieldbase the pins PA11 and PA12 (which are used for USB on the N2) are pulled high to 3V3.

 

Do I deploy the application through Digital I/O 0 and 1 or through the GoSocket? On Stefans firmware the application will be deployed through the GoPort. Nice, you can use the same connection as for flashing the firmware

 

And is there a tutorial to build a firmware with a custom deployment mode? Ah I've found the firmware tutorial: http://wiki.netduino...-6.ashx?HL=base

 

Do I have to build my own firmware from the sources? My converted firmware does obviously neither support dedicated I2C because the pins are not connected nor does it allow an deployment because it expects data on PA11/PA12.

 

Thanks again

Guido

Hi Stefan,

after I read the post nearly a year ago I immediately bought two extra shieldbases for my Netduino Go. They were both very busy gathering dust since then. A few days ago i tried your shieldbase hacking with my FTDI adapter board. No success with the connection. There are a few question I would like to ask:

• What are the correct settings in the Flash Loader: baud, parity, echo, timeout?
• Must the reset "button" be released after power up? Do I have to pull the jumper wire which pulls reset to 3V3 before connecting with Flash Loader?
• What are the differences between the file formats ".s19", ".dfu" and the embedded resources of the normal shield base update solution for Visual Studio
• Can I convert a firmware file from one format to another?
• Is the new Netduino 2 firmware compatible to the shield base? The MCU is the same and there is the schematic of the Netduino 2 but I haven't found any Schematics for the shieldbase.
• Can a ".dfu" file be deployed to the shieldbase.

Thanks in advance for your help.

 

Regards

Guido

Hi perkunas.
The connection "P2" will sense a low signal when the switch is closed. The resistor at the +5V and the switch at the bottom will form a voltage divider. The calculation is fairly easy because the switches resistance is (nearly) 0 ohm if closed and (nearly) infinite ohm if opened.
Closed: 5V * (0/(10000 + 0) = 0
see Wikipedia Voltage divider

The resistor at P2 is not relevant for the calculation.

Regards
Guido

Hi Lars,
welcome to the forum. I've already build a temperature logging of all my rooms. There are a few things I want to point out:
Netduino needs energy. At least 40mA if I'm correct. This meens every battery will be depleted in about 2 days. You will need a regular (wall) power supply for each Netduino.

My own layout is as following:
Each room has one Arduino driven by a coin cell (CR2025).
The Arduino sleeps 3 minutes and after that it takes the temperature.
The sleep state takes a current of 0,000005Ampere (5 mircoAmps).
The measurement of the temperature takes 4ms and the send procedure takes about 13ms.
During the measurement the circuit takes about 0,015A (15milliAmps).
My coin cell batteries are depleted in approximately one year. (You can also replace the coin cells by "Super Cap" capcitors.)

The Arduino was not my first choice because I'had to learn (a little bit of) C language first but there are some advantages:
The things takes next to no energy.
You don't need 8 power supplies.
The hardware cost next to no money. (Arduino 328P 3,87$; Freeduino Runtime board 2,69$).
You don't have to write a large program. Everything the Arduino does is: sleep, measure temperature, send the temperature to the serial port, sleep again.

The real program to process the data is on a Netduino board.

The used temerature sensor TMP102 can also be operated in a low power sleep mode.
The wireless link is currently provided by the Nordic RFD21733 chip. But they have a very bad indoor range and they get brocken all the time (they really don't like 24/7 operation). All my RFD21733 will be replaced by XBee (XBee XB24-Z7WIT-004) chips. The whip antenna has a good range, the firmware supports low power sleep modes.

I hope this helps a little bit.

Regards
Guido

How would you get two shift registers working?

You would put the second shift register also on SPI1 and define a different latch pin (aka slave select / device select).

If it is a 74HC595 shifter you can use something like this:

public class Shifter74Hc595Extender
{
	public Shifter74Hc595Extender(SPI.SPI_module spiBus, Cpu.Pin latchPin)
	{
		var spiConfig = new SPI.Configuration(
			latchPin, //latchPin (aka SlaveSelect),
			false, // active state
			0, // setup time
			0, // hold time 
			false, // clock idle state
			true, // clock edge
			1000, // clock rate
			spiBus);

		_Spi = new SPI(spiConfig);	
	}

	public void WriteData(byte data)
	{
		_WriteBuf[0] = data;
		_Spi.Write(_WriteBuf);
	}
}

I hope this helps...

Regards
Guido

The whole result was zipped and attached.

Forgot to press the "Attach This File" button

Hi,
I'm happy to help. I've mode some major and some minor changes. All major changes are listed below. The whole result was zipped and attached. But be aware that my Netduino GO hasn't arrived yet. So the code is completely untested.

• The "controller" isn't nested anymore. A nested type is only used if it is related to its parent in some way.
• The method "UpdateLeds" was moved inside "ShieldBaseController" because it was accessing only OutputPorts from it.
• All output ports are now private.
• The statement "bits[led]" and its "bits" array was replaced by a bit shift operation "1 << led".
• The "mask[led]" was also expressed as (inverted) bit shift "~(1<<led)". For example 1<<4 would result in 16 (or 0x10) and the "~" will invert every bit in the byte so you will get 0xEF or 239. Less manual calculations and less code results in less errors :-)
• Some minor renaming and other unimportant stuff

There is still room for improvement. You could change your SPI bit bang mode to native SPI from the Netduino. I've attached a class for the 74HC595 from my classic Netduino as example. You can also provide the parameter "GoSockets.Socket5" for your "new ShieldBase()" through the constructor of the class.

Regards
Guido

Hi Gutworks,
a singleton can work until you add your second shield base. If you will never ever do this you code is fine.

A singelton if often used if the following is true:

• Your class can only be instantiated once, there may not be a second instance of the class (like I2C bus on the classic Neduino).
• Your class will be used in multiple other classes in your code.
• You have no idea which code will call your class when. And so you have no idea who has to call the contructor.

Without the singleton pattern you would have to build the instance yourself (call the contructor) and give it to every class which may need it. This can get very ugly...

The use of an normal contructor (as stated in my earlier post) would suffice because your program calls "GetInstanc" once, your singleton will be used in only one class and you know when to call the constructor.

It isn't my intention to be rude and I'm absolutly thrilled that you have coded a beautiful singleton pattern. But simpler may be better.

Regards
Guido

Hi,
the static contructor is a solution but I prefer a diffrent approach. My main program always looks like this:

using System.Threading;

namespace Netduino.Extender
{
	public class Program
	{
		private static ImportantController _ImportantController;
		
		public static void Main()
		{
			_ImportantController = new ImportantController();
			Thread.Sleep(Timeout.Infinite);
		}
	}
}

Now I'm done with all the static stuff. The real party starts in my "ImportantController" (in real life the class name is not "ImportantController" of course).

using ...;

namespace Netduino.Extender.Heating
{
	public class ImportantController 
	{
		private readonly Lcd _Lcd;
		private readonly SwitchModule _SwitchModule;
		
		public ImportantController()
		{
			ILcdTransferProvider lcdTransportProvider = new Shifter74Hc595LcdTransferProvider(...);
			_Lcd = new Lcd(lcdTransportProvider, ...);
			_SwitchModule = new SwitchModule(...);
			_SwitchModule.ItemChanged += SwitchModuleItemChanged;
		}
		...
		void SwitchModuleItemChanged()
		{
			_Lcd.Write();
			...
		}
	}
}

In my opinion the advantage is that only one class (the "ImportantController") must be declared static. Inside this class you can decide if the objects should be instanciated more than once or if it should be static for some reason. Also if you want to refactor your code you don't have to remove all "static" modifiers. For example if you build a class with a field to count something and you need this class a second time the field shouldn't be static because your counter would count the "somethings" of all your instances.
Maybe the code in my example is a little bit desktop style programming but I don't know a reason against my approach. If there is one I would be happy to know it.

Sorry for the short and confused explanation but I've cought a cold and my brain is alread in bed sleeping :-)

Regards
Guido

Hi, to stress Marios point a littel bit more I can tell my own story: One of my Netduino boards controls my heating. It receives all temperature data then processes it and after that controls all heating valves (they are in one place). The whole application is event driven and if I use the firmware 4.1.1beta it runs week after week. So far so good. But if I update to firmware to 4.2 RC3/RC4 the same application hangs without an exception after 6 to 12 hours. This is a little bit anoying. But the most anoying thing is that I can't reproduce the bug in a manner of: "I do something and the board gets stuck." Don't get me wrong: I think Netduino is by far one of the best Micro Framework boards out there but I would'nt do anyting mission critical with it too. Regards Guido

In fact if I am debugging inside VS and pull teh USB cord our my computer instantly reboots... thats a nice feature.

Yeah,
this 'feature' is also discussed in Drivers for .NET MF 4.2.
There is an issue in Codeplex describing this behaviour. But sadly this bug can only be reproduced by another bug: Read on a disconnected I2C Bus takes forever.
This is not ideal. However you can try the repro and vote for it.
If something should be added or changed please send me a message.

Guido

Hi, the low resistance of the tantalum caps tends to set them on fire if they are loaded and then short-circuited or if the caps grow old or something unexpected happens to you circuit... This is a fact you should be aware of. My recommendation is to avoid tantalum but on the other side it is recommended by the vendor because the circuit is designed for tantalum caps and it would provide the best result. On most designs I would put normal caps in the circuit and I would check if the result is good enough. (This reminds me to buy a scope ) Guido

Hi,
at last I've posted the issue in Codeplex. Everyone should try the repro and vote for it.
If something should be added or changed please send me a message.

Guido

P.S. There is another bug I'm interrested in: Read on a disconnected I2C Bus takes forever. The foundation of the bluescreen repro is this bug. Everyone can also try the repro, vote for it, send me his or her results (with board type and firmware) and of course his or her opinion...

Guido

Hi smarcus,
at last I've posted the issue in Codeplex.
Please vote for it. If something should be added or changed please send me a message.

Guido

P.S. There is another bug I'm interrested in: Read on a disconnected I2C Bus takes forever. If you like, try the repro and send me your result (with your board and firmware) and of course your opinion

Hi, I would get a capacitor with a higher voltage. Something like 50V to 60V. If the TSR-1 needs 22uF you should get exactly the 22uF. If you need 1000uF for the rectifier you should get one and put them both in parallel. But I would put the rectifier capacitor near the rectifier and the TSR cap near the TSR. This should give the best result. Capacitor theory (oversimplified): Small caps can filter very small ripple (but not huge ripple) because they take little time to load and unload. Huge caps can filter huge ripple (but not small ripple) because it takes a long time to load and unload. Regards Guido

Hi,
there is already another thread which decribes this behaviour.
There is no fix but repro steps in there: Drivers for .NET MF 4.2

Ok, I'm not really helping here. But I'm frustrated by BSOD too and I'm unsure what to do.
Should I open a bug in Codeplex? I've posted the repro but in the last week there was no response.

Guido

Hi teo,
without the data sheet of the gyro I would guess something like that:

device.ReadInternalAddressBytes(i2cconf2, rbuf, 27, 1);

because the fourth parameter is the count of bytes that are used for the internal address and your internal address fits nicely in on byte.
But only the data sheet of your gyro sensor can answer your question.

Guido

Hi teo,
most possibly your firmware is something like 4.0.6 or so.
A good firmware for repeated start bit support is Version: 4.1.1 BETA 1 (version 4.1.1.0 b1)
You have to update the tiny booter decrompressor too. A superb how to is in the wiki.
After that you can update the firmware of your Netduino.

Version 4.1.1.0 b1 is really stable. My under floor heating runs on 4.1.1.0 b1 till january. The 4.2.0.0 will be great too but until now the same program gets stuck after 6 to 12 hours if it runs on 4.2.

Regards
Guido

Hi teo, I will try your code at a later time but in the meantime please answer me: which Netduino firmware are you running? Guido P.S: I've tested your code. Works well on firmware 4.2.0.0 RC4. I have none of your devices of course but the exception should occur without them...

Hi James,
Mario addresses a very important point with the "noise" issue.
I've designed a DCF77 remote controlled clock. Everything was fine until all my devices were connected together. After that my clock received an additional clock impulse from one of the other components every 10 seconds.
I resolved the problem by throwing the remote controlled clock away. A RTC was implemented instead.

My point: Mario is right in all of his points and I myself have made my share of bad experiences in counting/measuring pulses.

Guido

Hi,
the really hot resistor is a possible way but I wouldn't recommend it. I've build a switching power supply my self (based on the LM2596, but they are also available fully assembled.

For example the TSR1 module is very easy to use: One Pin is Vin, one is Ground and the last puts out your 5V. And this goes up to 2.5Amps 1Amp without a heatsink.

Regards
Guido

P.S.: Paul pointed out that the maximum power output is 1A instead of 2.5A. Thanks.

Hi James,
sadly I've to pass your question on to someone else...

...assuming that we don't miss any pulses on a Netduino? (Does this happen ever, if say the board is very busy may the .NET GC kick in and remove stuff from the Interrupt queues?

Does anyone have any tutorials/links on Micro framework interop??

But I'm very interested how the questions will be answerd.

Guido

Excellent! Thanks for your feedback. Guido

Hi gnomathibus,
after I read the datasheet of your DAC again I realized I've made a mistake:
The code on the Netduino should be something like this:

var slaveConfig = new I2CDevice.Configuration(0x28, 100);

byte port = 0x00;
var i2CAdapter = I2CAdapter.Instance;
i2CAdapter.WriteBytes(slaveConfig, new byte[] {(byte)(0x07 & port), 0xFF});

The "(0x07 & port)" ensures that only the 3 smallest bits can be set as port. The "(byte)" converts the resulting integer back to one byte and "0xFF" sets the DAC0 to full power.
As far as I understand the datasheet this should work.

Regards
Guido

Hi James, impulses with a frequency of about 100Hz can most possibly be handled by Netduino. But you can't say exactly when each impulse occured. Each impulse has a time stamp but this stamp is a few micro seconds of because the .NET Framework isn't realtime. Of course first you should build a prototype before ordering 1000units. Regards Guido