Hi! Found a few things to be a little odd, I'm not sure they'll solve your problem though. You are creating the trigger port each time GetDist() is called. If you wish to share the same trigger pin among multiple class instances, declare the trigger port member as static instead and make sure it only gets created once. Create both the trigger and echo ports in your constructor and store them in private members. Remove the pin members since there's no point in remembering those any more. About interrupts, when adding an event handler, you are only registering a method to be called if and when an interrupt occurs. You are not, as your comment implies, waiting for it to happen at that point. This also means you should move event handler registration to the constructor as well. How are the the instances ultraSonic1 and ultraSonic2 created, what parameters are passed to the constructor?

Yes, the Netduino can certainly talk to multiple SPI slaves, but you must serialize your data transfers. Basically, you create several SPI configurations and swap between these when interfacing to one or the other slave devices using different !CS pins.

 

In a multi-threaded environment, you must make sure that transfers are not interrupting each other. If necessary, use the lock statement to protect your SPI configuration swapping mechanism.

 

There are several implementations available, here's one for you:

 

http://netmftoolbox....rdware.MultiSPI

It sounds a bit like the mbi5026 does not honor it's !cs input really well. Have you tried using different Netduino pins for the mbi5026 !cs line or tried adding a pullup resistor on it? The latter might very well do the trick.

Those must have been some really bad wires, at these small currents and short distances, one would think such things should not matter, but there you go. Glad you solved it!

Is there anyway I could re-use existing C code libraries in my project. The work that would be involved in translating them in C# would be enormous. 

 

I've ported lots of code from C to C# and found it to be a very straight forward (almost mechanical) process even though it has not always been my own code to begin with. Many things can be taken care of with simple search and replace.

 

There are some converters out there but I have no idea if they're any good - but they should at least be able to do the "no brainers" for you:

 

http://lmgtfy.com/?q=convert+C+to+C%23

Nice, is it an Android phone and did you write the app for it?

Ah yes, silly me - I see now that you got the same webpage open in the browser of your PC.

I agree, the Netduino and Pi are not comparable and have different audiences, I was primarily the (in my opinion) somewhat unjustified hype around it.

 

OT: A while ago, I got a Cubieboard and yes, it still sits in unopened box :-) but I mention it because it's comparably priced, has superior hardware over Pi and intended on h/w hacking/interfacing. Runs Android 4.x, Ubuntu, Kali and Debian:

http://cubieboard.org/

http://ubuntuone.com...2MH4kCv5UdA6RmE

Couldn't agree more! It's a bit like the old Amiga, it worked amazingly well and that was long before the internet or even BBSs in many cases. People were exchanging knowledge through magazines and sending floppy disks by snail mail :-) Same thing, we all had the exact same hardware (almost anyway, there were a few expansion boards). Personally, I instinctively refrained from purchasing a Pi, it was simply too powerful to seem fun and enough challenging for me. I wouldn't be at all surprised if every other Pi ever sold still hides somewhere untouched and in its original packaging. I love the Netduino, it managed to bring my dormant interest for digital electronics back over night! Another thing is the friendly tone and welcoming feel in the forum, personally, I think that is a major contributor to the success.

Ok, just modify the erroneous line like this:

// Defines the HBridge IC on the correct pinsHBridgeMotorDriver = new HBridge(PWMChannels.PWM_PIN_20, Pins.GPIO_PIN_19, PWMChannels.PWM_PIN_18, Pins.GPIO_PIN_17);

It works for me (Netduino mini with framework 4.2) and should for you too I hope.

 

EDIT: Works = the code compiles but I don't have a H-brigde driver and forgot to check with the scope.

Hi! One or more of the HBridge constructor parameters are of the wrong type. Try writing Cpu.Pin.xxx instead of just Pins.xxx. Does that help? If not, a silly way to find out what is the cause, replace both PWM object parameters with null. if the error goes away, then you know the PWM obejcts are of the wrong type. If not, it's the Pins. Depending on the outcome of the above, investigate further as needed by examining the type of the corresponding parameters making sure they match those of the method signature.

Did you try replacing with null as described? The error has nothing to do with oop, it's just a matter of passing parameters of the correct type. Yes, it could be enumerator difference between the two. EDIT: Could you zip and attach your code so I could try it?

That is great news, good luck with your project!

Since the last thing of Main() is to call output0.Flash() which enters an infinite loop, I don't think Main() ever returns, at least not according to the Program.cs attached where ToggleMethod is set to LoopIteration for all instances of the ToggleOutput class by a static member of the Program class.

The scheduler may have problems switching between threads since they are all running in tight loops. Try yielding briefly in the loop by calling Thread.Sleep(1) once in a while.

Ok, that is truly strange. What if you just assign a variable DateTime.Now, does that produce anything other than zero? If not, could be hardware problems but one should think more stuff would also not work then so I assume you get a decent value and that would leave a firmware upgrade or you've teied that already perhaps? I don't know the differences, if any, between the N2 and NP2 with respect to such an issue, I'd suspect there's none.

I really doubt it's the keypad, I think you should try setting a few breakpoints in select places of the Toolbox.NETMF.Hardware.MatrixKeyPad driver code and find out where that zero originates from. There could be a bug in there or perhaps something resulting from incorrect wiring.

I'd expect time to be zero when the board starts up since there's no RTC on board, or is there? After startup, clock should start ticking of course. Would that explain the phenomena you're seeing? EDIT: What is the initial value of the ButtonLastPushed variable? I guess it should be DateTime.MinValue.

I would have thought it be unusual for an SPI slave device to ignore chip select but could be it only looks at the raising edge of the clock as long as !cs is asserted, i.e. performing and AND operation on the two. Maybe that is defacto standard procedure. The parameters you set do matter and controls how the Netduino SPI module manages the cs and clock pins respectively but I guess you knew that already.

Interesting.... Getting +/-6V could be useful in some cases. Any idea of how much it can source? I would guess about half as much as any other regular pin since those are 3V3.

Sounds like you got it from a secret place ;-)

Hi! Why not multiplex the 12 using only a single voltage divider and analogue input? You'd have to sample 12 times as often but it would be very economical... About the relays, pretty much the same deal or use a latched shift register. EDIT: Your avatar looks like a turbo charged in-line four jap motor or an old BMW M3, but what is it? EDIT: If its for a motronic application, speed could be a problem.

Yes, the general idea was to use an analogue multiplexer that can handle the voltage and then a single voltage divider between that and the Netduino. The CD4067B 16 channel mux/demux can handle up to 20V but Vcc must also be 20V:

 

http://www.ti.com/li...ink/cd4097b.pdf

 

If 20V is not readily available you need a step-up converter from 12V which infortunately would increase cost. On the other hand, such converters come quite cheaply on eBay:

http://www.ebay.com/...=item1c33d18e42

 

If you spend some time searching, you might be able to find a demultiplexer that can handle input voltage significantly greater than Vcc and then of course you won't need the converter.

 

Audi?

It suddenly hit me that you need an analogue switch instead of a multiplexer. There are many but this one is a 16 channel switch that can deal with 230V signals. I don't know but they could be expensive.

 

http://datasheets.ma...05-MAX14806.pdf

 

EDIT: Here's an overview from Texas Instruments:

http://www.ti.com/li...5d/slyb125d.pdf

USB gamepads are typically implemented as HID devices and must be connected to a USB host. The host (usually a PC) periodically polls the device to read the current state of buttons, directional pads, thumbsticks and so on. I find your project description to be somewhat cryptic - are you looking to have the Netduino act as USB host reading the gamepad or is it the other way around - e.g. the Netduino should act as a gamepad that will be read by a PC over USB as means of sending sensor information to the PC?