Does anybody from those who downloaded the firmware and possibly tried it have any feedback? How should I interpret the silence, with regard to initial eager requests? Please let me know whether it works or not with your device, so I can fix possible problems and publish the code. Thanks in advance.

Hi,

I have been meaning to look at this but I only just found a 1-wire supplier. I should be able to get hold of some sensors next week and I'll give it a go.

Looks like fun!
-(e)

What sort of things will you try? I tried stock SPI, bit-banged SPI, carefully managing the SCE (i.e. latch) line relative to SCLK, carefully managing the RST line relative to SCE, carefully managing D/C relative to MOSI, all the various commands (such as clear screen, inverse video, etc.) but I could not get the display to blink.

Hi,

If you have an Arduino lying about, test the display out with that first (I have both the Arduino and NetDuino).
This has helped me out in the past in identifying what the issue is, or at least confirming that my assumptions on setup and wiring are correct.
This should also eliminate the possibility that the display is broken (or otherwise )

If you haven't been taken up on your offer I'd be interested to have a look
-(e)

Hi, Its awesome you got this going I might have to get one now that you've done all the hard work -(e)

Well I'm going to give up for now I tried everything, I cut a connector from one of the cables and soldered the pins directly to it but I can't seem to get anything out of it.


I have 8 matrices and tried them all no luck with all of them. I really do not hope it is my netduino that is faulty or something.

I'm going to order a red 0832 matrix from sure to see if that one works for me..

One other thing I have thought of.. did you change anything in your firmware? maybe I have an older firmware or something? or isn't that possible, i'm such a newbee with Netduino

Hi,

Damn this is frustrating!

I run custom firmware for the bitbanger mod I made but this should not be a issue (the code attached is the original code I developed on stock firmware).

Do you by any chance have an Arduino? If so try the code from Miles Burton (linked in the first post) with your matrix and see if that works.

As a last option I reflashed with the original firmware to make sure there were no funnies there:
4.1.0.3 firmware

Then rebuilt the attached code and deployed it, it runs as expected. Try and do the firmware update, just in case. I have a watch on this topic so post back when you get the red matrix. I'd love to see this resolved!
Now to reflash back to custom...

-(e)

Whoot Whoot! Solved it! I tried the link you provided with the 4.1.0.3 firmware flashed the firmware and after the upgrade was finished I instantly saw something displayed on my Matrix!!

So the solution was flashing the updated firmware, now I have the same result as in the video posted earlier but the with my Netduino!

Thanks a million for helping me out! I will now try to make some extra functionality to run more than one display for example.. or do you have more recent code?

YAYAYAYAY!! Awesome!

I have some more recent code that uses the custom bitbanger firmware to really blast the display (it so much faster its unbelievable).
I need to fix it up so that compilation is conditional i.e. you don't need special firmware, and I have optimised the font drawing and some other bits.
I'll take a look tonight and see if I can post it up.

-(e)

Very cool! You've implemented "bit banged" variable-bit SPI using managed...doubly cool.

I really can't take too much of the credit, its mostly Miles Burton's code, but thanks
I think that is definitely part of the speed issue as is the memory access on the buffer arrays.

I need to have a look at that...
-(e)

Thanks for the picture! My configuration is exactly the same! So it can't be the wiring, you said the 2416 won't work because of a different pixel mapping.. I have read somewhere that the pixel mapping of the green 0832 is different from the red 0832 too just like the green 2416 pixel mapping is different from the red one.

The code runs just fine I have checked if the matrices are getting power. I really have no idea what is going wrong.

This is what is on the back of my 0832:

Is that the same as yours?

Thanks again for your help! I really hope I can get it to work!

I can't imagine the mapping is different if they are using the same display driver... I have the Yellow one btw.
Here is a close up (sorry about the washed out look, but the lighting in my study is terrible at night)


The only other thing I can suggest is that you have a bad connection. My clock line was dodgy initially and nothing would display.

HTH
-(e)

Hi,

Attached is some code to drive the HT1632 LED Matrix chip as found in the Sure Electronics DE-DP13212 and similar boards (Sure Electronics).
The code is horribly slow at the moment as a raw bit-bang approach is used to communicate with the HT1632 (and I am sure my horribly un-optimsed code does not help )
I will migrate this to SPI once variable SPI is available. At any rate here it is to look at.

This code was ported from Miles Burton's Arduino code and is released under the same GPL license.

Any pointers on optimisation would be great as C# on an embedded device is very new to me!

Connection is 5 wires:
Power and ground to 5V and GND pins.
ChipSelect to digital pin 4
Clock to digital pin 13
Data (WR) to digital pin 12

Hope this helps someone. I will attempt to optimise this to make it useful and to support the 2416 boards as well.
-(e)

Cool stuff Sweetlilmre!

I'm trying your sample with some of my 0832 boards here but I can't seem to get anything displayed on it. I have to say it are the green 0832's from SureElectronics and not the red ones don't know if that makes any difference. Just to be sure this is how I mapped the pins

NetDuino -------------- Matrix
Pin4 -------------- Pin3
Pin13 -------------- Pin5
Pin12 -------------- Pin7

Is that correct? or did I screw up

Hi,

Checking the 0832 Datasheet, your connections look good.
I assume you have also wired:

NetDuino GND to Matrix 11
NetDuino 5V to Matrix 12

Also that you have set the dip switches on the back of the matrix to 1=ON, 2=OFF, 3=OFF, 4=OFF?

Make sure you have the matrix connector orientation correct (I got it upside down the first time and wired 5V to GND... )
-(e)

Very strange, I did connect GND to pin 11 and 5V to 12 on the matrix, I also checked the CS selection switch and only 1 is on.. I have also some 2416 boards I tried one of those still no luck! Do you have a picture or something on how you wired yours? Or do you have any other ideas?

Thanks!

Does this help at all?



I just rewired it and tested it out. It all seems to work OK?
On the ribbon side, the pins are:

Green: Chip Select, pin3
Orange: Clock, pin5
White: Data, pin 7
Black: GND, pin 11
Red: 5V, pin 12

The 2416 will not work as the addressing mode is different. (well it might display something, but certainly not what is intended, I must get one of those to play with though...)

HTH

-(e)

Thanks alot for your help guys, I really appreciate it!

I am not sure how to go about measuring the pins, are you talking about physically checking their states or programmatically doing so? Sorry I am still very new to the hardware side of this!

My pins should be set up exactly to that in the diagram on Szymon's blog (as I have inspected my configuration several times!)

A few moments ago I did get some strange things appearing and being refreshed on the LCD screen. But have been unable to reproduce it.

Edit: The strange things appearing seems to be intermittent, it happened when I first turned it on this morning. Here is a picture...

Hi,

You may have:

• A bad ground, short etc.
• Misconfigured pin
• Inverted logic (bits in wrong order)

3. is affected by the MSB/LSB thing so should be easy to check.
2. you need to check your wiring again carefully
1. same as 2.

Edit: I have tried to puzzle out your wiring by looking at your breadboard picture, but there is not enough detail. If you could textually describe your wiring (what each pin of the shift register and LCD is connected to) that would help diagnose the issue.

HTH
-(e)

I thought I would have another go at it, so I soldered all the connections to the LCD this time, and it worked fine thanks for your help

Hi I'm really glad to see you got it going
-(e)

Thanks for your help, I think I have made those pin changes, I am using Syzmon's code at the moment, but am still struggling to get anything to appear. I have adjusted the display contrast as you suggested.

This stuff is hard to debug if you get it wrong

Can you give me the wiring between the shift register and the LCD pin for pin?
Also did you try and change BitOrder.LSBFirst to BitOrder.MSBFirst? Does that make a difference?

Step to the first SendCommand(0x03) and into that until the code has set the E pin high and sent the byte then check that the relevant pins on the output of the shift register are high / low.

Using the wiring I assume you are:

+--------- 0x80 d7
|+-------- 0x40 d6
||+------- 0x20 d5
|||+------ 0x10 d4
|||| +---- 0x08 enable
|||| |+--- 0x04 rw
|||| ||+-- 0x02 rs
|||| |||+- 0x01 backlight
7654 3210 

The byte should have been output as 0011 1011 to the Q7 to Q0 pin respectively:

Q7: low = d7
Q6: low = d6
Q5: high = d5
Q4: high = d4
Q3: high = E
Q2: low = RW
Q1: high = RS
Q0: high = BL

HTH
-(e)

Hi,

First off with respect to my previous reply: tie-ing Vo to ground only works for certain displays. I have 2, one works and one just shows black blocks i.e. the contrast it too high.

Secondly I have built the shift register circuit but my wiring was totally different to Szymon's and so I need to alter the code to allow a different pin assignment. I have implemented a dynamic mapping system that should allow any wiring configuration.

Please see attached code.

The BaseShifterLiquidCrystalTransferProvider now makes use of a ShifterSetup class which handles the pin mapping.

Setup (which you can find in the test program) looks like this:

  	// 2. use shift register provider
  	ShifterSetup setup = new ShifterSetup();
  	setup.AssignBit( ShiftBit.Q0, LCDPin.BL );
  	setup.AssignBit( ShiftBit.Q1, LCDPin.DB7 );
  	setup.AssignBit( ShiftBit.Q2, LCDPin.DB6 );
  	setup.AssignBit( ShiftBit.Q3, LCDPin.DB5 );
  	setup.AssignBit( ShiftBit.Q4, LCDPin.DB4 );
  	setup.AssignBit( ShiftBit.Q5, LCDPin.E );
  	setup.AssignBit( ShiftBit.Q6, LCDPin.RW );
  	setup.AssignBit( ShiftBit.Q7, LCDPin.RS );

  	var lcdProvider = new Shifter74Hc595LiquidCrystalTransferProvider( setup, SPI_Devices.SPI1, LED_Latch_Pin,
                                                         				Shifter74Hc595LiquidCrystalTransferProvider.
                                                           				BitOrder.MSBFirst );

Also in the test program I fixed the CreateCharTest() test method to clear the screen before writing the custom character, which seems to make it work properly on my display.


Thanks

Edit:

Here is a pic of my circuit:


-(e)

I am having trouble getting this to work I have used the code, and followed the wiring instructions here. I cant get the LCD to do anything other then turn on. Here is a picture of my current set up. Those LEDs just stay on/off as they are in the picture, and they should be flashing I think.

Any idea as to what I am doing wrong?

Thanks for your help

Firstly it looks like your contrast is at 100% (the completely white blocks would indicate this).
Try to just apply power (no signals lines) and turn the contrast down until the blocks almost disappear.

Secondly the Fritzing wiring diagram on Szymon's blog page is slightly incorrect w.r.t. the SPI port:

SHCP = PIN 13 (not 12)
STCP = PIN 10
DS = PIN 11

Thirdly which source are you using, Szymon's original or mine? If mine, have you configured the pin mappings correctly?

HTH
-(e)

Edit: one more thing you can try, once you have checked my points above is to change the MSB / LSB orientation of Szymon's code (if you are using his code). I had to change this to get my stuff working.

Hi,
I have finally published the library on CodePlex. You can grab it here http://microliquidcr...l.codeplex.com/
Basically the same code as previously published on my blog, just with few renames.

Please let me know if you have any suggestions on what can be improved.

Hi,

Thanks for the brilliant library
I just soldered up a pc1602f display in direct GPIO mode and it all works nicely.

As a tip for anyone else doing this, if you don't have a pot of the correct value, you can just tie Vo to ground for maximum contrast (this had me stumped for a bit, I thought the display was broken )

On Monday hopefully I will have my shift registers and I can try it with that.
-(e)

Does this BitBanger project have a home page and more information ?

Hi,

No it doesn't but should I'll try and generate some SandCastle or similar docco at some point.
-(e)

Hi,


UPDATE: this post has been updated with a newer version and firmware: 11/29/2010. This newer version provides SoftSPI like capabilities.

In my quest to make my HT1632 display useable I have developed a generic bit banger driver.

The attached archive unzips into the "MicroFrameworkPK_v4_1\Solutions\Netduino" dir.
If you want to build this yourselves you will have to build the managed solution and generate the client assemblies and then build the firmware as usual.

The speed increase in amazing when driving the HT1632 and I know that variable SPI is around the corner, but I thought this might be useful in a more generic context (the code should be device neutral).

The bit banger is constructed with a configuration class that describes two pins, one clock and one data.
Ownership of the pins then belongs to the BitBanger class.

public class Config
{
public Config( Cpu.Pin clockPin,
             		bool clockEdgeRising,
             		Cpu.Pin dataPin,
             		Cpu.Pin latchPin,
             		bool latchActiveState )
}

BitBang.Config config = new BitBang.Config( clkPin, true, dataPin );
// set data & clock pin modes
BitBang bb = new BitBang( config );

Additionally the latchPin and latchActiveState Config members allow for additional flexible latching behaviour.

public enum LatchBehaviour
{
	PerTransfer,
	Per8Bits,
	Per16Bits,
	Per32Bits,
	Never
}

LatchBehaviour is passed to the block blitting function and will toggle a latch line (or CS possibly) in a certain manner.
This is very useful for writing to shift registers in a continuous mode.


The BitBang class interface has some basic functionality:

These two methods bang out a stream of bytes, with each byte written from the MSb (bigEndian) or LSb and with optional latch behaviour.

public void Write( byte[] writeBuffer, int writeOffset, int writeCount, bool bigEndian)

public void Write( byte[] writeBuffer, int writeOffset, int writeCount, bool bigEndian, LatchBehaviour latchBehaviour )

And these two methods bang out up to 32 bits with the same endian functionality as above.

public void Write32( UInt32 data, byte numBits, bool bigEndian )

public void Write32AndLatch( UInt32 data, byte numBits, bool bigEndian )

I have attached 2 files containing the compiled firmare (tinyclr.hex.zip) and the source code (bitbang.zip).
Included in the source code is the compiled client assembly which you will find under the MicroFrameworkPK_v4_1\Solutions\Netduino\ManagedCode\SecretLabs_NETMF_Hardware\bin\Release dir.
You will need to reference this assembly or replace the one provided with the NetDuino SDK in order to use the BitBang class.



Hope this is interesting / useful
-(e)

Hi

Does the Bitbanger need an external clock signal to work (that is what i beleive)?
How is the performans, how long from a clock until output, how fast can the next output bee, and so on ?
Does it sit in a tight loop doing the work, or is it interupt driven? I have seen an issue with Interupt latency but perhaps that is only for managed code.

Would it be possible to have it internally clocked, something like the OutputCompare, were you have an array of delays and the bit values.

/Jan Olof

Hi,

The BitBang will toggle the clock line for each bit of data output, in a tight loop, as fast as possible.
This is handled by the interop layer and is written in raw C code (well a C++ function, but effectively raw C) and should have a very low latency i.e. this is about as fast as it is possible to toggle pins without offloading to something like SPI.

Internal clock could be possible but is probably somewhat out of scope for the BitBang code. Perhaps there could be an extra parameter to introduce a fixed per bit delay if this was a valid use-case? i.e. delay X microseconds after each clock pulse.

-(e)

No Joy

I can add the code in and that all seems well but I cannot get the LCD to play nice. It's all a bit beyond me on how to talk LCD..

Cheers,
Crispin

Hi,

Do you have any specifics on the issue? What LCD, wiring etc?
Maybe we can figure this out.
-(e)

Those links are pretty daunting for someone coming new into this technology. After reading those links am pretty sure I have no desire to go native for some time. That said, the current method of direct pin control is too slow. I tried FEZ Panda and it has the same slow pin speed, I guess it is the .NET layer. This seems very similar to standard pin control in the arduino being too slow, in which direct port access helps at the cost of portability.

This bit banger driver seems to be a great solution for this problem.

Is there is a way to put up a test firmware with big banger included? That would help see if bit banging will do the trick.

I would think having bit banger built in would be best case. Is there a case to not include bit banger in the base outside firmware size?

Thanks for building and posting bit banger, good to know there is a way to have fast pin access like direct port access in arduino.

Hi,

Yep the interop is well scary the first time around. I had to bang my head hard to get it to work as there was some obscure bug in my code (a naming issue with a lib and an incorrect .proj file).

Its probably worth getting to know though. As far as posting a firmware image I can do that, but as I have had no luck in compiling with RVCS I can only give you a GCC based image which will require flashing your boot loader via SAM-BA as well. Are you comfortable with this?

I have been playing with the code and have managed to slim the size down significantly and keep the functionality. Perhaps I can convince Chris to add it to the main source tree.

-(e)

Hi sweetlilmre,

We'd love to look at putting this (or something like it) into a firmware update.

Chris

Awesome

The code is yours to do with what you will. I have made some improvements though so perhaps I should get you the new version.
I would appreciate your thoughts on this:

The basic functionality is now wrapped into a class that provides two native methods:

  [MethodImpl( MethodImplOptions.InternalCall )]
  private extern void NativeWrite( Cpu.Pin clockPin, Cpu.Pin dataPin, byte[] data, int writeOffset, int writeCount,
 									bool risingClock, bool bigEndian );

  [MethodImpl( MethodImplOptions.InternalCall )]
  private extern void NativeWrite32( Cpu.Pin clockPin, Cpu.Pin dataPin, UInt32 data, byte numBits, bool risingClock,
   									bool bigEndian );

risingClock

allows for a rising edge clock signal (true) or falling edge (false)

bigEndian

indicates the bit order i.e. true = most significant bit first, false = least significant bit first. This applies on a per-byte basis for the Write() method and across the 32 bits for the Write32() method.

numBits

number of bits to process for Write32(). In bigEndian mode this indicates the start bit i.e. numBits = 9 would bitbang bits 8 to 0 in that order

Public methods wrap the internal methods to prevent passing a Cpu Pin that has not been assigned to an OutputPort (I could have passed the port to the native method but the marshalling is more complex and slower that way). Also resource management is handled by the containing class.

This seems to be the best compromise I could come up with in terms of speed and efficiency.
Unfortunately I left my NetDuino at work so I will only be able to test these changes tomorrow.

In terms of naming conventions / namespace, I would like to build this so that it is a drop in with the least amount of work for you. How would you like me to do this? Should I extend code inside the SecretLabs namespace? I am happy to assign all rights etc. over to you in this case?

-(e)

[edit: for numBits clarification]

Hi,

Chris:

I have taken the liberty of moving the code into the SecretLabs.NETMF.Hardware namespace.

Attached is a zip that should be extracted into the Solutions\Netduino\ folder and will:

• update the Solutions\Netduino\DeviceCode\SecretLabs_NETMF_Hardware folder with the bitbang code
• add the managed project source code into the C:\MicroFrameworkPK_v4_1\Solutions\Netduino\ManagedCode\SecretLabs_NETMF_Hardware folder

I discovered that the "SecretLabs.NETMF.Hardware.featureproj" file was pointing to the debug assembly, so I changed that to point to release and made the reference endian independent. You will obviously need to compile the managed code in release mode before building the firmware in order to generate this reference.

I tested the firmware against the LED matrix code and it all seems to work nicely.


Hookedup:

I hope this works for you, let me know how it goes.

Thanks
-(e)

Folks,

After much frustration I've found out (think) my LCD won't work because of how I am talking to it. It would appear this is my solution.

Any chance of a nice step by step walkthrough on how to get this working? I've flashed the new bootloader and flashed the firmware with sweetlilmre copy but am non the wiser as to how to proceed.
after much searching on my machine for anything that resembled "C:\MicroFrameworkPK_v4_1\Solutions\Netduino\ManagedCode" I worked out I actually had to install the Porting kit from MS. From there, I am still lost.

Any help for a total noob at this? Any hint as to when it would be in the native firmware, even as an alpha? I would be happy to use that.


Thanks
CP

Hi,

If you have flashed the firmware I provided then in the zip file should be an assembly that you can reference.
Once you've referenced the assembly in your project you can call the bitbanger driver (you don't need the porting kit etc. unless you want to compile your own firmware).

You are looking for "NetDuino.Hardware.BitBang.dll" in the zip file. Reference that and then instantiate the class and call appropriate methods to setup the gpios etc.
-(e)

Hi Sweetlilmre,

If you have the time can you please explain to me how I can get this bitbanger driver to work with the Dot Matrices from Sure Electronics? or can you update your example of the Led Matrices with this driver?

Thanks,

Ramon

Hi Ramon,

I will try to get to this as soon as possible, unfortunately life is a little crazy at the moment
-(e)