That's really strange, because I've checked a deep difference in performance.
Writing a single frame byte-by-byte is hugely slow than writing a buffer all at once.
The actual byte-rate is around 2-3 KBytes/s: very slow.

Moreover, by adding a little help to the circuit, you may reach very high byte-rates, close to the theoretical SPI speed (around 200 KBytes/s).
Check my fresh post about the SPI perf.

Cheers

PS: after writing that post, I have done some other test and it seems that the speed could be improved enough.

Hi,

I read your post (great article btw!) and I agree... what I am seeing is waay to slow. Thanks for the upper metric of 200 KBps, that gives me something to work with.
I will try some more options and see if I can improve performance.

This is really frustrating... a GameDuino programmed with a C# backend would just be awesome.

I have some other avenues to explore with eLua that I am going to have a look at and see if there is any relative performance difference as well.
-(e)

@sweetlilmre:
I don't think there's need to implement the chip-select manually. The SPI manages an output automatically without any problem and the result is much faster than the manual solution.

Try yourself and maybe your ball game will run at a satisfying speed.
Cheers

Hi

In my code there are only 2 SPI writes per frame so the independent chip select doesn't make any difference.
I rewrote the code as a test to flush the entire 32KB of data per frame with SPI handling the select.
This also made no difference.

I'll try some more options, but it seems the NetDuino running C# is just not fast enough to handle this
-(e)

Hi,

Firstly to kerry_h:

You need to independently handle chip select with an OutputPort on Pin9 and make sure that your SPI config does not specify ChipSelect (see my setup code below).
Your code example should look something like:

ChipSelect = new OutputPort( Pins.GPIO_PIN_D9, true );

byte[] addressBuffer = new byte[2];
byte[] oneByteReadBuffer = new byte[1];
byte[] oneByteWriteBuffer = new byte[1];
oneByteWriteBuffer[0] = 0;

ChipSelect.Write( false );
addressBuffer[0] = 0x28;
addressBuffer[1] = 0x00;
mySPI.Write(addressBuffer);
mySPI.WriteRead(oneByteWriteBuffer, oneByteReadBuffer);
ChipSelect.Write( true );

Secondly to Mario Vernari:

The SPI setup for the GameDuino is specified as SPI Mode Zero i.e. CPOL = 0 and CPHA = 0
edit:

  SPI.setClockDivider(SPI_CLOCK_DIV2);
  SPI.setBitOrder(MSBFIRST);
  SPI.setDataMode(SPI_MODE0);

Thirdly:

I've ported the GD library to the NetDuino and got the Ball demo working.
This was a direct C++ -> C# port and very messy but it works.

However performance is abysmal, which is not surprising considering that the Ball demo makes 45 * 2 SPI writes for the sprites and 256 SPI writes for the palette shift.
This in turn results in 346 interop calls...

To increase performance I built an SPIBuffer class that buffers the 90 sprite writes and 256 palette writes and only makes 2 SPI calls per frame.
Performance increased significantly but still results in only about 5 FPS (pure guess work).

The SPI interface is supposed to run at 8Mhz stable for the GameDuino (1/2 Arduino clock).
The RAM size of the GameDuino is 32KB.
Calculating the transfer rate: 8Mhz = 8 000Khz = 8 000 000Hz = 8 000 000 bits per second = 1 000 000 bytes per second = 975KB/s

At the above rate I should be able to write the entire RAM at about 30 times a second.
I do not achieve anything remotely near this even with a significantly smaller write size.

Even taking .NET runtime and interop overhead into account this seems really strange.
Is there an issue with SPI transfer rate that I am not aware of?


My setup code is:

  	bool chipSelect_ActiveState = false;
  	bool clock_IdleState = false;
  	bool clock_Edge = true;
  	uint clockKHz = 8000;

  	SPI.Configuration config = new SPI.Configuration( Pins.GPIO_NONE, chipSelect_ActiveState, 0, 0, clock_IdleState, clock_Edge, clockKHz,
                       									SPI.SPI_module.SPI1 );

I use a separate OutputPort on PIN9 for chip select.

If I can get this working I will publish the library.
-(e)

Hi, Its awesome you got this going I might have to get one now that you've done all the hard work -(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

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)

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)

As for debugging native code, first line of debugging is using serial ports to write out trace info. If you need "interactive" debugging (i.e. up to 1 breakpoint, visually stepping through memory) debugging, you can get a copy of debugger software and an AT91SAM7X512-EK board.

Hi Chris,

I can only seem to find 256K version of this eval board. Do you have a link to where I could get the 512K version?
Thanks
-(e)

Hi,

I've been looking into porting eLua to the Netduino.
Currently eLua supports the Netduino chip (at91sam7x512) but not the board i.e. I can build and flash the firmware but the device does not seem to boot.
Diagnosing this without JTAG is going to be ... very interesting.

I was wondering if anyone here with low level board support skills would be willing to have a look into the port and report back any findings / insight?

Lua is a wonderfully easy language to teach to kids and I'd like to expand the reach and capabilities of the Netduino through this.
(after a sucessful Lua port, I'd probably look into PyMite next).

I look forward to your responses.
-(e)

EDIT:

Turns out that eLua DOES boot. I just had the incorrect serial port connected (UART2 i.e. pins D2&D3 are required, not D0 and D1).
This means that the default compile works for the Netduino, exciting stuff! I will post progress in this thread.

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)

I have updated the first post with a much more rounded driver and related firmware. To test the efficiency of this new firmware I have put the Matrix code through its paces and it performs well. Hopefully soon I will try this out on some LCD displays to test the latching effect. Also I have found some interesting bugs in the matrix code and will be updating it as soon as possible. Thanks -(e)

Hi Ramon, I just remembered that I had made this change already. Here is a totally untested code drop of the matrix code built against the BitBang class. You are totally on your own with this: I am releasing purely for you to look at and am not going to support it in any way I will update the matrix thread when I release it properly. -(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)

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

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,

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,

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

Sorry, meant to add: Do the continuous mode stuff. This made a significant difference in the LED matrix performance. -(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)

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)

edit: double post

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)

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)