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)

This is awesome Let us know how the locking code goes, and can you tell me what you used to do the video? It looks really good and would be a nice alternative to a blog post for me to try out sometime. Thanks -(e)

Wow!
It always amazes me how well people can reverse engineer circuits. Well done!

Very nice, sweetlilmre!

We may need to have a "junkyard" challenge in the future

Thanks It was a good bit of fun and luckily not too difficult. There is a newer model of this decoder with a totally different display circuit / bus that I want to look at next. Only one 7-segment display, but 3 buttons and an IR receiver... this one looks challenging!

Hmm a Junkyard challenge sounds excellent....
-(e)

Hi,

Here is a nice little R.E. project I did over the weekend on some old electronics: My Blog
There is so much old stuff just getting tossed into the dump which is a shame as these bits contain a wealth of commercial grade electronics.

-(e)

Oh hey, that is really cool. If a few community members have feedback on uses for this, maybe we could integrate something like this into the stock firmware in a future update?

Chris

Thanks! Maybe this could be built into a namespace with CW2's OneWire stuff? A kind of bitbanger toolkit?

Is there anyway to ship a driver without including it in a matching kernel i.e. have the native and managed portions separate and loadable or is built-in the only possibility?

Also I can trim down the code more, and put it in a better more generic namespace. Do you have a namespace suggestion?

edit: any news on a GIT source share or something similar for the firmware? It would make community generated patches so much nicer and easier

-(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,

In as far as more inputs, would this help?
-(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)

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)

Hi Jeremy, CW2,

I used your patches and all works pretty much as expected. Just to confirm, the target firmware will still be too large and will require the fix mentioned above in the other thread?
I get:

c:\GCC\bin\arm-none-eabi-ld.exe: region `LR_FLASH' overflowed by 576 bytes

Does this match your build? If so, its a pity its such a small difference!

edit: CW2:

For clarity (on my part):

// flash page is 8KB
// ranges are inclusive i.e. 0-5 is 6 pages
const BlockRange g_SAM7X_BS_BlockRange[] =
{
	{ BlockRange::BLOCKTYPE_BOOTSTRAP,     	0,  5 }, // 0x00000 - ( 6*8*1024) 0x0C000, length 0x0C000
	{ MEMORY_BLOCKTYPE_GCC_SPECIAL_BOOTSTRAP,  6, 10 }, // 0x0C000 - (11*8*1024) 0x16000, length 0x0A000, Sum = 0x16000 (.bin size = 0x143B0)
	{ BlockRange::BLOCKTYPE_CODE,         	11, 44 }, // 0x16000 - (45*8*1024) 0x5A000, length 0x44000
	{ MEMORY_BLOCKTYPE_GCC_SPECIAL_CODE,  	45, 53 }, // 0x5A000 - (54*8*1024) 0x6C000, length 0x12000, Sum = 0x56000, Flash size = 0x542C0
	{ BlockRange::BLOCKTYPE_DEPLOYMENT,   	54, 60 }, // 0x6C000 - (61*8*1024) 0x7A000, length 0x0E000 -> 56 KiBi for application code
	{ BlockRange::BLOCKTYPE_STORAGE_A,    	61, 61 }, // 0x7A000 - (62*8*1024) 0x7C000, length 0x02000
	{ BlockRange::BLOCKTYPE_STORAGE_B,    	62, 62 }, // 0x7C000 - (63*8*1024) 0x7E000, length 0x02000
	{ BlockRange::BLOCKTYPE_CONFIG,       	63, 63 }  // 0x7E000 - (64*8*1024) 0x80000, length 0x02000
};

So therefore:

<Set Name="Code_BaseAddress"	Value="0x00116000"/>
<Set Name="Deploy_BaseAddress"  Value="0x0016C000"/>

And once I have this correct I should be able to flash?

also:

However, during my numerous experiments, I have found out that bootloader compiled with RVDS actually works with firmware compiled with GCC 4.4 (!), so it appears to be a better choice, as there is more memory left for the application code, because GCC bootloader is twice as big as RVDS one (~40 KiBi vs. ~80 KiBi). I will probably stick with this for now...

This would be nice any hints on how to accomplish it?
-(e)

Hi sweetlilmre,

Thanks for the post and welcome to the Netduino community!

We're looking at adding variable-bit SPI as a feature in the Netduino firmware. If you want to make the modifications in the source code yourself, you're welcome to do so. You can find the source on the downloads page.

Chris

Hi, and thanks for the welcome, seems like a great community to be part of

I'll take a look at the the SPI stuff, but driver level code is an unknown for me at this point.
The device in question works, but slowly. I will release the code to drive it shortly and then upgrage to SPI when it becomes available.

Out of interest is there a reason why the SPI driver locks the SPI pins? Is this at the framework level i.e. unavoidable?
The reason I ask is that variable SPI could be implemented at the user level in an emulated context if this was not the case.

I know this is the worst kind of question, but do you have any info on:

• A beta of the firmware with the variable SPI feature (I would be keen to assist in testing)
• An estimation on release date

Thanks
-(e)

Hi,

I have a device that uses a SPI-like clock / data mechanism, however the transfer length depends on what form of command you are sending to the device. This makes standard SPI 8/16 bit transfers impossible. For certain commands though the device has a 'bulk' write option that is 8 bits wide.

I have taken adavantage of this on a PIC by bit-banging in the non 8-bit commands and then using SPI to handle the bulk transfers. This really speeds up communication, but unfortunately I can't seem to replicate this behaviour on the NetDuino as once I initialise SPI the SPI pins are not longer available to write to manually i.e.

SPI.Configuration conf = new SPI.Configuration(Pins.GPIO_PIN_D4, false, 0, 0, false, true, 1000, SPI.SPI_module.SPI1);
SPI SPI_port = new SPI(conf);

OutputPort _clkPin = new OutputPort(Pins.GPIO_PIN_D13, true);

causes an exception CLR_E_PIN_UNAVAILABLE.

Is there someway to get around this or perhaps I am looking at this the wrong way?

Thanks in advance
-(e)