sweetlilmre

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)