As mysteriously as it stopped working, it started again. So, please ignore.

Yeah, it does that. A lot.

I just about finished my epic project, maybe I should read the book now eh?

I am using D4 and D5 with an twiddly knob (encoder). The common is connected to ground and the weak pullups are enabled. Thus when I the encoder connects D4 and Common I get a 0, and same for D5. I have built a state machine and configured it such that 4 - 1 represents a clockwise detent and 1 - 4 is anticlockwise. All good so far. I am using an interrupt on edge for both and when either is interrupted I check both and compare it with my state machine. The problem I am having is that I am not receiving all interrupts. The main weird thing is that it works better in one direction than the other. The speed of the interrupts is not very high perhaps 10 per second or so. If I disconnect my encoder and use push buttons I can see what happens. Holding down Button A first prevents Button B from generating an interrupt. B on its own generates an interrupt. Holding down B doesn't interfere with A. Its nothing to do with A not finishing the interrupt routine, everything ought to be symmetric. For now I have bodged it knowing that 3 - 1 is a clockwise rotation, though its not a valid set of states. I have added 10nF on D4 and D5 to ground, based on the premise that internal pull-up is about 100k, this should filter out glitches and still pass the fundamental that I want. Any ideas why the interrupts are not working as they should.

Well my master piece is almost finished. Its got pressure transducers, accelerometer, thermopiles and LCD touch screen. Its a piece of avionics. Its awesome. Now, I have accelerometer, thermopile and pressure on a single I2C with some low-pass filtering. This all runs on a thread. My routines for the display use the UART and they also run on their own thread. Then my main execution runs on the main thread. I have logging on yet another thread. And I'm currently using about 38kb of program space. I was wondering if there was any way to determine the CPU load - I mean all those threads have thread.sleep in them at some point and if there is a speed limit my code hasn't reached it limited mainly by the speed of the display and the I2C devices. I was thinking of sticking GPS for ground speed and heading information on the spare com port. This will require constant baby sitting of the NMEA sentences. The question is will the little netduino cope? How to tell?

You don't need to be concerned with the debug statements, if no debugger is attached they do nothing. With no debugger attached watch out for much faster execution which may change how your program executes if you have not been careful with delays. I had been using I2C and effectively closed it immediately after sending a shut down, in debug this worked well, with no debugger it shut the port down before it had chance to send shut down!

Does anyone know what the PWM resolution is when using 4.2? (Latest)? I am using PWM at 10Khz and the minimum duty ratio I can get is 0.01. Which suggests that the PWM resolution is 100. The ARM has a resolution of 16bit which is a good deal higher than the 7 bits I seem to be getting. This means when controlling LED brightness it goes from off to about 20% perceived brightness in one jump which is a bit rubbish really. I'm using Microsoft.Spot.Hardware.PWM, am I doing something stupid? Would I get a better result by setting the period and the duration of the pulse? I would have though this had already been posted but I couldn't find anything.

this works well now. My code was fine.

Aha, that makes sense. Will try lower freq.

Does anyone know what the PWM resolution is when using 4.2? (Latest)?

I am using PWM at 10Khz and the minimum duty ratio I can get is 0.01. Which suggests that the PWM resolution is 100.

The ARM has a resolution of 16bit which is a good deal higher than the 7 bits I seem to be getting. This means when controlling LED brightness it goes from off to about 20% perceived brightness in one jump which is a bit rubbish really.

I'm using Microsoft.Spot.Hardware.PWM, am I doing something stupid? Would I get a better result by setting the period and the duration of the pulse?

I would have though this had already been posted but I couldn't find anything.

Really no-one know?

Yes, pretty sure that could be a power issue.



I would not be comfortable with a constant 800mA draw, even if its not shutting down, I don't like my board to be getting so warm. This could cause the board to get quite warm. I like to power via 5V rail with either a PC power supply, or a similar stand alone supply, and only use the on-board regulator for small projects.

It'll be fine, you worry too much, what could possibly go wrong....... (don't know why they worry at work when I say that)

Hi DrJaymz,

Does this help?
http://forums.netdui...-5v-header-pin/

Well it states that the 5v regulator on board is good to 800mA we know that the controller uses about 250 so that leaves 550mA to stay in the current spec. So as long as the on board reg doesn't overheat we're good. The reg will shutdown in the event it gets too hot so it should be fine. perhaps my issues could be insufficient supply decoupling.

I'm using a serial qVGA graphic display that draws about 200+mA, the Netduino can draw a couple of hundred as well, sooner or later I often wonder if my issues with stuck deployment and general shakeyness could be lack of power. Also my project behaves differently when running from a USB charger as opposed to connected to a PC. The timings appear to change on the UART which should be fixed surely or else it wouldn't work properly.

Hi DrJaymz,


Be sure that you're selecting the MFUSB_Netduino.inf file, not MFUSB.ini.

We're basically overriding the Windows driver system by forcing it to use MFUSB instead of WinUSB. Unless we select "no, let me choose" at every step it will try to use the driver specified for the VID/PID in the registry.

Chris

Yes, understand, but it will not let me. I'm running XP 32 bit.

Yes, understand, but it will not let me. I'm running XP 32 bit.

I clicked uninstall driver

Then let it install it again.

then just now it worked.

There must be something iffy with the driver caching or something - but I rebooted the VM and changed my LED blink rate just to check, rebuild and deploy - it works fine. Now back to my original issue - I couldn't work out the PWM syntax as usual the MIcrosoft help file says exactly what the function name is and that it has parameters such as duty ratio, but doesn't bother to tell you what units they might be. Really I want to start a PWM signal 10k bananas with a duty ratio of 50 pears. On say D5. Just to add to the confusion, I saw a number of questions in the forum about this and they were using the secret labs definition of PWM and were told not to use the SPOT ones. If people were using the SPOT function then PWM_0 doesn't relate to any pin so I never did get a straight answer to this.

It does deploy the application, then afterwards it says preparing to deploy and then that times out.

Switching to serial and then back again makes no difference.

I cannot install the MFUSB.ini because windows says:

The specified location does not contain information about your hardware.

With only OK as an option.

So I guess were stuffed then.

The only thing I thought about was the bootloader being at fault.

Hi all, I have dusted off the netduino VMware system and aquired another netduino plus. I am confused because I cannot find a definitive guide to what I should be using with versions, the front page mentions 4.1 4.2 sdk, 4.2 firmware, 4.1.0 sdk for the plus and I can't figure out what I need. I have 4.2.0.0 RC4 firmware in my netduino and 4.2 SDK and latest netduino DSK but I cannot use the PWM because its all messed up and the checksums don't match and its all confused. So. Lets start over... Uninstall SDK's , Netduino and just have VS2010. Now, what to install and in what order? I'm happy to update the netduino firmware. Presumably even now, the bug where it cannot be reliably deployed is still with us?

OK, trying now, BRB

Switching to serial and then back again makes no difference.

I cannot install the MFUSB.ini because windows says:

The specified location does not contain information about your hardware.

With only OK as an option.

So I guess were stuffed then.

The only thing I thought about was the bootloader being at fault.

Hi DrJaymz,

1. Install the .NET MF 4.2 QFE2 SDK
2. Install the Netduino 4.2 SDK (latest version)
3. Upgrade your board to the latest Netduino firmware

Please let me know how it works for you,

Chris

Done.

It will not deploy now. Whatever I try to do.

Incrementally deploying assemblies to device
Deploying assemblies for a total size of 1456 bytes
Assemblies successfully deployed to device.

You'd think its deployed then? No. The error comes up:

Error 1 Device not found or cannot be opened - USB:Netduino

Using MFDeploy I can get

HalSystemInfo.halVersion: 4.2.0.0
HalSystemInfo.halVendorInfo: Netduino Plus (v4.2.0.1) by Secret Labs LLC
HalSystemInfo.oemCode: 34
HalSystemInfo.modelCode: 177
HalSystemInfo.skuCode: 4097
HalSystemInfo.moduleSerialNumber: 00000000000000000000000000000000
HalSystemInfo.systemSerialNumber: 0000000000000000
ClrInfo.clrVersion: 4.2.0.0
ClrInfo.clrVendorInfo: Netduino Plus (v4.2.0.1) by Secret Labs LLC
ClrInfo.targetFrameworkVersion: 4.2.0.0
SolutionReleaseInfo.solutionVersion: 4.2.0.0
SolutionReleaseInfo.solutionVendorInfo: Netduino Plus (v4.2.0.1) by Secret Labs LLC
SoftwareVersion.BuildDate: Sep 19 2012
SoftwareVersion.CompilerVersion: 410894
FloatingPoint: True
SourceLevelDebugging: True
ThreadCreateEx: True
LCD.Width: 0
LCD.Height: 0
LCD.BitsPerPixel: 0
AppDomains: True
ExceptionFilters: True
IncrementalDeployment: True
SoftReboot: True
Profiling: False
ProfilingAllocations: False
ProfilingCalls: False
IsUnknown: False

So presumably the device is working. The output is set to deploy to netduino over USB.

So surprised it still can't really be used seriously.

OK, trying now, BRB

Hi DrJaymz,


Can you please try two things really quickly?

1. Open up your project properties and go to the ".NET Micro Framework" tab. Change transport from USB to Serial. Then change it back to USB. Try to run your app again.
2. If that doesn't work, please try switching back to the MFUSB drivers.

If all that fails, there are two final options:
1. If you're running Visual Studio 2012 (or would like to try Visual Studio Express for Windows Desktop), upgrade to the .NET MF 4.3 beta SDK. It has dramatically better diagnostics when deploying and it supports .NET MF 4.2 boards as usual.
2. Reflash your Netduino with the production 4.1 firmware. That's really a last resort, but if Visual Studio is failing to connect...it may b a bug which needs to be fixed in the NETMF 4.3 SDK.

Chris

P.S. If you're running inside a virtual machine, the standard WinUSB drivers may not be set up to handle that. Switching to the MFUSB drivers may be a solution there.

You could always argue that the netduino is a really big CPLD. I guess it depends on what you are trying to do and quite a lot can be implemented in software and I never cease to be amazed how ingenious some peoples solutions are. I guess most uses for the netduino are not concerned with outright speed but (in my case) out of lazyness. happy coding.

Hi
As far as the BSODs go, the only time I ever get them is if I reset the Netduino while Visual Studio is doing the deployment.
For me it is a golden rule, cancel a deployment via visual studio before cycling power to the netduino.

To be pedantic it is not the Netduino hardware itself causing any BSOD but it is the USB driver.

There is another thread where we discussed failed deployments that may help. Stuck Deployments

You are right about the 12v supply, I think the power cycle is critical sometimes.

I have tried quite a few embedded technologies and they are all full of compromise, the Netduinos compromises in particular are a little different than most.
but so are its advantages,

As far as your serial port problem goes, have you considered a hardware solution. Such as using a logic gate to hold the line how you want it.

eg.

Using a 2 input gate: one input is the Tx line; one input is an IO pin, that we could call enable; one output goes to the LCD.

Would that work?

I cannot cancel deployment withing visual studio it hangs. No matter how long you wait. The other failure mode is where it says deploy failed in the status bar and then visual studio won't respond to the mouse anymore. In this case you can only end task it. If you pull the usb you will get a BSOD, thus the only thing you can do is end task. Once in this state, if you keep the board powered and remove the usb connection, and plug it back in, the device isn't recognized, thus I have just proved that whatever is going on in the atmel, it is not in the correct state. At this point the driver has been reloaded - thus its not the driver per-se, though the driver could be responsible for putting it in this not allowed state.

I am all to familiar with compromises in the world of development, I still remember the various bodges for 8051's. I have BSOD my machine before when writing USB Hid devices in assembler - but I don't really expect it in this case. I have considered using a VM for this work but the whole point of the netduino was to enable me to be lazy.

The gate idea, did cross my mind or simply a pass transistor, but I think I proved that the transition wasn't the problem by demonstrating that it doesn't occur when closing and opening again at the same speed and the communication remains unaffected.

Does anyone know what baudrates are available with the netduino and what their bitrate errors are? Despite the .netMF functions for creating serial ports, the rates are not infinitely variable. I am trying to talk to a device that should be 256kbaud and its actually 282,393 and I wanted to know how close I could get to that rate. Failing that I should be able to find some happy medium somewhere above 128k. I have had a look at the Atmel datasheep and its not that useful without knowing exactly how it was implemented on for .net. For example, you can specify exactly how the input is sampled, in my case a single sample would probably work where multi-sampling probably wouldn't. Thanks if anyone knows.

Have you tried the .NET MF 4.2 beta drivers yet?

Tried RC3 and it was hopeless, I may try RC4 later on - is there any change with the deployment? It is really tiresome when you are trying to debug something and then deploy fails after 4 or so goes. I have found the only way to avoid blue screen is to end-task on visual studio and then remove and replug the netduino then restart Visual studio.

I know its the netduino that is the problem because if it has its own 12V supply, replugging the USB doesn't help i.e. it has not been reset by power cycling.

Update - I have tried closing and opening the port at 9600 and I do not loose the connection with the display. So thats all fine and no pull ups are needed. I found port.close followed by dispose, then new port at 9600 worked, where close then new baudrate and then open didn't seem to. But it has come to my attention that the SGC slave controller has an implementation of baudrate that has rounding errors in it probably as a result of how they have implemented it. Which sounds a bit like they are bit banging. Here is my discussion with 4D http://4d.websitetoo...post?id=5734058 I have tried incrementing the baudrate in a for-next loop to find the actual rate it is talking at but I cannot get communication above 9600 with the display. At this stage in my investigation, when I open the serial port I supply an integer for the baudrate - but how does the baudrate generator work on the netduino? I would imagine it is not infinitely variable, and that there is a list of available rates somewhere that fit the internal generator scalers. My next thing is to get a scope trace from the display when it thinks its at say 115200 measure the bit period and try to find a compatible rate on the netduino. I am sure that a few other people would find this work useful once we find the magic rates! For 256kbd the actual rate is 282353bd but if I set that with the netduino it doesn't work. Without a scope I can't do anything other than trial and error - but I will have a DSO Quad next week to investigate it further.