[En-Nut-Discussion] SPI Bus

[Allister Mannion]

Dear Harald

Many thanks for the pointers; I think I understand the Net/OS, Net/Net,
and SPI basics now. So to work... (trying for real!)

I think I've read everything (at least once) and I've built everything
on Linux (ubuntu 9.04 - not clean!). I can now build applications
(hhtpserv, logtime, etc.) without problem and have got to the exciting
bit - downloading them to the 1.3 board!

I set my Linux system up with bootp and tftp, went to the basemon
monitor on the board, hit 'j', saw the board download the image I
specified in the dhcp/bootp config, and then after a bit of waiting see
it drop into the default webserver application at the fixed address
(192.168.1.54), rather than the one I saw the dhcp hand it
(192.168.1.50)? That is, it didn't run the application code it
downloaded, nor even adopt the address given during the dhcp/bootp
transactions?

Now I know the board still has the factory default EESAVE fuse
set/enabled, but wasn't sure I needed to reset/disable this in order to
'flash' the new application. i.e. does having the fuse set stop ALL
programming (i.e. I'm doing nothing), or just stop the erase (what I'd
like it to do, so eboot stays resident at the top of flash memory)

I know it's probably a stupid question, but I'm keen to get a
development system working using bootp/tftp rather than mess around with
serial cables (which modern PCs - like my laptop - no longer have).
Suggestions?

Allister Mannion

P.S. I do have a PC with a serial port, it's just not the most
convenient way to do development.
 
ΠΟωaττ - saving more than you think
+41 (0) 79 - 7591554
www.nowatt.com


On Thu, 2009-07-23 at 11:22 +0200, Harald Kipp wrote:

> Allister Mannion wrote:
> 
> > The codec and MP3 examples look a bit hardware device driver specific.
> > I'm sort of imagining a serial type interface, but I guess (and have
> > read) it's a little more complex. Maybe writing a driver like that for
> > the codec would make the application code more generic/readable, but I
> > was hoping I could do the whole SPI interaction as an application (i.e.
> > touch nothing in the *-bld/OS folder). 
> 
> The MMC MP3 Player and the Flash MP3 Player sample
> 
>  http://www.ethernut.de/nutwiki/Flash_MP3_Player
>  http://www.ethernut.de/nutwiki/MMC_MP3_Player
> 
> are quite generic in that sense, that any hardware specific code is done
> in the initialization. Access to the codec is via stdio. This is the
> most advanced solution, but requires a device specific Nut/OS driver.
> 
> You can always directly access the AVR hardware. Actually, before the
> Nut/OS SPI bus driver has been available, this was used by all drivers
> of SPI devices. For example
> 
>  nut/arch/avr/dev/spiflash.c
> 
> Check the function SpiByte().
> 
> The advantages of the SPI bus driver are
> 
> - SPI devices can be attached to any SPI bus, even bit-banged.
> - Several SPI drivers can be attached to the same bus.
> 
> This makes its usage a bit more complicated.
> 
> 
> > I think I'm going to have to study the nutwiki/SPI document more; from
> > what you've forwarded and I've read, it looks like the closest I'm going
> > to get to an example.
> 
>  http://www.ethernut.de/en/documents/ntn-6_spi.html
> 
> is the most important document. The chapter "Using the SPI bus / Low
> level bus access" provides an example, that doesn't require a driver. It
> should work on all platforms, because it is a bit banging driver. To use
> the AVR SPI hardware, simply replace the bus driver, using spiBus0Avr
> instead of spiBus0Gpio.
> 
> Harald
> 
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion