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)

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)

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)

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.

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)

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

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)

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

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

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)