autorun

[Luel Georges]

Hi,

 

I buy an Olimex SAM7 256 EX to try Elua.

 

I install Elua on the Olimex SAM7 256 and it works really fine.

 

I download examples program via Xmodem and run it fine also.

 

Can I save the program on Flash or SD Card and have an autorun on my program
?

 

 

                  Thanks for to post this nice piece of code

 

                                         Georges

 

                                               Belgium

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090216/e2909cc1/attachment-0001.html 

[Dado Sutter]

Hello Luel,
   Thank you for trying eLua and for your nice report ! :)
   eLua's current File System is still a Read Only File System, so programs
still cannot write to it.
   But yes, the program you have loaded and tested via XModem, CAN indeed be
included on the File System image and also be run as an "autorun" program.
But for this you need to be able to build eLua.
   I don't know if you have used one of our binary releases or if you are
already building eLua yourself.
   The process of including a file in the ROM File System is very easy and I
can post a simple tutorial here if you or anyone find interesting.
   If you just want to include it once, I can generate an image here for
you, including your file as an autorun Lua Program.
   Please let me know what is more usefull and I'll be glad to help.

Regards
Dado




On Mon, Feb 16, 2009 at 14:41, Luel Georges <georges.luel at skynet.be> wrote:

>  Hi,
>
>
>
> I buy an Olimex SAM7 256 EX to try Elua.
>
>
>
> I install Elua on the Olimex SAM7 256 and it works really fine.
>
>
>
> I download examples program via Xmodem and run it fine also.
>
>
>
> Can I save the program on Flash or SD Card and have an autorun on my
> program ?
>
>
>
>
>
>                   Thanks for to post this nice piece of code
>
>
>
>                                          Georges
>
>
>
>                                                Belgium
>
>
>
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090216/38453c80/attachment.html 

[Jesus Alvarez]

I added FatFs support to my local version of eLua to run scripts from an
MMC/SD card. The changes use the "/mmc" prefix for the card and you can
place an autorun.lua on the card to load a script upon startup. "/rom" can
still be used for the files in flash. I will post these changes to a
separate trunk in the SVN later today or tomorrow.

Regards,
Jesus Alvarez

[jbsnyder]

Nice!

It would be fun to use this to test some data logging with the new ADC module.

How much extra code space does this require?

Best.

-jsnyder

----- "Jesus Alvarez" <jalvarez at micromint.com> wrote:

> I added FatFs support to my local version of eLua to run scripts from
> an
> MMC/SD card. The changes use the "/mmc" prefix for the card and you
> can
> place an autorun.lua on the card to load a script upon startup. "/rom"
> can
> still be used for the files in flash. I will post these changes to a
> separate trunk in the SVN later today or tomorrow.
>
> Regards,
> Jesus Alvarez
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev

[Dado Sutter]

That is great news Alvarez !
   Thank you very much for the contribution to the project.
   I'll be glad to test your code and we might be able to include it in v0.6
eventually.

Tks again
Dado


On Mon, Feb 16, 2009 at 15:14, Jesus Alvarez <jalvarez at micromint.com> wrote:

> I added FatFs support to my local version of eLua to run scripts from an
> MMC/SD card. The changes use the "/mmc" prefix for the card and you can
> place an autorun.lua on the card to load a script upon startup. "/rom" can
> still be used for the files in flash. I will post these changes to a
> separate trunk in the SVN later today or tomorrow.
>
> Regards,
> Jesus Alvarez
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090216/b1f8378f/attachment.html 

[Jesus Alvarez]

> How much extra code space does this require?

On an LM3S target, the eLua binary is approximately 6.8 KB larger. When you
relocate your scripts to the SD card the /rom filesystem becomes much
smaller. That results in a net flash space savings for many applications.

Note that I have only implemented this on the LM3S platform and testing has
been limited.

Porting to the other platforms should only require copying the FatFs mmc.c
file to the platform directory and changing it to match the SSI port I/O
where the MMC/SD card is connected.

Regards,
Jesus Alvarez

[jbsnyder]

On Feb 16, 2009, at 1:11 PM, Jesus Alvarez wrote:

>> How much extra code space does this require?
>
> On an LM3S target, the eLua binary is approximately 6.8 KB larger.  
> When you
> relocate your scripts to the SD card the /rom filesystem becomes much
> smaller. That results in a net flash space savings for many  
> applications.

That sounds similar to what I recall seeing on the FatFS website as  
estimates when FatFS was compiled in, so it sounds like not too much  
extra code was needed to make it work with eLua.

The latter point you make is something that I've been thinking about  
myself, since eLua is creeping towards 256kB, it would be nice to move  
things non-essential for booting over to the card.

> Note that I have only implemented this on the LM3S platform and  
> testing has
> been limited.

Luckily, this is what I've got :-)

Have you tried using the display and the SD card at the same time?  I  
recall on many of the LM3S boards that they share the same SSI port,  
and that some considerations are needed to make sure that both can be  
used at the same time.

I look forward to seeing this module.

-jsnyder

--
James Snyder
Biomedical Engineering
Northwestern University
jbsnyder at fanplastic.org
http://fanplastic.org/key.txt
ph: [phone]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090216/afeacc2e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090216/afeacc2e/attachment.pgp 

[Jesus Alvarez]

> Have you tried using the display and the SD card at the same time? I
recall on many
> of the LM3S boards that they share the same SSI port, and that some
considerations
> are needed to make sure that both can be used at the same time.

No. My testing is on the Micromint Eagle 100 which is based on the LM3S6918.
The Eagle 100 is more oriented towards industrial applications so it has
PC/104, character LCD and keypad interfaces instead of the RIT display
interface used in the Luminary evaluation kits.

But I have used multiple devices per SSI channel with LM3S processors. With
the LM3S as the SSI master and using the microcontroller SSI registers (e.g.
not implementing SSI by bit-banging), you should be able to use several
devices in each SSI channel with no problems.
 
The problem you are referring to may be a software issue. I have seen
applications that switch the SSI chip select to a new device without
checking if the SSI channel is done receiving or transmitting to the current
device. That is not a good practice and would cause problems in many SSI
implementations. If the SSI chip select does not have the proper
arbitration, you will not get reliable I/O to multiple SSI devices.

I'm working on a project at the moment but will upload the MMC/SD changes
tonight so you can test them on your board.
 
Regards,
Jesus Alvarez

[jbsnyder]

On Feb 16, 2009, at 2:56 PM, Jesus Alvarez wrote:

> The problem you are referring to may be a software issue. I have seen
> applications that switch the SSI chip select to a new device without
> checking if the SSI channel is done receiving or transmitting to the  
> current
> device. That is not a good practice and would cause problems in many  
> SSI
> implementations. If the SSI chip select does not have the proper
> arbitration, you will not get reliable I/O to multiple SSI devices.

Right, I'm pretty that it is just a software issue.  I'll check and  
see if the existing display module plays nicely with the FatFS code.

I'm looking forward to seeing how well this will work for data logging.

> I'm working on a project at the moment but will upload the MMC/SD  
> changes
> tonight so you can test them on your board.

Thanks!

--
James Snyder
Biomedical Engineering
Northwestern University
jbsnyder at fanplastic.org
http://fanplastic.org/key.txt
ph: [phone]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090216/39cde1d7/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090216/39cde1d7/attachment-0001.pgp 

[Jesus Alvarez]

The changes to support MMC/SD cards and the Micromint Eagle 100 board are
now on 'branches/eagle_mmc/' at the SVN. That branch was originally based on
rev 195. It is suggested that you check it out to a separate directory so it
does not interfere your current development trunk.

$ svn checkout svn://svn.berlios.de/elua/branches/eagle_mmc

Regards,
Jesus Alvarez

[Dado Sutter]

Thank you !!!!!!!!!!!!!!!!
   I regret I left my LM kit at the lab :(   :)
   I'll have to wait until tomorrow to test it.

   Is there any limit on the SD Card size or speed ?

Best
Dado


On Mon, Feb 16, 2009 at 21:46, Jesus Alvarez <jalvarez at micromint.com> wrote:

> The changes to support MMC/SD cards and the Micromint Eagle 100 board are
> now on 'branches/eagle_mmc/' at the SVN. That branch was originally based
> on
> rev 195. It is suggested that you check it out to a separate directory so
> it
> does not interfere your current development trunk.
>
> $ svn checkout svn://svn.berlios.de/elua/branches/eagle_mmc
>
> Regards,
> Jesus Alvarez
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090216/dc956974/attachment.html 

[jbsnyder]

Seems to work for me on my LM3S6965 at least for running lua scripts  
from /mmc. I haven't checked the display module or anything with  
writing to it yet, but I'll try that soon.

I also updated the branch with the few commits from trunk that came in  
after Jesus' initial branch.

-jsnyder

On Feb 16, 2009, at 6:50 PM, Dado Sutter wrote:

> Thank you !!!!!!!!!!!!!!!!
>    I regret I left my LM kit at the lab :(   :)
>    I'll have to wait until tomorrow to test it.
>
>    Is there any limit on the SD Card size or speed ?
>
> Best
> Dado
>
>
> On Mon, Feb 16, 2009 at 21:46, Jesus Alvarez  
> <jalvarez at micromint.com> wrote:
> The changes to support MMC/SD cards and the Micromint Eagle 100  
> board are
> now on 'branches/eagle_mmc/' at the SVN. That branch was originally  
> based on
> rev 195. It is suggested that you check it out to a separate  
> directory so it
> does not interfere your current development trunk.
>
> $ svn checkout svn://svn.berlios.de/elua/branches/eagle_mmc
>
> Regards,
> Jesus Alvarez
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev

--
James Snyder
Biomedical Engineering
Northwestern University
jbsnyder at fanplastic.org
http://fanplastic.org/key.txt
ph: [phone]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090216/caca42f2/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090216/caca42f2/attachment.pgp 

[Jesus Alvarez]

> Is there any limit on the SD Card size or speed ?

The changes are based on the FatFs code which supports FAT32 and (in theory;
I have not tested it with large cards) should allow >4 GB SD cards. Its
f_lseek() allows a DWORD offset so individual files are limited to 32-bit
offsets (4 GB) on the ARM.

FatFs uses 8.3 file names. Long file names are not supported and converted
to 8.3 names similar to MS DOS.

I would suggest looking at the FatFs page for fairly good documentation on
the implementation:

http://elm-chan.org/fsw/ff/00index_e.html

There are some speed benchmarks on the resources area of the FatFs web page.
Besides the FatFs options, the card itself and the SPI clock can
significantly affect I/O performance. For example, SD cards generally
perform better than MMC cards. Compact flash cards are generally faster than
SD cards.

Please keep in mind that the MMC/SD changes to eLua have very limited
testing. Modifications will likely be required before production use.

Regards,
Jesus Alvarez

[BogdanM]

> On an LM3S target, the eLua binary is approximately 6.8 KB larger. When you
> relocate your scripts to the SD card the /rom filesystem becomes much
> smaller. That results in a net flash space savings for many applications.
>
> Note that I have only implemented this on the LM3S platform and testing has
> been limited.
>
> Porting to the other platforms should only require copying the FatFs mmc.c
> file to the platform directory and changing it to match the SSI port I/O
> where the MMC/SD card is connected.

We'll have to make it use the platform SPI interface. In this way, simply
providing the platform SPI interface for a new platform would make the whole
FS code available to that platform. I didn't look at the code yet to see if
something else is involved in the process of making this implementation
fully portable.

Best,
Bogdan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090217/dcd62d96/attachment.html 

[BogdanM]

Of course, another idea would be to use SDIO support on platforms that
support it instead of SPI (although I'm not sure there are SDIO interfaces
on any of the currently supported eLua CPUs). If the interfaces are good
enough, using SPI or SDIO for the SD/MMC interfacing would be a simple
matter of defining a macro at compile time.
The next version of eLua (not 0.6 that should be ready by the end on this
month, but 0.7) will definitely have much better support for filesystems.
I'm working on it.

Best,
Bogdan

On Tue, Feb 17, 2009 at 2:16 PM, Bogdan Marinescu <
bogdan.marinescu at gmail.com> wrote:

>
> On an LM3S target, the eLua binary is approximately 6.8 KB larger. When you
>>  relocate your scripts to the SD card the /rom filesystem becomes much
>> smaller. That results in a net flash space savings for many applications.
>>
>> Note that I have only implemented this on the LM3S platform and testing
>> has
>> been limited.
>>
>> Porting to the other platforms should only require copying the FatFs mmc.c
>> file to the platform directory and changing it to match the SSI port I/O
>> where the MMC/SD card is connected.
>
>
> We'll have to make it use the platform SPI interface. In this way, simply
> providing the platform SPI interface for a new platform would make the whole
> FS code available to that platform. I didn't look at the code yet to see if
> something else is involved in the process of making this implementation
> fully portable.
>
> Best,
> Bogdan
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090217/96047925/attachment.html 

[dariopra]

Hello

I'm approaching the planning board Eagle-100.
I need to implement in C + + programming using the Micromint Eagle-100 LM3S6918 microcontroller, so you can do the following:
-drive timers to count
-data conversion with the DAC
-transmission via Ethernet.

I do not know if this is the appropriate place for discussion, but if anyone can give me any suggestions, I would be grateful.
thanks