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!

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?

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

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

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

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.

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

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?

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.

That is great news, good luck with your project!

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.

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

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.

Much better, it's a shift register and you can probably use SPI to read it. MISO, CLK and CS pin for latching before reeling in the bits. ...or you could use the MCP23S17 chip, it has 16 pins controlled with SPI. With the driver I wrote for it, you can easily create a 16 bit wide parallell databus and just read them all into a single unsigned short variable:

ushort my16bits = bus.Value;

Here's the driver with some examples: http://forums.netdui...17-io-expander/ The driver can also alert you with interrupts whenever any of the 16 pins changes.

Thanks, glad you liked it! Regarding having multiple SPI devices sharing the same SPI bus as the MCP23S17, I eleborated over that in the post that I made over the driver software: http://forums.netdui...der/#entry56306 Also, I think you need to use the "inhibit" pin or similar on your shift register to sort of turn it off while using the SPI bus for other purposes.

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?

Yes, I believe it whould be very hard to modulate that in managed code.

 

If I'm not mistaken, you need about 10 times the freq of the highest note. With maybe ~8khz for the "ssss" sounds (?), you would need ~80kHz of PWM.

 

That is of course no problem in itself but you also need to be around to change the duty cycle every 125us and even if you manage that, there would be very little time left for other processing and I suppose there are quite some.

 

EDIT: Oh, and this is the song from your video. I find your robotic vocals slightly more rhythmic though 

Sounds like my old A500 once did when fooling around with speech from within A-Basic. We used phonetics to try and make it speak swedish with some quite amusing results. Very interesting, I sure didn't know that RAM/ROM thing but just took for granted those where stored on flash and not read into ram until upon actually used. That knowledge would probably explain a thing or two that I've experienced when seen those "failed to allocate x blocks" debug outputs. Without having looked in the zip file (I'm on a tablet that can do unzip) nor checked the d/s of that vintaged speech synthesis chip of yours - what exactly are you using for playback? You mentioned a synth and by that, do you mean Netduino PWMs or some actual external h/w not seen in the video? Is there perhaps some kimd of schematics or wiring diagram inside the zip or could you just roughly describe how you wired this thing?

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.