Of course the biggest differences are that the homebrew mini has an STM32 chip and USB.

Yes, quite significantly so, how silly of me :-)

Great I saw this post, I didn't know how to provoke a reboot from software.

 

The code you attached before would restart the device repeatedly between 10:00 and 11:00 AM, effectively rendering it unusable during that time. Am I right?

 

Personally, I think there's no such thing as a software watchdog. You can't write software to check if another piece of software has locked up. If I remember correctly it's one of those NP complete problems within the theories of complexity.

In the multi-threaded world, anything that theoretically can happen - will happen, for sure 

 

A hardware watchdog is a quite simple part, like this one for example:

 

http://www.analog.co...3_6824_6825.pdf

 

Simple operation, your micro periodically "checks in" by toggling the detector pin every 100ms. Should the device not hear from you in 140ms, it will briefly de-assert your reset pin, effectively causing an actual reboot.

 

I'm sure you can find a watchdog IC that is available in DIP8 - just stick it down the breadboard, connect 2 wires (plus power) and you're good.

I'm no expert either, nobody is :-)

The one I referred to is named ADM682x where x is 3, 4 or 5 depending on small differences in functionality (it's all in the datasheet) but it's only available in a 5-pin SOT23 package which is SMD (surface mount device) and thus cannot simply be snuck down a breadboard.

Instead, you probably want to use the classic DS1232 which is available in breadboard friendly DIP8 package. A nice feature is that timeout can be configured up to 2 seconds, so you don't have to check in that often, saving you some cpu time. It's about 1.50 USD and available at most electronic part resellers:

http://datasheets.ma...ds/DS1232LP.pdf

See figure 1 on page 3 on how to wire it. Another thing to consider is whether your Netduino has a soft or hard reset pin - if it's soft, a hardware watchdog won't be bullet proof after all. However, in the case of a soft reset, you could have the watchdog chip control the powerline to make sure the board actually reboots for sure no matter what.

Good luck and be sure to check back to report on your progress. I'm sure many here at the forum would be interested in a driver class for that chip so perhaps you could take on writing one...

There was this other similar case a while back, maybe you've already seen it:

http://forums.netdui...other-problems/

Unfortunately, I don't beleive it was solved eventually but there might be something useful in there.

Obviously, it's not supposed to be this way. Admin: This issue should be escalated.

Have you tried different SD cards, formatting, sizes, etc? Also, try writing a large file, say 4k+ and see what happens. There seems to be some kind of lazy writing going on.

I trust you close the file after creating and writing to it?

No, its 3 minutes 

Awesome video! - must have taken months to combine all those separate videos into one.

 

EDIT: Too me, the video would suggest something with an LCD on it.

Could be sort of....the mystics around this seem to thicken by the hour...check out this post:

 

http://forums.netdui...mepage/?p=49589

 

Code cracked!

I actually edited the post on 1:57 but that doesn't show...I initally wrote 4 minutes, but you beat me to that 

Yes, where is it?

I must say, I never expect a smartwatch - I was so wrong, so very wrong!

 

How much?

Looks sweet, don't know what it can do but still only a question of how much I should place!

I should expect so and hopefully even runs NETMF !

 

...and it really was a time machine!

The SensorTag is just 25 dollars :-)

I got one, works perfecly with iOS devices but haven't got around getting a board for my Netduinos yet and turned out there's no BT LE drivers for my good old XP box (while as it is built into Win 7).

To think there are more than one manufacturer of such things, incredible really!

Great project!

If you need more sensors, you could try interfacing the Parrot Flower Power:
http://www.parrot.com/flowerpower/en/

It would require a Bluetooth LE module and probably hacking their protocol. The flower power is a bit expensive but there's also the SensorTag from Texas which is not miles away (not a coinsidence):
http://www.ti.com/tool/cc2541dk-sensor

Hi! The logic sniffer seems ok for UART and PWM analyzis but not as an oscilloscope: The analogue bandwidth of 200kHz is way too low and makes it pretty useless The display is tiny, mine is many times bigger and I still wish it was a lot bigger Buffers are very small, you can only see small fragments at a time I think these kind of gadgets are rather cool but don't qualifiy as oscilloscopes. It's like they thought "We got this tiny piece of hardware, let's see if we can make an oscilloscope out of it". It would be better if they'd thought "hey, let's design an oscilloscope and choose whatever hardware meets the requirements". No, I would put my money on something else.

Assuming (haven't read the d/s) the first matrix will swallow the nop only passing forward the next operation to the next matrix in chain, shouldn't you be sending the nop first when addressing the second matrix?

Sorry about the delay, couldn't find the code so I had to write it all over again 

 

Anyway, attached is some code you can try. It's a small Hd44780 demo app using bit banging to drive the LCD. I wrote the app for the Mini but you should only need to change the pin assignments and using directives according to your board. It works perfectly on the Mini and hopefully it will on your board too.

 

Here's a couple of pictures showing what it should look like when running:

 

 

In the pictures the wiring may look funny because I use PWM to control brightness and contrast. That way I don't need any potentiometers and there's a few lines for this that you can uncomment if you want to use PWM. Should you decide to do so, first measure the currents to make sure you can drive the LCD straight off the PWM outputs. In my case the current is only some 4mA so it's fine.

 

Good luck!

 

 

 Hd44780Test.zip   4.55KB   4 downloads

The built-in 16 bit shiftregister has the effect of data coming in though DIN being spit out through DOUT 16.5 clock cycles later. So there's a 16 bit delay before data reaches the 2nd chip. Data is latched in from the shiftreg on the high edge of CS. So you are correct, the nop should go last. I agree, your code ought to work, after clocking through 32 bits, the nop should be sitting in the shiftregister of the 1st matrix and the actual op in the 2nd. As LOAD goes high (!CS goes low) ending the SPI write, the shiftregister data should be latched in to both chips respectively. At this point, the 1st would load the nop while the 2nd would load the op. What happens if you send the same op twice in a row (eg without a nop in between) - does both chips act as expected or only the 1st, 2nd or none? EDIT: I've had some bad experiences with 16 bit SPI, could be you have to make two transfers, 16 + 16 bits. Naturally, if you have a scope or analyzer, have a look at the signals to what really happens and check your wiring, SPI timing config with setup time, etc.

That is strange, the wiring looks ok to me and the corresponding gpio# in code checks out too. You shouldn't have to tweak anything more than the gpio# so I find it very strange. 1. The code does compile yes? 2. If so, exactly what do you see when you run the app? 3. If you see something (like garbeled text or so), could you perhaps take photo of it? EDIT: Would it be possible to isolate the board and LCD from everything else, i.e. temporarily disconnect all the other stuff or maybe you have an extra board, a regular N, NP or mini you could try the LCD alone with?

When cascaded like this, the chips collectively form a big shift register with a bit length equal to 16 x the number of chips. As long as you keep LOAD low, bits are just shifted through according to the number of clock cycles. You can think of the data bits as a train running on a track through a series of stations where each of them corresponds to the cascaded chips respectively. The clock is your train engine and when you stop the engine, the train stops and the passengers (the bits) arrive to the location where they happen to be when the train stopped. You then open the doors by raising LOAD to let the passengers off. As for your questions:

 

1. The above should answer that

2. Yes but it's only necessary to raise LOAD when bits are in place

3. I've never used the emulator so I wouldn't know but an external device generally cannot tell the difference if it's being bit banged or communicating with a an actual hardware peripheral (e.g. h/w SPI)

4. Yes, only one LOAD when bits have arrived to the designated chip (see 3)

 

I wouldn't know about power consumption.

Nice, is that using variable word length or with "manual" LOAD control?