Default device in device manager
Locked
|
I would like to propose adding the following two simple functions for the device manager in devman.c:
// Set the default device index. int dm_set_default_dev( int idx ); // Get the default device index. int dm_get_default_dev( void ); These will allow a device to then choose to make it the default device by registering its index with the device manager as shown below: // Register the efc filesystem idx = dm_register( efcfs_init() ); // Set as default device. if ( idx >= 0 ) dm_set_default_dev( idx ); Then in the function find_dm_entry() the default device will be used for any file name that doesn't have a leading "/". The total changes for this are about 20 lines of code in both devman.c and stubs.c. The reason I would like this is that on my AT91SAM7S dev board I have three separate file systems -- /rom, /mmc (Fat16 on an sd/mmc card) and /efc (embedded flash controller). By setting a default device I can make all file opens that don't prefix a device to automatically utilize the /efc device for file access. I've implemented zmodem upload of code and not having to specify the device to write to in the zmodem code will make it a little more generic. This also saves from having to type in the device path when you want to launch a lua program from the default device. Being new to the eLua I'm not certain how little things like this get proposed and into the eLua code. I can certainly add it to the SVN if others agree. Thanks, Mike Thompson |
 
|
Dado Sutter |
Re: Default device in device manager
|
|
Hello,
On Wed, Apr 8, 2009 at 14:33, mpthompson <[hidden email]> wrote:
Thanks for the ideas and for the code effort Mike ! I'm not sure if I got the big-picture. What you are proposing is a sort of a "cd" command ? Or a different abstraction, like the "default" device as you've proposed ? We still don't have an internal flash file system and it will be great to discuss some implementations. What we need is a generic layer, so we can port it easially to different flash (internal) peripherals. As Bogdan mentioned, zmodem can be a nice adition too (every new feature is ! :) but it does not fit very well in most of our ram-tight kits. We'll be glad to hear your reports on zmodem usage. Being new to the eLua I'm not certain how little things like this get proposed and into the eLua code. Exactly the way you did :) Sharing your thoughts with us, here on the list :) And I don't think these are "little" things. These are nice contributions for eLua ! I can certainly add it to the SVN if others agree. You have developper access to our SVN repo now. But let's discuss a bit more here, before we go for another branch. Pls do not add new code to the current trunk, before we release v0.6. Thanks, Thank you very much. Dado
_______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
mpthompson |
Re: Default device in device manager
|
|
Dado Sutter wrote:
> Thanks for the ideas and for the code effort Mike ! > I'm not sure if I got the big-picture. What you are proposing is a sort > of a "cd" command ? Or a different abstraction, like the "default" > device as you've proposed ? Well, the reason I proposed this is that whenever I went to go run a lua program at the command prompt I had to type something like the following: eLua# lua /efc/hello.lua Press CTRL+Z to exit Lua Hello, World! eLua# With this change, in the C code I make '/efc' the default device when it is initialized and can now do the following: eLua# lua hello.lua Press CTRL+Z to exit Lua Hello, World! eLua# Since the 'hello.lua' program has no preceeding '/' character and a default device index has been registered the device manager simply assumes the file name should be opened on the default device. Likewise, I implemented zmodem upload which handles bulk transfer of multiple files kicked off using an 'rz' command at the prompt. Since, the zmodem handles the naming of files as they are transferred, I still needed to tell it which volume the files should be directed at such as: eLua# rz /efc With the default volume, the files were automatically directed to the desired volume with: eLua# rz [...three files get transferred and automatically named...] eLua# ls bisect.lua 646 hangman.lua 3750 hello.lua 23 eLua# lua hello.lua Press CTRL+Z to exit Lua Hello, World! eLua# (ignore the 'ls' command, you didn't see that :-) This isn't really a 'cd' command as the semantics of a current working directory aren't being introduced. Really, it's just a way to direct the opening of a filename without a prefixing the device name ('/efc' in my examples) to the filename. Hopefully this makes the nature of my proposed change a little more understandable. Mike _______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Personally, I like the current version more because it's more explicit (and more clear) and I don't think it's such a hassle to type 3-4 more chars (I'm a very lazy person, but this seems too much even for me :) ). It can bring confusion when more than one platform (or even two similar platforms but with different firmware versions) are involved, so let's leave it as is for now.
Can you make rz behave just like the current "recv" (as in "receive file to memory instead of disk"?) My guess would be "yes", but I don't know how easy/hard it is to change the code. This is related to another thread in this list, so let's continue the discussion there. Thanks, Bogdan On Thu, Apr 9, 2009 at 2:52 AM, Mike Thompson <[hidden email]> wrote:
_______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Dado Sutter |
Re: Default device in device manager
|
|
In reply to this post by mpthompson
Thanks for the explanations Mike.
Although I see that it helps somewhat for a few commands typing, I don't think the introduction of a new and different concept (the "default" device) will help more than confuse though :( I think that it is actually good to type explicitly the full path to what we're doing, including the device name (actually part of the path already), unless we come up with an implementation of a true "cd" command. This is just my feeling, let's see if we have some more opinions. ZModem lighter than XModem ? :-o Really ? It will be great to have it then ! :) And talking about XModem, does anybody know why it "times out" after a few seconds (7~9) if we don't send the file ? It did not happened before, in it's firsts implementations and I lost track on exactly when the problem showed up. It seems to be in it's final days anyway :) Regards Dado On Wed, Apr 8, 2009 at 20:52, Mike Thompson <[hidden email]> wrote:
_______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
mpthompson |
Re: Default device in device manager
|
|
Dado Sutter wrote:
> ZModem lighter than XModem ? :-o Really ? It will be great to have it > then ! :) Well, the code compiles to a little over 2x that of xmodem, but the SRAM footprint doesn't involve any buffers except for the 32 character filename buffer and about a dozen single byte state variables. These can all be put into an allocated structure to even eliminate that fixed overhead from the data segment. The eLua implementation of zmodem can be examined in the zip file linked below: http://home.comcast.net/~michael.p.thompson/elua/elua_zmodem.zip I'm using this with SecureCRT as my terminal program and it works great. I just type rz at the eLua shell prompt and my terminal program prompts for the file(s) to be transferred. For my application, the benefits of zmodem outweigh the slightly larger code size over the xmodem application. In this specific code I'm writing the files to a file system, but changing the code to work like eLua's xmodem with a malloc'd buffer should be a simple matter. Using xmodem or zmodem could be a simple compile type BUILD_XMODEM or BUILD_ZMODEM switch. Note, like xmodem, this is receive only. The sending part does involve a 1K buffer, but I stripped that out along with the rest of the sending code as sending is not a requirement of mine. The original implementation came from the AVR Freaks site: http://www.avrfreaks.net/index.php?module=FreaksAcademy&func=viewItem&item_id=134&item_type=project Enjoy... Mike Thompson _______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |