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)

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)

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,

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,

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)

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,

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)

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

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.

Does anybody from those who downloaded the firmware and possibly tried it have any feedback? How should I interpret the silence, with regard to initial eager requests? Please let me know whether it works or not with your device, so I can fix possible problems and publish the code. Thanks in advance.

Hi,

I have been meaning to look at this but I only just found a 1-wire supplier. I should be able to get hold of some sensors next week and I'll give it a go.

Looks like fun!
-(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 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)

Thanks.
I got those jumper wires from China through ebay. I don't remember which seller exactly, but this cable looks like the one I have.
http://cgi.ebay.com/...=item1c1555b5ef

Lower quality compared to the one from Sparkfun, but also a lot cheaper!
I really like having different colored wires. Makes the circuit easier to "read".

Thanks, ordered some Now to find the foam board...
-(e)

Hi, What a great idea! I wonder if I can get this stuff in South Africa... hmmmm Also, could you tell me where you got those nice jumper wires from? I have some generic ones and they are OK, but yours look much nicer. Thanks -(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)

Hi,

In as far as more inputs, would this help?
-(e)

I have drivers for the FEZ to run all the sharp distance sensors accurate to within a few mm, if anyone's interested i can port them over to Netduino, however i don't have one to test on (yet).

Yes please I just got one today that I would like to start playing with soon. Or just post the code and I'll convert it?
-(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)

edit: double post

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)

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)

Hi,
I have finally published the library on CodePlex. You can grab it here http://microliquidcr...l.codeplex.com/
Basically the same code as previously published on my blog, just with few renames.

Please let me know if you have any suggestions on what can be improved.

Hi,

Thanks for the brilliant library
I just soldered up a pc1602f display in direct GPIO mode and it all works nicely.

As a tip for anyone else doing this, if you don't have a pot of the correct value, you can just tie Vo to ground for maximum contrast (this had me stumped for a bit, I thought the display was broken )

On Monday hopefully I will have my shift registers and I can try it with that.
-(e)