Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.

hanzibal's Content

There have been 386 items by hanzibal (Search limited from 28-April 23)


By content type

See this member's


Sort by                Order  

#56330 Extensive driver for the MCP23S17 I/O expander

Posted by hanzibal on 24 February 2014 - 08:46 AM in Project Showcase

I'm sorry it's not working out as hoped. It's a bit strange since "port0000" would be the GPIO_NONE pin and that an attempt has been made to use it more than once. I'm thinking maybe the cast returns zero for some reason? This occurs while in the loop creating one of the output ports right? EDIT #1: Pin numbers can be given in any numeric format, the binary value will be the same either way.

 

EDIT #2: Made a few small updates to the code, probably nothing but you could try updating.

 

EDIT #3: What does your main chip and port creation code look like at this point?




#56327 My daydream - FPGA/ARM platform

Posted by hanzibal on 24 February 2014 - 06:55 AM in General Discussion

Don't let me tempt and lead you a stray now, keep your eyes on the road and your hands on the wheel there chief! Ha, ha - I got a special folder on my desktop saying "cool stuff" and a similar one in my email plus tons of little things in anti static bags (many of which are still unopened). I'd say I got gizmos, chips and kits to span a few life times of tinkering but I don't mind, most of the stuff was really cheap and dreaming of what to do with them is free :-)



#56322 My daydream - FPGA/ARM platform

Posted by hanzibal on 24 February 2014 - 12:30 AM in General Discussion

After this I actually started working on something vaguely similar to my "day dream" but then (as I predicted), put it on hold for an undefined amount of time in favor of other more urgent or interesting projects. I got as far as a simplistic simulator of digital electronics with a built-in on-line repository and the idea (dream) was to somehow being able to render the "hardware models" on an actual cpld or fpga board. Recently however, I spent some time playing around with a PSoC 1 eval kit from Cypress that I had laying around unused for a year. Naturally, it turned out the guys at Cypress had already accomplished more or less what I was thinking of maybe doing - and it has been around for quite some time too! Basically, the PSoC designer software (graphical IDE) lets you drag-drop blocks implementing stuff like op amps, filters, PGAs, comparators, timers, PWMs, DACs, ADCs, etc onto a canvas using a GUI. You interconnect data lines of a matrix using muxes and you can have the integrated 24Mhz micro controller interact with your blocks. I found it all totally awsome and ended up having implemented a stereo headphone amplifier with built-in NEC IR decoder (volume, balance and a few other features) with surpricingly good sound quality in a single DIP-8 package - my very first ASIC for crying out loud :-) image.jpg So, if you need a specialized chip to help your Netduino in performing some sub task, you can use PSoC to create a device that does the job and then just snap it down your breadboard alongside your Netduino. Such sub tasks could be small but timing critial work or some special analogue processing. You'd then transfer the results to your Netduino and have it readily available for conveniant processing in .NET C# (or VB) - the latter of which PSoC does not offer. PSoC can act as Netduino's little helper!



#56319 Extensive driver for the MCP23S17 I/O expander

Posted by hanzibal on 23 February 2014 - 10:24 PM in Project Showcase

....Any ideas?...

I just updated the driver code in post #1 - it now contains an internal light weight multiple SPI manager so you shouldn't be getting that exception anymore. Please try it when you can and report back since I haven't actually tested it myself yet :unsure: because all my Netduinos are occupied :) This also means sharing a single SPI bus among multiple driver instances should work, both when cascading using a shared CS line and when using separate per chip CS lines. EDIT: Sorry for messing with your code, but may I suggest:
for (int ic = 0; ic < icCnt; ic++){    chip[ic] = new MCP23S17(SPI_Devices.SPI1, Pins.GPIO_PIN_D10, Pins.GPIO_NONE, ic, 7000);    // Define all outputs    for (int pin = 0; pin < pinCnt; pin++)        Outs[16 * ic + pin] = chip[ic].CreateOutputPort((MCP23S17.Pins)(1 << pin), false);}
Really anxious to know if the driver works with your board!



#56315 Extensive driver for the MCP23S17 I/O expander

Posted by hanzibal on 23 February 2014 - 10:04 PM in Project Showcase

Cool, so you "only" need to write your own LcdProvider class where you would then make internal use of the MCP23S17 driver in creating and using a bus from the pins you supply in the parameter list above - correct?




#56313 Extensive driver for the MCP23S17 I/O expander

Posted by hanzibal on 23 February 2014 - 09:08 PM in Project Showcase

ok.. another great work Andy. so... actually i dont need to drive LCD display using M74HC595. I think it should be easier to drive it using MCP2317.... :rolleyes: thanks in advance for hanz and andy.

Yes, that's an excellent idea - and it would be really cool to see the software being used to drive an LCD too! TIP: Try using BurstWrite on a bus... Thanks to the pins A0,A1,A2 of each chip (reflected through the hwAddr constuctor parameter), you can cascade up to 8 chips on the same SPI bus producing a maximum of 128 GPIOs all with the same CS line - but, I need to make a few adjustments to allow the same SPI module to be shared among multiple driver instances. At present, such an attempt would result in an exception of type "resource already in use" or something like that - just like mcinnes01 just experienced. NOTE: The driver is for the SPI version, e.g. the MCP23S17 with an "S" in the middle - not the regular MCP23017 which runs on I2C.



#56312 Extensive driver for the MCP23S17 I/O expander

Posted by hanzibal on 23 February 2014 - 09:05 PM in Project Showcase

Yes it is because you are passing in the same SPI module to multiple driver instances.

 

As I said earlier, the driver does not yet support the same SPI module being shared among multiple driver instances.

 

I have to make a few adjustments for that first.

 

Also, I think your pin numbering might still be wrong - you must use values that are integer power of two, e.g. 1,2,4,8,16, etc. Have a look at the example I provided in post #15 above where I'm bit shifting like this "1 << Counter".

 

While waiting for me to update the code, you'd probably benefit more from verifying the driver works in getting a single single chip up and running.




#56307 Extending Digital Input using game Controller

Posted by hanzibal on 23 February 2014 - 05:38 PM in General Discussion

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.



#56306 Extensive driver for the MCP23S17 I/O expander

Posted by hanzibal on 23 February 2014 - 05:32 PM in Project Showcase

You should avoid reading the code :-) I should probably supply more examples to make things clearer but basically you create input, output and interrupt ports in much in the same way you create any Netduino digital port. Furthermore, you can create buses that are collections of multiple pins that you can use in parallell. To answer your question in the other thread regarding using the driver along side of other SPI slaves on the same SPI bus - yes, it is possible to share the SPI bus with another slave but you will be facing the same problem that you always do with multiple SPI slave devices on the same bus. You need some software mechanism to change between different SPI configurations in run time between communication with one or the other slave devices. There have been a number of such very similar "multi SPI" implementations avaialable and I would gladely add support for one. Unfortunately, there's no standard - naturally, everybody who's had the problem have also developed their own solution for it. I think I will make an attempt at adding some kind of generic multi SPI support and will return to that later.



#56297 Extending Digital Input using game Controller

Posted by hanzibal on 23 February 2014 - 01:32 PM in General Discussion

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.



#56290 Extending Digital Input using game Controller

Posted by hanzibal on 23 February 2014 - 10:36 AM in General Discussion

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?



#56276 LCD-Boost library for Netduino

Posted by hanzibal on 22 February 2014 - 02:16 PM in Project Showcase

Thanks, the 128x64 LCD driver and perhaps getting an Eve kit are two separate "projects" and for now, I'm just speculating over the different possibilities around these.



#56273 LCD-Boost library for Netduino

Posted by hanzibal on 22 February 2014 - 12:46 PM in Project Showcase

You are right, I should probably use another micro in between and have that expose a higher level API over SPI. I got a couple of cy8c29466 chips that can do the job - they are not perfect but I know how to program them. Roughly, how should such an SPI interface be organized in order for it to integrate as smootly as possible with your GDI library? Yes, I've already read your blog about the new FTDI Eve module with great interest and chances are I'm getting one because their super cool and would be perfect for any home automation project. I wish they had put a USB to SPI bridge on the eval board to omit the need of the separate USB module though - because the on-board USB connector is just for power right? I got a couple of 3.5" 320x240 TFT displays with resistive touch film on them and it seems they are the same as the ones FTDI uses in their kits. Sure, pricing is good enough to buy a kit that includes a display and skip the hazze but it would be really nice to be able to use the ones I already got.



#56270 LCD-Boost library for Netduino

Posted by hanzibal on 22 February 2014 - 09:44 AM in Project Showcase

Sure, I was thinking more in terms of your lib copinh with how the LCD "frame buffer" is organized. For example, there are two "chip select" pins (one for each screen half) and Y addressing is autoincremental while X is organized in 8 pages of eight pixels, eg the 8 bit databus. I probably don't have any need for reading the chip other than maybe the busy flag and that would require one bit of the databus being bidirectional.



#56265 LCD-Boost library for Netduino

Posted by hanzibal on 22 February 2014 - 03:14 AM in Project Showcase

Hi Mario! Would the LCD-Boost library work with a 128x64 LCD like this one: http://www.fractroni...12864b_full.pdf It uses two KS0108B controllers, one for the left and right half part of the display respectively.



#56264 Netduino and FTDI EVE Board

Posted by hanzibal on 22 February 2014 - 03:07 AM in Project Showcase

Totally awsome Mario, great work!



#56262 Extensive driver for the MCP23S17 I/O expander

Posted by hanzibal on 22 February 2014 - 01:30 AM in Project Showcase

Looking great! A couple of things though: 1. You should connect D12 to MISO (assuming you got a Netduino 2). 2. There's a bug in your code - when looping to create your 16 output ports, you cannot pass in counter values 0,1,2,3,4,5,6,...etc casted as pins since these need be integer powers of two, e.g. 1,2,4,8,16,32,64,...etc. You can achieve this like so:
for (uint Counter = 0; Counter < pinCount; ++Counter)    Outs[Counter] = chip1.CreateOutputPort((MCP23S17.Pins)(1 << Counter), false);
However, I really think you should be using the enums, then your code will be easier to read and will work even if I change the implementation. For example, you would have avoided the above bug :-) I see your expander board has the IRQ pins broken out after all which is great news but you might want to add that later when you got the basics working. Hope this helps!



#56236 Extensive driver for the MCP23S17 I/O expander

Posted by hanzibal on 20 February 2014 - 09:23 PM in Project Showcase

Oh and even though its probably obvious, I should maybe point out that the driver presents the two banks (A0...A7 and B0...B7) as one consecutive pin array 0...15. Microchip tend to use "bank switching" due to legacy tech in how registers of their MCUs are mapped to memory. Most of their chips are probably PIC 18's running custom read-only firmware :-)



#56234 Extensive driver for the MCP23S17 I/O expander

Posted by hanzibal on 20 February 2014 - 08:23 PM in Project Showcase

Yes, see my last post on how to use one of the chips. Good luck and please be sure to report back on how it worked out for you!



#56232 Extensive driver for the MCP23S17 I/O expander

Posted by hanzibal on 20 February 2014 - 08:00 PM in Project Showcase

I guess I could add another constructor to better suit your needs, but it turns out its a little more complicated than that.

 

For now you can specify Cpu.Pin.GPIO_NONE for the IRQ pin like so for the first chip using hwAddr=0:

var chip0 = new MCP23S17(SPI.SPI_module.SPI1, Pins.GPIO_PIN_17, Cpu.Pin.GPIO_NONE, 0, 7000);

and like so for the second chip using hwAddr=1:

var chip1 = new MCP23S17(SPI.SPI_module.SPI1, Pins.GPIO_PIN_17, Cpu.Pin.GPIO_NONE, 1, 7000);

In cascaded mode, these chips can, not only, share the same SPI bus but also use the same chip select (!CS) line because they (as with your board) can use the hardwired address pins (A0,A1,A2) to differentiate bus messages as belonging to one or the another chip. This is a feature to reduce the number of IO lines required meaning that you can have up to 8 chips connected to the same four pin SPI bus.

 

However, because I never got around to testing the driver in cascaded mode with multiple chips, it turns out it currently doesn't support running two instances simultaneously. This means that, until further, you'll have to settle for using one of your chips at a time.

 

I'm afraid you have to bare with me until I've had the time to add support for sharing the same SPI module between multiple instances.




#56229 Extensive driver for the MCP23S17 I/O expander

Posted by hanzibal on 20 February 2014 - 05:48 PM in Project Showcase

Ok, I've fixed the hwAddr bug and updated the driver source code file of the first post in this thread.

 

About your board, I can't find any schematics and can't tell from just looking at the pictures how the A0,A1,A2 pins of the chips are connected but looking into their source code, it seems one chip has h/w address 0 (zero) and the other has h/w address 1 so you should just pass in those values and it should work.

 

This means you have to create one driver instance for each of the chips.

 

At a first glance, it seems they haven't broken out the IRQ pins of the chips which is too bad because then you cannot use the interrupt functionality of the driver.

 

The driver class has multiple constructors, normally you simply choose the one that fits your needs, e.g. the one without the IRQ pin parameter but when come to think of it, I'm uncertain as of there is a constructor that 1) has the hwAddr parameter and 2) does not have the IRQ pin parameter. I'll have to look into this and will get back to you.




#56225 Own IO Shield

Posted by hanzibal on 20 February 2014 - 10:26 AM in Project Showcase

That Richard's pretty good :-)



#56217 Extensive driver for the MCP23S17 I/O expander

Posted by hanzibal on 20 February 2014 - 07:29 AM in Project Showcase

Yes, there's an optional constructor parameter hwAddr to be used when cascading multiple chips. The IRQ pin is optional, you only need it if you require interrupts on input pins. Regarding pin assignents, could you point me to the board you've got so that I can have a look? EDIT: To calculate what value of hwAddr to use, you must first figure out how pins A0,A1,A2 are wired on your expander board - they will be tied to gnd or vcc in any contellation forming a binary number for you to specify for the hwAddr parameter. Oh and I just discovered a bug regarding how the driver treats hwAddr so please wait for me to update the code file attached to the original post above!



#56205 Extensive driver for the MCP23S17 I/O expander

Posted by hanzibal on 19 February 2014 - 02:07 PM in Project Showcase

Here's a series of example on how to use the driver.

using MCP23S17Lib;// print code versionDebug.Print(MCP23S17.Version);// create a new instance of the driver class using pin 17 for !CS and pin 18 for IRQvar io = new MCP23S17(SPI.SPI_module.SPI1, Pins.GPIO_PIN_17, Pins.GPIO_PIN_18);// create an input port for MCP23S17 pin 0var p0 = io.CreateInputPort(MCP23S17.Pins.GPIO_0);// create an input port for MCP23S17 pin 1var p1 = io.CreateInputPort(MCP23S17.Pins.GPIO_1);// create an output port for MCP23S17 pin 2var p2 = io.CreateOutputPort(MCP23S17.Pins.GPIO_2);// set p2 to the logical AND between p0 and p1p2.Value = p0.Value && p1.Value;// toggle p2 a few times (really quickly)p2.BurstWrite(new bool[]{true, false, true, false, true, false});// create an interrupt port for pin 12. Apply a weak pull up and have it fire interrupts on low edgesvar ip12 = io.CreateInterruptPort(MCP23S17.Pins.GPIO_12, MCP23S17.PullupMode.Pullup, MCP23S17.InterruptMode.EdgeLow);// attach an interrupt handler to pin 12ip12.OnInterrupt += (MCP23S17.Pins pin, bool value, DateTime time) =>    {        Debug.Print("Interrupt occurred on p12!");    };// quick and dirty single line interrupt handler on pin 14 with defaults (no pull up, both edges)io.CreateInterruptPort(MCP23S17.Pins.GPIO_14).OnInterrupt += (MCP23S17.Pins pin, bool value, DateTime time) =>    {        Debug.Print("Interrupt occurred on pin " + pin.ToString());    };// create a 4 pin output bus (MSB first)var bus = io.CreateBus (    io.CreateOutputPort(MCP23S17.Pins.GPIO_6),    io.CreateOutputPort(MCP23S17.Pins.GPIO_5),    io.CreateOutputPort(MCP23S17.Pins.GPIO_4),    io.CreateOutputPort(MCP23S17.Pins.GPIO_3));// set pins 6 and 4 to logic highbus.Value = 10;// create a 5 bit mixed bus of both inputs and outputs// which must be consecutive (e.g. not scarse)var mixbus = io.CreateBus(    io.CreateInputPort(MCP23S17.Pins.GPIO_11),    io.CreateOutputPort(MCP23S17.Pins.GPIO_10),    io.CreateInputPort(MCP23S17.Pins.GPIO_9),    io.CreateOutputPort(MCP23S17.Pins.GPIO_8),    io.CreateOutputPort(MCP23S17.Pins.GPIO_7));// this will only effect output pinsmixbus.Value = 0xffff;// this will read all five pins ushort mixbusvalue = mixbus.Value;// attach an interrupt handler to the mixed bus mixbus.OnInterrupt += (ushort interruptmask, ushort value, DateTime time) =>{    Debug.Print("Interrupt occurred!nBus value is " + value.ToString());

The above example uses SPI module #1 and pins 17 and 18 on a Netduino mini but you can easily change it to work on other pins and on any Netduino model, just change the first lines.




#56202 Networked music player using the mini

Posted by hanzibal on 19 February 2014 - 12:15 PM in Project Showcase

Great, that you found it useful! I saw your antique radio project and I really love the mix of new and old that you get from putting new internals in old machines. My late mother used to have one similar to yours, you'd have to wait for like 15 minutes for it to get warm before you could use it. Sadly, we didn't keep it. Cheers!




home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.