New to eLua and STM32F4xx

classic Classic list List threaded Threaded
12 messages Options
Graham Henstridge Graham Henstridge
Reply | Threaded
Open this post in threaded view
|

New to eLua and STM32F4xx

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
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: New to eLua and STM32F4xx


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:

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!

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.
 

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?

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.
 

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.

None that I know of, but personally I never tried to build eLua on a Mac.
 

4. Present issue is with require"lfs" not accepting lfs.so. Paths are ok. Suspecting Lua versions. Comments anyone?

This is quite strange. How are you installing lfs on your machine? What is the value of your LUA_PATH environment variable?

Best,
Bogdan
 

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


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Björn Kalkbrenner Björn Kalkbrenner
Reply | Threaded
Open this post in threaded view
|

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 Graham Henstridge-2
Reply | Threaded
Open this post in threaded view
|

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:


4. Present issue is with require"lfs" not accepting lfs.so. Paths are ok. Suspecting Lua versions. Comments anyone?

This is quite strange. How are you installing lfs on your machine? What is the value of your LUA_PATH environment variable?

Best,
Bogdan
 

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 Graham Henstridge-2
Reply | Threaded
Open this post in threaded view
|

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
jbsnyder jbsnyder
Reply | Threaded
Open this post in threaded view
|

Re: New to eLua and STM32F4xx

In reply to this post by BogdanM



On Mon, Jun 3, 2013 at 2:03 AM, Bogdan Marinescu <[hidden email]> wrote:

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:

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!

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.
 

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?

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.

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.
 
 

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.

None that I know of, but personally I never tried to build eLua on a Mac.

It should be fine on Mac OS X.  That's what I use for development.
 
 

4. Present issue is with require"lfs" not accepting lfs.so. Paths are ok. Suspecting Lua versions. Comments anyone?

This is quite strange. How are you installing lfs on your machine? What is the value of your LUA_PATH environment variable?

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.
 

Best,
Bogdan
 

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


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev



--
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
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: New to eLua and STM32F4xx

On Mon, Jun 3, 2013 at 8:28 PM, James Snyder <[hidden email]> wrote:



On Mon, Jun 3, 2013 at 2:03 AM, Bogdan Marinescu <[hidden email]> wrote:

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:

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!

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.
 

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?

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.

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.

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.

 

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 works very well, the multilib configuration is complete and it has a Mac version.

Best,
Bogdan

 
 

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.

None that I know of, but personally I never tried to build eLua on a Mac.

It should be fine on Mac OS X.  That's what I use for development.
 
 

4. Present issue is with require"lfs" not accepting lfs.so. Paths are ok. Suspecting Lua versions. Comments anyone?

This is quite strange. How are you installing lfs on your machine? What is the value of your LUA_PATH environment variable?

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.
 

Best,
Bogdan
 

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


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev



--
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


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
jbsnyder jbsnyder
Reply | Threaded
Open this post in threaded view
|

Re: New to eLua and STM32F4xx




On Mon, Jun 3, 2013 at 1:22 PM, Bogdan Marinescu <[hidden email]> wrote:
On Mon, Jun 3, 2013 at 8:28 PM, James Snyder <[hidden email]> wrote:



On Mon, Jun 3, 2013 at 2:03 AM, Bogdan Marinescu <[hidden email]> wrote:

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:

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!

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.
 

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?

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.

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.

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.

That sounds good for now.
 

 

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 works very well, the multilib configuration is complete and it has a Mac version.

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:



Best,
Bogdan

 
 

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.

None that I know of, but personally I never tried to build eLua on a Mac.

It should be fine on Mac OS X.  That's what I use for development.
 
 

4. Present issue is with require"lfs" not accepting lfs.so. Paths are ok. Suspecting Lua versions. Comments anyone?

This is quite strange. How are you installing lfs on your machine? What is the value of your LUA_PATH environment variable?

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.
 

Best,
Bogdan
 

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


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev



--
James Snyder
Biomedical Engineering
Northwestern University
http://fanplastic.org/key.txt
ph: <a href="tel:%28847%29%20448-0386" value="+18474480386" target="_blank">(847) 448-0386

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev



--
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
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: New to eLua and STM32F4xx




On Mon, Jun 3, 2013 at 9:43 PM, James Snyder <[hidden email]> wrote:



On Mon, Jun 3, 2013 at 1:22 PM, Bogdan Marinescu <[hidden email]> wrote:
On Mon, Jun 3, 2013 at 8:28 PM, James Snyder <[hidden email]> wrote:



On Mon, Jun 3, 2013 at 2:03 AM, Bogdan Marinescu <[hidden email]> wrote:

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:

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!

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.
 

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?

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.

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.

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.

That sounds good for now.

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
 
 

 

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 works very well, the multilib configuration is complete and it has a Mac version.

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:



Best,
Bogdan

 
 

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.

None that I know of, but personally I never tried to build eLua on a Mac.

It should be fine on Mac OS X.  That's what I use for development.
 
 

4. Present issue is with require"lfs" not accepting lfs.so. Paths are ok. Suspecting Lua versions. Comments anyone?

This is quite strange. How are you installing lfs on your machine? What is the value of your LUA_PATH environment variable?

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.
 

Best,
Bogdan
 

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


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev



--
James Snyder
Biomedical Engineering
Northwestern University
http://fanplastic.org/key.txt
ph: <a href="tel:%28847%29%20448-0386" value="+18474480386" target="_blank">(847) 448-0386

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev



--
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


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Graham Henstridge-2 Graham Henstridge-2
Reply | Threaded
Open this post in threaded view
|

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
jbsnyder jbsnyder
Reply | Threaded
Open this post in threaded view
|

Re: New to eLua and STM32F4xx

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:

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



--
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 Graham Henstridge-2
Reply | Threaded
Open this post in threaded view
|

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:

On Mon, Jun 3, 2013 at 9:43 PM, James Snyder <[hidden email]> wrote:



On Mon, Jun 3, 2013 at 1:22 PM, Bogdan Marinescu <[hidden email]> wrote:
On Mon, Jun 3, 2013 at 8:28 PM, James Snyder <[hidden email]> wrote:



On Mon, Jun 3, 2013 at 2:03 AM, Bogdan Marinescu <[hidden email]> wrote:

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:

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!

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.
 

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?

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.

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.

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.

That sounds good for now.

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
 
 

 

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 works very well, the multilib configuration is complete and it has a Mac version.

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:



Best,
Bogdan

 
 

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.

None that I know of, but personally I never tried to build eLua on a Mac.

It should be fine on Mac OS X.  That's what I use for development.
 
 

4. Present issue is with require"lfs" not accepting lfs.so. Paths are ok. Suspecting Lua versions. Comments anyone?

This is quite strange. How are you installing lfs on your machine? What is the value of your LUA_PATH environment variable?

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.
 

Best,
Bogdan
 

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


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev



--
James Snyder
Biomedical Engineering
Northwestern University
http://fanplastic.org/key.txt
ph: <a href="tel:%28847%29%20448-0386" value="+18474480386" target="_blank">(847) 448-0386

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev



--
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

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

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