Hello hanzibal,

Well yes i will reach that approach soon , actually i am planning to use this ram to work with my HttpLibrarV3 So that it stores all the requests and manipulates them from the ram instead of an internal buffer hence making alot of free memory for code use and variable allocation,

my next project will be itegrating the ram with the HttpLibrary

Cool!

 

I really love this kind of small IC drivers, they're just so nice to have when you need them. It's really stupid we don't have a central repository for these kind of things.

 

As an example, people (including myself) keep making those LCD drivers with multi channel I2C support over and over...

Nice!

 

Many stream type classes can be created by passing a System.IO.Stream to the constructor. I'm not sure for which this holds true but I think it goes for TextWriter, StringWriter, XMLWriter etc.

This would mean that if your class RamStream where to inherit from the System.IO.Stream class (and implement a few basic methods), you could pretty much store all kinds of data onto that nifty little chip.

 

For example, I think it would let you implement memory files so that you can pass in a such a "virtual file" to any method expecting a regular FileStream.

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.

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?

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.

One would think you were in control of what devices are accessing your local network?

At least I think I am - of mine, not yours, that is :-)

Sure it counts as a project, more than well!

I've done a fair deal of similar RF control stuff too and found it very rewarding.

Very interesting and great news!

I actually didn't think Netduino was fast enough for bit-banging this (not even Netduino 2) and thought you had at least use SPI for this.

The natural next step would be adding a webbserver so that you can use a smartphone as a remote control but I guess you already thought of that.

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.

I agree, the byte order is equal to that of the Arduino code.

 

In my experience floating pins can sometimes result in strange phenomena and I try to avoid them even if it theoretically shouldn't matter. I normally use 100k pull-downs on unused pins though.

 

You could try using stronger I2C pull-ups, say 4k7 as see if that helps.

Yes, two 10k resistors i parallel should correspond to a single 5k resistor. Well, it was just a thought.

 

Looking again at your code and comparing to the user manual you referred to, it seems you're are doing the reads wrong. You should read location 2 and 3 separately to get the high and low byte respectively. As it is now, you issue a series of four transactions where the read buffer gets overwritten by the the second read transaction. Your read buffer is 2 bytes but I think it only need be one byte since first you should read the high byte and then you read the low byte (the order does not seem to matter).

 

Also, I believe the location counter (address counter) auto-increments for each read performed so you could probably do something like this instead (here, the read buffer is still 2 bytes long):

xActions = new I2CDevice.I2CTransaction[]{	I2CDevice.CreateWriteTransaction(new byte[] { 0x02 }),	I2CDevice.CreateReadTransaction(RegisterValue),}int c = srf02.Execute(xActions, 1000);Debug.Assert(c > 0, "I2C write/read failed!");int val = (RegisterValue[0] << 8)|RegisterValue[1];

As you know, the Netduino is 5V tolerant and I wonder if the the LLC is really necessary - have you tried without it?

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!

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.

When cascading as depicted on page 13 of the d/s, you don't send data to a certain chip, instead you just clock out the data bits in a series out the MOSI line and into the shift register of each chip. When all bits are in place, you assert the load pin for all chips at once and each chip will load whatever command there is sitting in its shift register at that point.

Of curiosity, how come you need more than 16 digits?

Judging from the RegisterAddressMap enum, there seem to be an 8 digit limit to the driver.

The enum is conceptionally mistreated. They way they are defined, they are not meant for you to apply arithmetics operations onto them.

Surely, as the corresponding enum values just so happens to be 0,1,2,3...etc because of the order in which they appear, you consecuently happen to get "digit1" by adding a one to "digit0". However, when adding a one to "digit7" you suddenly get "DecodeMode" instead of "digit8" which is not defined.

See what I mean?

Those are the values assigned by default so it won't change anything.

Actually, the MAX 7219 and 7221 are 8 digit driver chips but they support daisy-chaining while the driver class apparently does not.

https://www.sparkfun...219-MAX7221.pdf

The solution is to modify the driver so that it supports cascading.

I was unaware of the need for inversion, I always use a regular Prolific USB to RS232 cable (think it has the 2303 chip) for flashing tinybooter onto my minis without problems (have used two different ones over time).

 

Since I've never had to interface with any RS232 devices in my apps, I've only used the TTL UART (pins 11 and 12) for deployment and debugging using a classic FTDI USB to 3V3 TTL UART cable which also supplies 5V to pin 21.

 

Are you flashing the RS232 version of tinybooter in order to free up the TTL UART for application use?

I also came as far as the "platform independent driver" but no further.

 

That "Super WiFi mini" idea of yours is awsome - I'd just love to see that realized! We could ask CW2, he usually ports tinyCLR to any h/w in a couple of days, well almost anyway  The Spark is open h/w so SL could make their own .NET version 

 

After some more investigations, you could perhaps create a separate thread about the Super WiFi mini in hope of attracting someone with the right skills to help realizing it. I don't play in that leage but I think CW2 and Ziggurat29 are two of the guys that do. 

Hi!

I think some work has been done in this direction, google returns some hits when searching for usb + cdc:

http://lmgtfy.com/?q...o.com usb + cdc

Also forum member Oz made a HID keyboard a while back:

http://forums.netdui...d-updated-code/

In either case, I think the normal programming/debugging device will no longer be available so you have to switch to serial deployment.

Hopefully, the above will get you started. Good luck!

@baxter: Coincidentally I saw the cc3000 wifi module yesterday, it looks interesting but I've been unable to find documents describing the SPI interface on how to interface.

Have you found some SPI docs or are you planning on porting the MSP430 code?

About a year ago, I got one of the earlier wifi modules from TI/LSR and haven't found any SPI docs for that either.
http://www.ti.com/pr...RMAL&mpref=full

A big advantage of these boards over most others is that they use SPI instead of UART which is typically much slower. There are also the Redpine modules which look very nice:

http://www.semicondu...idproduct=43957

@baxter: Thanks, I just wanted to make sure I got it straight. For me it's usually the other way around, I want two TTL UARTs and so that's why I didn't quite follow initially. Now it's perfectly clear.

See what you mean now, it's nice to be able to use the same cable for both ports. Since COM1 expects TTL levels, I suppose the inverter does signal level conversion too? However, in my experience COM2 (pins 1 and 2) does does not expect an inverted signal, rather it seems your PICAXE does. From what I know, COM2 implements industry standard RS232 signal levels, i.e. positive voltage is a logical zero and negative voltage is a locical one and in the mini case these voltages are -12V and +12V respectively. On, the other hand TTL UART levels are usually active low (idle high) with GND for ones and Vdd for zeros and so these levels are kind of the inverse of RS232. Am I right?

That last doc looks more like a broschure for TIs wireless tech in general, wrong link? Suppose you mean this:
http://processors.wi...Interface_(SPI)

This is the board I got:
http://www.lsr.com/d...ts/330-0086.pdf

It's based on the cc3000 chipset so I guess it would work using the same driver as your cc3000 board, if there was one that is...

Hmm...maybe one should get busy creating a managed driver from porting TIs driver looking at the Arduino code you referred to. Great deal of work involved though and probably a lot more than I can afford to spend right now but it itches ;-)