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)

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)

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

Very cool.

A few questions:
1. What do (or others) see as the typical use cases for this feature? By including it in the core firmware, we'd like to make sure that we communicate its use and value clearly to users.

2. What limits are you putting on length of data? My only concern would be that the code might send out enough bits that it would tie up the processor and not let other managed code run... In .NET MF, native code should use timers, continuations, or completions for long-running tasks.

3. Are you willing to include this in the core codebase (Apache 2.0 licensed)? Attribution to original authors (internal or external) doesn't appear in any of the source--but we'd like to find a way to give you credit. At minimum we can give you a big public "thank you" in the online release notes... Hmm, have to think about that...

Chris

1. Typical use case is to handle hardware like the HT1632, shift registers etc. Of course you CAN do this in managed, its just slow. Basically any hardware that can be bitbanged can now be used 'speedily' from a NetDuino without custom drivers.

2. There is no limit on the length of data atm. typical usages look to be small arrays (16-32 bytes?) but I am willing to look into friendlier options to allow 'unlimited' data or even cap it at some reasonable value.

3. Sure no problem. Any license is pretty much fine with me. I am no GPL zealot

Something things to think about:

• variable SPI might perform a similar function, although that obviously dictates the usage of the SPI pins. How is this going btw?
• the 1-wire interface CW2 wrote also could use some firmware love It is different enough that it needs its own impl though.

-(e)

Hi all, I've attached the latest code which I got a chance to test last night. It seems to perform well (and work!) Hookedup: if you want to flash this you will need to reflash your bootloader (tinybooterdecompressor.bin is included) and then flash the hex files included. Source is in the archive as well. Chris, now I just need to rename / whatever to make this an appropriate fit for the firmware. Thanks -(e)

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,

Would it be possible to hook the DMA up to external SRAM (obviously not with the current board, but assuming a board with suitably connected SRAM was developed, does the CPU have this capability?

I would like to read and transform a large volume of data very quickly,
something along the lines of this project except that I am looking for an 8-bit colour display and hence a block of SRAM to store the display buffer in (plus other bits)

-(e)

sweetlilmre, the AT91SAM7X512 MCU does not support external RAM directly. You could add external RAM via SPI, but you'd have to read/write data slowly via the SPI interface.

Chris

Hi,

Thanks for the info. I guess for this particular application I'll need to look at something else like a STM32.
Hmm pity I really like the AT91 chips.

-(e)

Hi,

I ported over the Arduino PS2 keyboard driver but unfortunately I cannot seem to read the PS2 data line fast enough during the clock interrupt.
The same pinout etc. was tested and working on an Arduino so it seems to be an interop speed issue.

Has anyone else managed to get this working?

Thanks
-(e)

OK, so I saw someone connect their arduino to a TV- anyone done anything similar with the Netduino?

--
neonsonicboy

No, but I really want to

Check these out:

Projects
ELM - General purpose display controller
Renesas M16C Design Contest 2005
LucidScience - Build the LAZARUS-64 PROTOTYPE - Page 4 of 15

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

I have done this with the MAX7456 IC. It costs <$20 and can put characters on the screen. I wrote a driver you can download here: http://www.fezzer.co...ormance-driver/

I wrote it on Fez Panda but it doesn't use any Fez-specific libraries.

-Andrej

Very cool!

My ultimate aim though is a 320x240 8-bit, double-buffered frame buffer with hardware tile and sprite support.
I am spec-ing it at 32x32 sprites and 16x16 bg tiles with a single alpha bit for transparency.

Probably powered by a second micro or CPLD / FPGA, think: FrameBufferShield with PAL / NTSC and VGA support.
I'd like to be able to handle a max res of 640x480.

The primary micro would communicate via SPI, upload all GFX (tiles and sprites) and use a command language to control the display:

• update tilemap
• move sprite x, y, depth

That would be truly awesome and is going to take me forever to get right
-(e)

edit: double post

Hi, Wow, awesome replies everyone! I am going to look at capturing the state of any input pins at the time of interrupt and exposing this up the chain to the event handler. I've looked at the code and it looks possible, but will require some significant changes.... Hmmm -(e)

I'm currently looking at workarounds to be able to blast a whole array of data to the display in one call but the only solution may be to resort to a native-code implementation (I'm still struggling to get the vanilla firmware to compile so it may take a while).

Perhaps I can extend my BitBang implementation to offer a latch-per-bytes-sent functionality or such.
I'll look into it.

-(e)

Sorry, meant to add: Do the continuous mode stuff. This made a significant difference in the LED matrix performance. -(e)

Hi Ward,

This is exactly what I am after for a number of ideas / projects.
I will take 2 if available.

Do you accept PayPal?
-(e)

edit: only problem is that I might need a XC3S200

Hi,

SUCCESS!!!

12 hours of my life I'll never get back, a switch to the Keil compiler and a low-level firmware modification and I can read a PS2 keyboard.
At least it seems like it - I haven't got to the decoding routine yet.

During this exercise I discovered that GCC built firmware is horribly unreliable in interrupt delivery (at least I think it was a GCC issue).
A keyboard press / release should generate 33 clock pulses for a standard key (scan code, E0 and scan code again to match key down / key up).

Under GCC I was getting a random number of interrupts in the range 11 - 23... Under Keil I consistently get 33.

My firmware modification traps the state of 0 - 31 InputPorts at the time of the interrupt and passes this state via the data2 parameter of the interrupt. This is handled via a modification to InterruptPort and the low level ISR routine:

	public sealed class InterruptPort : InputPort
	{
    	//--//
    	private uint[] m_inputPinWatch = null;

    	public InterruptPort( Cpu.Pin portId, bool glitchFilter, ResistorMode resistor, InterruptMode interrupt, InputPort[] watches )
      	: this( portId, glitchFilter, resistor, interrupt )
    	{
        	if ( watches != null )
        	{
            	if ( watches.Length > 31 )
            	{
              	// max 31 bits of resolution in data2 argument of the interrupt event handler
              	throw new ArgumentException();
            	}
            	m_inputPinWatch = new uint[ watches.Length ];

            	for ( int index = 0; index < watches.Length; index++ )
            	{
                	m_inputPinWatch[ index ] = (uint) watches[index].Id;
            	}
        	}
    	}
]

and

    	CLR_RT_HeapBlock_Array* inputPinWatchRef = pManagedPortObj[ Library_spot_hardware_native_Microsoft_SPOT_Hardware_Port::FIELD__m_inputPinWatch ].DereferenceArray();
    	if ( inputPinWatchRef != NULL )
    	{
        	CLR_UINT32* inputPinIds = (CLR_UINT32*) inputPinWatchRef->GetFirstElement();
        	int len = inputPinWatchRef->m_numOfElements;

        	for ( int i = 0; i < len; i++ )
        	{
            	if ( ::CPU_GPIO_GetPinState( inputPinIds[i] ) )
            	{
                	data2 |= ( 1 << ( i + 1 ) );
            	}
        	}
    	}

This seems to perform well but is an interesting alteration to the core framework and changes the meaning of the data2 / state parameter of the interrupt significantly.

I would be interested in any comments on this approach.

I'd also like to thank CW2 for various posts on getting the firmware compiled without which this wouldn't have happened.

Thanks
-(e)

Hi,

It sounds like you are running into similar issue I had in trying to interface with a PS2 Keyboard.
I might have a test firmware available soon if you want to try it out?

-(e)

Hi CW2,

It's actually the same source we build the published binaries from (with the exception of swapping out the pre-release PWM code for the stub file).

Looking into the best publication options...

Chris

Hi Chris,

I'd also like the PWM code, but not in a manner that would cause delays for any of your projects.
The people testing beta firmware that I have compiled will have to live without the PWM capabilities for now

Ultimately it would be awesome if you would publish the firmware source to GitHub (or host your own Git master repo) that people like CW2 and myself can pull from for our experiments. This would also help to smooth the jump between firmware versions and allow us to push upstream our changes for your consideration.

Then again I realise that this would take some considerable time to set up and you have a million things on the go, I do this for fun, you for a living!

-(e)

Hi, Wow... some really interesting ideas flowing here. I was thinking along the lines of writing a naked C function with some kind of function support table (read/write pin etc.) and then passing that as a byte stream to the firmware to execute. As far as the JIT approach goes, I am weary. Even with a JIT to native there is still the potential overhead of all the calls through the managed layers i.e. in the BitBanger code, everything is marshalled to native pointers and then the pins are toggled to provide the best speed advantage. Manged code even in JIT form would be calling other managed functions (Read / Write for pins) that would then be marshalling and calling native functions. The Fluent approach is very attractive from an easy-to-modify (and extend) point of view. Something that may be worth having a look at are the dynarec compilers used in emulators. These dynamically recompile code from a foreign instruction set into a native one. Looking at this type of code could give some good pointers in how to emit efficient assembly. I know that there exist dynarecs for Z80 <--> ARM and various others and perhaps this could be a starting point. Corey: I'll have a look at the code when I can get some time -(e)

sweetlilmre,

We've registered the netduino.codeplex.com project (using Mercurial) and hope to publish the v4.1.0.6 or v4.1.1 there. I'll make sure we include the PWM code as it comes out of beta sa well.

Would that work well?

Chris

Brilliant
Thanks for all your hard work.

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