New to eLua and STM32F4xx
Locked
|
I have been following eLua for a while with the aim of deploying it on a custom STM32F4xx project. I have successfully built the STM32F407_Discovery image with the now obsolete "scons" based builder, but have not yet been successful with the new "lake" builder. I am not too worried about that at the moment as I have not spent much time on it. But I do have some basic questions to get a feel for where eLua is going:
1. Lua 5.1 is specified for eLua. Using Lua 5.2 may be the cause of my present problems. Is Lua 5.2 supported and if not is it intended to do so soon? Moving to a total Lua build system makes sense, but staying at Lua 5.1 does not! 2. The STM32F4xx branch has been around for a while (although not on main git until very recently) and has not been merged with Master yet. Can anyone comment on its status? 3. My working platform is a Mac. Are there any known issues in building eLua on a Mac? So far I have not discovered any. 4. Present issue is with require"lfs" not accepting lfs.so. Paths are ok. Suspecting Lua versions. Comments anyone? Obviously much good work has gone into eLua by Bogdan and others for which I am grateful and hope to return some value in the coming months. Graham _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Mon, Jun 3, 2013 at 4:49 AM, Graham Henstridge <[hidden email]> wrote: I have been following eLua for a while with the aim of deploying it on a custom STM32F4xx project. I have successfully built the STM32F407_Discovery image with the now obsolete "scons" based builder, but have not yet been successful with the new "lake" builder. I am not too worried about that at the moment as I have not spent much time on it. But I do have some basic questions to get a feel for where eLua is going: Lua 5.1 is far from being obsolete and a lot of projects centered around Lua still use Lua 5.1. There are plans to move eLua to 5.2 at some point, but nothing very clear at the moment.
Check the new 'stm32f4' branch on github, this is where the STM32F4 development is currently happening. After some testing, it will be merged to master.
None that I know of, but personally I never tried to build eLua on a Mac.
This is quite strange. How are you installing lfs on your machine? What is the value of your LUA_PATH environment variable? Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
 
|
Björn Kalkbrenner |
Re: New to eLua and STM32F4xx
|
|
Hi,
On 03.06.2013 09:03, Bogdan Marinescu wrote: > > Lua 5.1 is far from being obsolete and a lot of projects centered around > Lua still use Lua 5.1. There are plans to move eLua to 5.2 at some > point, but nothing very clear at the moment. Graham, I just want to add the fact that a jump from Lua 5.1 to Lua 5.2 on the "PC"-Client side may not be working out of the box (depends on libraries and code which is used). Two things are problematic: - The module system has changed. I am not sure if module() is deprecated but that is not the only thing - setfenv/getfenv are missing due to the fact that the environments have changed for _ENV. There are some more changes, as stated at http://lua-users.org/wiki/LuaFiveTwo "Lua 5.2 was allowed to make design changes that break full compatibility." I think it will take some time and some "lua-5.2-compat" modules for a working jump to 5.2. I had to deal with the same problem on Lua 5.0 => Lua 5.1. Some libraries are still lua-5.0 code with a "hacked" lua-5.1 compat module. Bye Björn _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Graham Henstridge-2 |
Re: New to eLua and STM32F4xx
|
|
In reply to this post by BogdanM
On 03/06/2013, at 5:03 PM, Bogdan Marinescu <[hidden email]> wrote:
Thank you for response. Have reinstalled Lua 5.1.5 and problem continues. Have confirmed neither eLua or lfs at fault. This is now more a Lua list issue, but from Lua prompt I can >dofile"/usr/local/lib/lua/5.1/test.lua" and it works, but if I do: >require"test" I get ..... stdin:1: module 'test' not found: no field package.preload['test'] no file 'test.lua' ' no file '/usr/local/lib/lua/5.1/test.lua should have been found here no file 'test.so' ' no file '/usr/local/lib/lua/5.1/test.so stack traceback: [C]: in function 'require' stdin:1: in main chunk [C]: ? >print(package.path) ?.lua;/usr/local/lib/lua/5.1/?.lua and this seems ok However I have not used Lua for a few years so it is almost certainly me! Graham _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Graham Henstridge-2 |
Re: New to eLua and STM32F4xx
|
|
In reply to this post by Björn Kalkbrenner
Hi On 03/06/2013, at 6:36 PM, Björn Kalkbrenner <[hidden email]> wrote: > Hi, > > On 03.06.2013 09:03, Bogdan Marinescu wrote: > >> >> Lua 5.1 is far from being obsolete and a lot of projects centered around >> Lua still use Lua 5.1. There are plans to move eLua to 5.2 at some >> point, but nothing very clear at the moment. > > Graham, I just want to add the fact that a jump from Lua 5.1 to Lua 5.2 > on the "PC"-Client side may not be working out of the box (depends on > libraries and code which is used). Two things are problematic: > > - The module system has changed. I am not sure if module() is deprecated > but that is not the only thing > > - setfenv/getfenv are missing due to the fact that the environments have > changed for _ENV. > > There are some more changes, as stated at > http://lua-users.org/wiki/LuaFiveTwo > > "Lua 5.2 was allowed to make design changes that break full compatibility." > > I think it will take some time and some "lua-5.2-compat" modules for a > working jump to 5.2. I had to deal with the same problem on Lua 5.0 => > Lua 5.1. Some libraries are still lua-5.0 code with a "hacked" lua-5.1 > compat module. > > > Bye > Björn Thanks Björn, I probably underestimated the issues involved. I did update my pre-existing code to 5.2 when it first came out and that was a quick and trivial exercise - but that was because I had used very few of the features that changed - from memory, only the depreciation of module() needed to be worked around. Graham _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by BogdanM
On Mon, Jun 3, 2013 at 2:03 AM, Bogdan Marinescu <[hidden email]> wrote:
On this front if you're using the discovery board you might need to use the bikeNomad-master branch or have one of us commit a fix to put the UART back on PB6/7 for that board (https://github.com/jsnyder/elua/tree/bikeNomad-master). I'll try and put this fix in the 'stm32f4' branch and test it (on the board, PA9 is connected to VBUS for USB and an LED, not sure if it it can be used as a UART.
Another thing might be if you switch to the stm32f4 branch it will try to build with hardware floating point, depending on your toolchain you might run into linking errors about VFP, depending on the toolchain you're using and if it includes the right libraries or multilibs. If you're using my Makefile (arm-eabi-toolchain), I have a version that seems to be working in a branch, but I haven't pushed it to master yet.
It should be fine on Mac OS X. That's what I use for development.
You'll want to use 5.1 on your machine for building I think (as Bjorn was discussing what might happen with 5.2). I don't know that any of us have tested the build system with 5.2.
I believe on my system I've got lua and luarocks installed out of Homebrew (which defaults to 5.1.x, https://github.com/mxcl/homebrew/) and then used luarocks to install the needed modules like lfs. You can certainly install your own versions of lua/luarocks or use another method if you like.
James Snyder Biomedical Engineering Northwestern University http://fanplastic.org/key.txt ph: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Mon, Jun 3, 2013 at 8:28 PM, James Snyder <[hidden email]> wrote:
It's almost certainly unusable as an UART. One thing we can do before eLua gets the proper uart_set_pins() function is to use the configurator and add a platform-specific configuration. Something like this: -- Add specific configuration to the 'configs' table function add_platform_configs( t, board, cpu ) t.stm32f4_uart_pins = { attrs = { con_rx_port = at.int_attr( 'STM32F4_CON_RX_PORT', 0 ), con_rx_pin = at.int_attr( 'STM32F4_CON_RX_PIN', 0 ), con_tx_port = at.int_attr( 'STM32F4_CON_TX_PORT', 0 ), con_tx_pin = at.int_attr( 'STM32F4_CON_TX_PIN', 0 ) }, required = { con_rx_port = 1, con_rx_pin = 7, con_tx_port = 1, con_tx_pin = 6 } -- this is the default configuration } end Then each board description file will be able to supply its own pin configuration for the console UART. Of course, this still needs support in platform.c, but that should be fairly easy. Let me know if you're OK with this solution.
It works very well, the multilib configuration is complete and it has a Mac version. Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Mon, Jun 3, 2013 at 1:22 PM, Bogdan Marinescu <[hidden email]> wrote:
That sounds good for now.
Yep. That one looks like a nice option. There's a blog article on ARM's site about it here by one of the maintainers describing some of what they've done:
I'm especially curious about what exactly they did in newlib-nano which is broken out here:
James Snyder Biomedical Engineering Northwestern University http://fanplastic.org/key.txt ph: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Mon, Jun 3, 2013 at 9:43 PM, James Snyder <[hidden email]> wrote:
Done, check the latest commit on stm32f4. The configuration for stm32f4discovery needs to be updated accordingly, please update it if you can (and test it, of course). Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Graham Henstridge-2 |
Re: New to eLua and STM32F4xx
|
|
On Mon, Jun 3, 2013 at 1:22 PM, Bogdan Marinescu <[hidden email]> wrote: > I recommend this: > > https://launchpad.net/gcc-arm-embedded/+milestone/4.7-2012-q4-major > > It works very well, the multilib configuration is complete and it has a Mac version. Thank you Bogdan - I'll install the toolchain to gain the vital VFP support. (I am presently using yagarto-4.7.2.) and try your latest stm32f4 commit on a discovery board. And thank you James - I had started with your bikeNomad-master branch. I have being using MacPorts to import libraries, but will now try homebrew, especially as it is recommended for above toolchain, and start over. Cheers Graham _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
FWIW: I did do a quick test of what Bogdan put in, the defaults you set for the ports gave me a booting version with the gcc-arm-embedded toolchain without further modifications. I might do some further mods for the other peripherals using the template of what you implemented. The console did come up on PB6/7. I'm not sure about Yagarto, I don't see what targets it supports out of the box. Regarding my own arm-eabi-toolchain, I tried things with the latest version and extended multilibs and something is not right there (hard faulting, something related to memory allocation), so Bogdan's recommendation seems like a good option for now :-)
Aside: Interestingly, gcc-arm-embedded still generates somewhat larger code (~10%). Will have to figure out what's going on with why the latest Mentor/CodeSourcery sources are having trouble and whether that, when fixed still has size benefits. I wish I had more spare time :-) On Mon, Jun 3, 2013 at 7:43 PM, Graham Henstridge <[hidden email]> wrote:
James Snyder Biomedical Engineering Northwestern University http://fanplastic.org/key.txt ph: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Graham Henstridge-2 |
Re: New to eLua and STM32F4xx
|
|
In reply to this post by BogdanM
On 04/06/2013, at 6:29 AM, Bogdan Marinescu <[hidden email]> wrote:
Bogdan, the recommended toolchain works like a breeze, where as the one I was using had VFP associated linking problems as James thought likely. The stm32f4 commit seems ok, but I have yet to confirm terminal operation. My aim is to use the stm32f407-discovery board to familiarise with eLua in case some optimisations can be identified for a stm32f427vg board hardware design. Graham _______________________________________________ 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 |