[En-Nut-Discussion] Memory card issues in EIR

[Antti Olavi Ahola]

Thanks for quick and informative reply; now I know to leave the memory  
card be until things are sorted out. Luckily it is not critical to  
what I am doing.

-Antti

Quoting Harald Kipp <harald.kipp at egnite.de>:

> Hi Antti,
>
> Antti Olavi Ahola wrote:
>> I tried to write onto sd card using the sample code on ethernut
>> webpages but execution halts at:
>> if (NutRegisterDevice(&devNplMmc0, 0, 0))
>
> NPL stands for Nut Programmable Logic and is used on boards with
> customizable CPLD/FPGA chips only, like Ethernut 3.
>
> The situation for PHAT on the EIR is a bit weird right now. The SAM7SE
> provides one SPI only, which is used for the VS1053 codec and the
> DataFlash. In order to allow MP3/Ogg streaming from the MMC to the MP3
> decoder, this SPI has been intentionally not connected to the MMC.
>
> The original idea was to use SPI over SSC for the card socket. However,
> this seems to be a bit tricky. It worked basically. Until all problems
> are solved on the SSC interface, bit banging is the only choice. This
> requires some settings in the Configurator. I just tested that and it
> didn't work here. I have to come back to you.
>
>
>> One more thing; the eir example application have hackish initiation
>> function (see below) which I thought might be the cause but when I
>> disabled it(and basically all other unrelated code), the application
>> froze even earlier before any memory card related code.
>
> This is for SPI initialization, used with audio decoding and DataFlash
> access. Actually the main problem is, that Nut/OS doesn't provide a
> general bus driver concept right now and hacks are often required to
> make SPI, I2C, USB etc. working.
>
>
>> Ps. Stupid question but I don't want to break the house of cards that
>> is my environment: is it safe to update nut/os just by copying new
>> sources over old ones and rerunning the nutconfigure?
>
> Not sure if I understood this correctly. It is generally save to install
> a new Nut/OS version over an existing one and use the Configurator to
> update the libraries. Though, I'd recommend to use a new folder for each
> version. So you are able to switch between them. On Windows this is
> simply c:\ethernut-4.6.3 or c:\ethernut-4.6.4. On Linux you should
> create ~/ethernut/ and unpack the archives in this directory. So you get
> ~/ethernut/ethernut-4.6.3/ or ~/ethernut/ethernut-4.6.4/. Use the
> symbolic link nut to link to the current version, which will be
> accessible via ~/ethernut/nut/. Call the Configurator after changing to
> ~/ethernut/. You build directory will be ~/ethernut/nutbld/ and your
> application tree ~/ethernut/nutapp/.
>
> When changing versions, it is not only required to re-build Nut/OS, it
> is also advisable to re-create the sample directory. If you changed any
> application sample, the Configurator will not touch them.
>
> On Windows you need to create a new sample directory and copy your
> changes from the previous version's directory.
>
> There are other ways to deal with updates, but from our experience this
> works best. We are switching between versions quite often.
>
> If you want to modify Nut/OS library modules, you shouldn't do this in
> the source tree. Better copy the original Nut/OS file to your
> application directory and add it to the application's Makefile. This way
> your local version will replace the Nut/OS library module.
>
> Harald
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>