STM32 Port of eLua

[Rob Emanuele-2]

Greetings,

We've started developing an STM32 port of eLua for our family of
products such as, http://www.crystalfontz.com/product/CFA735YYKKR1

We just completed a patch set for I2C and I have a question about the
methodology to enabling ports and clocks.  In the current STM32 port
the platform code initializes all of the clocks for each peripheral
supported in functions such as cans_init(), spis_init(), etc.  Having
all the clocks enabled when some may be unused wastes power and more
importantly, can cause unexpected behaviour if two peripherals that
share the same resources (pins, memory) conflict.  We do use some of
the pins in a remap state for their alternate functions.

I propose that we should not clock any peripheral (within reason,
GPIOs and peripherals internal to lua need to be clocked) until it is
setup.  For example, in this snip of my I2C code, I've created a "3rd"
I2C port which is really just the first port remapped to new pins.  I
am open to suggestions for better ways to do the remaps.  Anyway, the
example:

// ****************************************************************************
// I2C support
static const GPIO_TypeDef* i2c_port_data[] = { GPIOB, GPIOB, GPIOB };
static const I2C_TypeDef* i2cs[] = { I2C1, I2C2, I2C1 };
static const u32 i2c_clks[] = { RCC_APB1Periph_I2C1,
RCC_APB1Periph_I2C2, RCC_APB1Periph_I2C1 };
static const u16 i2c_clock_pin[] = { GPIO_Pin_6, GPIO_Pin_10, GPIO_Pin_8 };
static const u16 i2c_data_pin[] = { GPIO_Pin_7, GPIO_Pin_11, GPIO_Pin_9 };

#define I2C_TIMEOUT (500000)

u32 platform_i2c_setup( unsigned id, u32 speed )
{
  GPIO_InitTypeDef GPIO_InitStructure;
  I2C_InitTypeDef I2C_InitStructure;

  if (id == 2)
      GPIO_PinRemapConfig(GPIO_Remap_I2C1, ENABLE);

  // Setup PIO
  GPIO_StructInit( &GPIO_InitStructure );
  GPIO_InitStructure.GPIO_Pin = i2c_clock_pin[ id ] | i2c_data_pin[ id ];
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_Init( (GPIO_TypeDef*)i2c_port_data[ id ], &GPIO_InitStructure );

  // Setup and interface
  /* I2C configuration */
  I2C_StructInit( &I2C_InitStructure );
  I2C_InitStructure.I2C_Mode = I2C_Mode_I2C;
  I2C_InitStructure.I2C_DutyCycle = I2C_DutyCycle_2;
  I2C_InitStructure.I2C_OwnAddress1 = 0x0;
  I2C_InitStructure.I2C_Ack = I2C_Ack_Enable;
  I2C_InitStructure.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit;
  I2C_InitStructure.I2C_ClockSpeed = speed;

  RCC_APB1PeriphClockCmd(i2c_clks[ id ], ENABLE);

  I2C_DeInit( (I2C_TypeDef*)i2cs[ id ] );

  I2C_Cmd((I2C_TypeDef*)i2cs[ id ], ENABLE);

  I2C_Init( (I2C_TypeDef*)i2cs[ id ], &I2C_InitStructure );


  // Return actual speed
  return speed;
}
//****************************************************************************

How do people feel about this?  Would it also be good to have a way to
disable ports?

Once we come to a nice solution, our changes will be found:
https://github.com/crystalfontz/elua

Thank you,

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

[BogdanM]

Hi,

On Tue, Feb 14, 2012 at 8:44 PM, Rob Emanuele <[hidden email]> wrote:

> Greetings,
>
> We've started developing an STM32 port of eLua for our family of
> products such as, http://www.crystalfontz.com/product/CFA735YYKKR1
>
> We just completed a patch set for I2C and I have a question about the
> methodology to enabling ports and clocks.  In the current STM32 port
> the platform code initializes all of the clocks for each peripheral
> supported in functions such as cans_init(), spis_init(), etc.  Having
> all the clocks enabled when some may be unused wastes power and more
> importantly, can cause unexpected behaviour if two peripherals that
> share the same resources (pins, memory) conflict.  We do use some of
> the pins in a remap state for their alternate functions.
>
> I propose that we should not clock any peripheral (within reason,
> GPIOs and peripherals internal to lua need to be clocked) until it is
> setup.  For example, in this snip of my I2C code, I've created a "3rd"
> I2C port which is really just the first port remapped to new pins.  I
> am open to suggestions for better ways to do the remaps.  Anyway, the
> example:
>
> // ****************************************************************************
> // I2C support
> static const GPIO_TypeDef* i2c_port_data[] = { GPIOB, GPIOB, GPIOB };
> static const I2C_TypeDef* i2cs[] = { I2C1, I2C2, I2C1 };
> static const u32 i2c_clks[] = { RCC_APB1Periph_I2C1,
> RCC_APB1Periph_I2C2, RCC_APB1Periph_I2C1 };
> static const u16 i2c_clock_pin[] = { GPIO_Pin_6, GPIO_Pin_10, GPIO_Pin_8 };
> static const u16 i2c_data_pin[] = { GPIO_Pin_7, GPIO_Pin_11, GPIO_Pin_9 };
>
> #define I2C_TIMEOUT (500000)
>
> u32 platform_i2c_setup( unsigned id, u32 speed )
> {
>  GPIO_InitTypeDef GPIO_InitStructure;
>  I2C_InitTypeDef I2C_InitStructure;
>
>  if (id == 2)
>      GPIO_PinRemapConfig(GPIO_Remap_I2C1, ENABLE);
>
>  // Setup PIO
>  GPIO_StructInit( &GPIO_InitStructure );
>  GPIO_InitStructure.GPIO_Pin = i2c_clock_pin[ id ] | i2c_data_pin[ id ];
>  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD;
>  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
>  GPIO_Init( (GPIO_TypeDef*)i2c_port_data[ id ], &GPIO_InitStructure );
>
>  // Setup and interface
>  /* I2C configuration */
>  I2C_StructInit( &I2C_InitStructure );
>  I2C_InitStructure.I2C_Mode = I2C_Mode_I2C;
>  I2C_InitStructure.I2C_DutyCycle = I2C_DutyCycle_2;
>  I2C_InitStructure.I2C_OwnAddress1 = 0x0;
>  I2C_InitStructure.I2C_Ack = I2C_Ack_Enable;
>  I2C_InitStructure.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit;
>  I2C_InitStructure.I2C_ClockSpeed = speed;
>
>  RCC_APB1PeriphClockCmd(i2c_clks[ id ], ENABLE);
>
>  I2C_DeInit( (I2C_TypeDef*)i2cs[ id ] );
>
>  I2C_Cmd((I2C_TypeDef*)i2cs[ id ], ENABLE);
>
>  I2C_Init( (I2C_TypeDef*)i2cs[ id ], &I2C_InitStructure );
>
>
>  // Return actual speed
>  return speed;
> }
> //****************************************************************************
>
> How do people feel about this?  Would it also be good to have a way to
> disable ports?

Completely agreed. eLua does not address the issue of power
consumption at all at this moment, so having a way to change this can
only be a good thing. We just have to find a smart way. The first
thing that comes to mind is to add 'enable'/'disable' (and maybe
'is_enabled') functions for each peripheral, with some additional
rules to make life easier for a developer (for example, calling
'uart.setup' will automatically enable the given UART). This sounds a
bit too simplistic to be a complete solution, but I think it it a good
start.

Best,
Bogdan

>
> Once we come to a nice solution, our changes will be found:
> https://github.com/crystalfontz/elua
>
> Thank you,
>
> Rob
> _______________________________________________
> 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]

On Tue, Feb 14, 2012 at 2:26 PM, Bogdan Marinescu
<[hidden email]> wrote:

> Hi,
>
> On Tue, Feb 14, 2012 at 8:44 PM, Rob Emanuele <[hidden email]> wrote:
>> Greetings,
>>
>> We've started developing an STM32 port of eLua for our family of
>> products such as, http://www.crystalfontz.com/product/CFA735YYKKR1
>>
>> We just completed a patch set for I2C and I have a question about the
>> methodology to enabling ports and clocks.  In the current STM32 port
>> the platform code initializes all of the clocks for each peripheral
>> supported in functions such as cans_init(), spis_init(), etc.  Having
>> all the clocks enabled when some may be unused wastes power and more
>> importantly, can cause unexpected behaviour if two peripherals that
>> share the same resources (pins, memory) conflict.  We do use some of
>> the pins in a remap state for their alternate functions.
>>
>> I propose that we should not clock any peripheral (within reason,
>> GPIOs and peripherals internal to lua need to be clocked) until it is
>> setup.  For example, in this snip of my I2C code, I've created a "3rd"
>> I2C port which is really just the first port remapped to new pins.  I
>> am open to suggestions for better ways to do the remaps.  Anyway, the
>> example:
>>
>> // ****************************************************************************
>> // I2C support
>> static const GPIO_TypeDef* i2c_port_data[] = { GPIOB, GPIOB, GPIOB };
>> static const I2C_TypeDef* i2cs[] = { I2C1, I2C2, I2C1 };
>> static const u32 i2c_clks[] = { RCC_APB1Periph_I2C1,
>> RCC_APB1Periph_I2C2, RCC_APB1Periph_I2C1 };
>> static const u16 i2c_clock_pin[] = { GPIO_Pin_6, GPIO_Pin_10, GPIO_Pin_8 };
>> static const u16 i2c_data_pin[] = { GPIO_Pin_7, GPIO_Pin_11, GPIO_Pin_9 };
>>
>> #define I2C_TIMEOUT (500000)
>>
>> u32 platform_i2c_setup( unsigned id, u32 speed )
>> {
>>  GPIO_InitTypeDef GPIO_InitStructure;
>>  I2C_InitTypeDef I2C_InitStructure;
>>
>>  if (id == 2)
>>      GPIO_PinRemapConfig(GPIO_Remap_I2C1, ENABLE);
>>
>>  // Setup PIO
>>  GPIO_StructInit( &GPIO_InitStructure );
>>  GPIO_InitStructure.GPIO_Pin = i2c_clock_pin[ id ] | i2c_data_pin[ id ];
>>  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD;
>>  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
>>  GPIO_Init( (GPIO_TypeDef*)i2c_port_data[ id ], &GPIO_InitStructure );
>>
>>  // Setup and interface
>>  /* I2C configuration */
>>  I2C_StructInit( &I2C_InitStructure );
>>  I2C_InitStructure.I2C_Mode = I2C_Mode_I2C;
>>  I2C_InitStructure.I2C_DutyCycle = I2C_DutyCycle_2;
>>  I2C_InitStructure.I2C_OwnAddress1 = 0x0;
>>  I2C_InitStructure.I2C_Ack = I2C_Ack_Enable;
>>  I2C_InitStructure.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit;
>>  I2C_InitStructure.I2C_ClockSpeed = speed;
>>
>>  RCC_APB1PeriphClockCmd(i2c_clks[ id ], ENABLE);
>>
>>  I2C_DeInit( (I2C_TypeDef*)i2cs[ id ] );
>>
>>  I2C_Cmd((I2C_TypeDef*)i2cs[ id ], ENABLE);
>>
>>  I2C_Init( (I2C_TypeDef*)i2cs[ id ], &I2C_InitStructure );
>>
>>
>>  // Return actual speed
>>  return speed;
>> }
>> //****************************************************************************
>>
>> How do people feel about this?  Would it also be good to have a way to
>> disable ports?
>
> Completely agreed. eLua does not address the issue of power
> consumption at all at this moment, so having a way to change this can
> only be a good thing. We just have to find a smart way. The first
> thing that comes to mind is to add 'enable'/'disable' (and maybe
> 'is_enabled') functions for each peripheral, with some additional
> rules to make life easier for a developer (for example, calling
> 'uart.setup' will automatically enable the given UART). This sounds a
> bit too simplistic to be a complete solution, but I think it it a good
> start.

I think in some cases we do do the clocking in the setup functions,
other times it's just done at startup.

I'd be fine with making clocking implicit in setup or usage of a
peripheral (since not everything has a setup function), requiring
enable/disable for everything would break existing functionality and
make code overly verbose.  On the Lua level this might not require
explicit enabling of clocking, but the underlying platform API would
include and make use of enable/disable functions to make this somewhat
transparent.  In addition, we could expose enable/disable functions
within Lua for direct control.

>
> Best,
> Bogdan
>
>>
>> Once we come to a nice solution, our changes will be found:
>> https://github.com/crystalfontz/elua
>>
>> Thank you,
>>
>> Rob
>> _______________________________________________
>> 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: [phone]
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Rob Emanuele-2]

Ok, I'm going to look at adding enables and disables.  Maybe the setup
call implicitly enables the peripheral.

So is anyone active in the STM32 port?  I'd like to clean it up, so it
is more like the AVR32 port.  Basically break out the differences
between the chips and boards into separate files.

On a related note, what is conf.lua in the port?  It looks like
conf.py for SCons.

Thanks,

Rob

On Tue, Feb 14, 2012 at 1:24 PM, James Snyder <[hidden email]> wrote:

> On Tue, Feb 14, 2012 at 2:26 PM, Bogdan Marinescu
> <[hidden email]> wrote:
>> Hi,
>>
>> On Tue, Feb 14, 2012 at 8:44 PM, Rob Emanuele <[hidden email]> wrote:
>>> Greetings,
>>>
>>> We've started developing an STM32 port of eLua for our family of
>>> products such as, http://www.crystalfontz.com/product/CFA735YYKKR1
>>>
>>> We just completed a patch set for I2C and I have a question about the
>>> methodology to enabling ports and clocks.  In the current STM32 port
>>> the platform code initializes all of the clocks for each peripheral
>>> supported in functions such as cans_init(), spis_init(), etc.  Having
>>> all the clocks enabled when some may be unused wastes power and more
>>> importantly, can cause unexpected behaviour if two peripherals that
>>> share the same resources (pins, memory) conflict.  We do use some of
>>> the pins in a remap state for their alternate functions.
>>>
>>> I propose that we should not clock any peripheral (within reason,
>>> GPIOs and peripherals internal to lua need to be clocked) until it is
>>> setup.  For example, in this snip of my I2C code, I've created a "3rd"
>>> I2C port which is really just the first port remapped to new pins.  I
>>> am open to suggestions for better ways to do the remaps.  Anyway, the
>>> example:
>>>
>>> // ****************************************************************************
>>> // I2C support
>>> static const GPIO_TypeDef* i2c_port_data[] = { GPIOB, GPIOB, GPIOB };
>>> static const I2C_TypeDef* i2cs[] = { I2C1, I2C2, I2C1 };
>>> static const u32 i2c_clks[] = { RCC_APB1Periph_I2C1,
>>> RCC_APB1Periph_I2C2, RCC_APB1Periph_I2C1 };
>>> static const u16 i2c_clock_pin[] = { GPIO_Pin_6, GPIO_Pin_10, GPIO_Pin_8 };
>>> static const u16 i2c_data_pin[] = { GPIO_Pin_7, GPIO_Pin_11, GPIO_Pin_9 };
>>>
>>> #define I2C_TIMEOUT (500000)
>>>
>>> u32 platform_i2c_setup( unsigned id, u32 speed )
>>> {
>>>  GPIO_InitTypeDef GPIO_InitStructure;
>>>  I2C_InitTypeDef I2C_InitStructure;
>>>
>>>  if (id == 2)
>>>      GPIO_PinRemapConfig(GPIO_Remap_I2C1, ENABLE);
>>>
>>>  // Setup PIO
>>>  GPIO_StructInit( &GPIO_InitStructure );
>>>  GPIO_InitStructure.GPIO_Pin = i2c_clock_pin[ id ] | i2c_data_pin[ id ];
>>>  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD;
>>>  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
>>>  GPIO_Init( (GPIO_TypeDef*)i2c_port_data[ id ], &GPIO_InitStructure );
>>>
>>>  // Setup and interface
>>>  /* I2C configuration */
>>>  I2C_StructInit( &I2C_InitStructure );
>>>  I2C_InitStructure.I2C_Mode = I2C_Mode_I2C;
>>>  I2C_InitStructure.I2C_DutyCycle = I2C_DutyCycle_2;
>>>  I2C_InitStructure.I2C_OwnAddress1 = 0x0;
>>>  I2C_InitStructure.I2C_Ack = I2C_Ack_Enable;
>>>  I2C_InitStructure.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit;
>>>  I2C_InitStructure.I2C_ClockSpeed = speed;
>>>
>>>  RCC_APB1PeriphClockCmd(i2c_clks[ id ], ENABLE);
>>>
>>>  I2C_DeInit( (I2C_TypeDef*)i2cs[ id ] );
>>>
>>>  I2C_Cmd((I2C_TypeDef*)i2cs[ id ], ENABLE);
>>>
>>>  I2C_Init( (I2C_TypeDef*)i2cs[ id ], &I2C_InitStructure );
>>>
>>>
>>>  // Return actual speed
>>>  return speed;
>>> }
>>> //****************************************************************************
>>>
>>> How do people feel about this?  Would it also be good to have a way to
>>> disable ports?
>>
>> Completely agreed. eLua does not address the issue of power
>> consumption at all at this moment, so having a way to change this can
>> only be a good thing. We just have to find a smart way. The first
>> thing that comes to mind is to add 'enable'/'disable' (and maybe
>> 'is_enabled') functions for each peripheral, with some additional
>> rules to make life easier for a developer (for example, calling
>> 'uart.setup' will automatically enable the given UART). This sounds a
>> bit too simplistic to be a complete solution, but I think it it a good
>> start.
>
> I think in some cases we do do the clocking in the setup functions,
> other times it's just done at startup.
>
> I'd be fine with making clocking implicit in setup or usage of a
> peripheral (since not everything has a setup function), requiring
> enable/disable for everything would break existing functionality and
> make code overly verbose.  On the Lua level this might not require
> explicit enabling of clocking, but the underlying platform API would
> include and make use of enable/disable functions to make this somewhat
> transparent.  In addition, we could expose enable/disable functions
> within Lua for direct control.
>
>>
>> Best,
>> Bogdan
>>
>>>
>>> Once we come to a nice solution, our changes will be found:
>>> https://github.com/crystalfontz/elua
>>>
>>> Thank you,
>>>
>>> Rob
>>> _______________________________________________
>>> 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: [phone]
> _______________________________________________
> 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

[BogdanM]

Hi,

On Wed, Feb 15, 2012 at 12:47 AM, Rob Emanuele <[hidden email]> wrote:
> Ok, I'm going to look at adding enables and disables.  Maybe the setup
> call implicitly enables the peripheral.
>
> So is anyone active in the STM32 port?

Currently, only the AVR32 port has an official maintainer. STM32 is
quite active though, with both James and me working on it and the
community recently contributing support for the newer M4 cores from
ST.

> I'd like to clean it up, so it
> is more like the AVR32 port.  Basically break out the differences
> between the chips and boards into separate files.

By all means, do that. It can't possibly be a bad thing and it might
just clean things enough to get us courage to merge the M4 support :)

>
> On a related note, what is conf.lua in the port?  It looks like
> conf.py for SCons.

eLua has an (yet still mostly unnoficial) Lua based build system. For
this build system, conf.lua does what conf.py does for SConstruct.

Best,
Bogdan

>
> Thanks,
>
> Rob
>
> On Tue, Feb 14, 2012 at 1:24 PM, James Snyder <[hidden email]> wrote:
>> On Tue, Feb 14, 2012 at 2:26 PM, Bogdan Marinescu
>> <[hidden email]> wrote:
>>> Hi,
>>>
>>> On Tue, Feb 14, 2012 at 8:44 PM, Rob Emanuele <[hidden email]> wrote:
>>>> Greetings,
>>>>
>>>> We've started developing an STM32 port of eLua for our family of
>>>> products such as, http://www.crystalfontz.com/product/CFA735YYKKR1
>>>>
>>>> We just completed a patch set for I2C and I have a question about the
>>>> methodology to enabling ports and clocks.  In the current STM32 port
>>>> the platform code initializes all of the clocks for each peripheral
>>>> supported in functions such as cans_init(), spis_init(), etc.  Having
>>>> all the clocks enabled when some may be unused wastes power and more
>>>> importantly, can cause unexpected behaviour if two peripherals that
>>>> share the same resources (pins, memory) conflict.  We do use some of
>>>> the pins in a remap state for their alternate functions.
>>>>
>>>> I propose that we should not clock any peripheral (within reason,
>>>> GPIOs and peripherals internal to lua need to be clocked) until it is
>>>> setup.  For example, in this snip of my I2C code, I've created a "3rd"
>>>> I2C port which is really just the first port remapped to new pins.  I
>>>> am open to suggestions for better ways to do the remaps.  Anyway, the
>>>> example:
>>>>
>>>> // ****************************************************************************
>>>> // I2C support
>>>> static const GPIO_TypeDef* i2c_port_data[] = { GPIOB, GPIOB, GPIOB };
>>>> static const I2C_TypeDef* i2cs[] = { I2C1, I2C2, I2C1 };
>>>> static const u32 i2c_clks[] = { RCC_APB1Periph_I2C1,
>>>> RCC_APB1Periph_I2C2, RCC_APB1Periph_I2C1 };
>>>> static const u16 i2c_clock_pin[] = { GPIO_Pin_6, GPIO_Pin_10, GPIO_Pin_8 };
>>>> static const u16 i2c_data_pin[] = { GPIO_Pin_7, GPIO_Pin_11, GPIO_Pin_9 };
>>>>
>>>> #define I2C_TIMEOUT (500000)
>>>>
>>>> u32 platform_i2c_setup( unsigned id, u32 speed )
>>>> {
>>>>  GPIO_InitTypeDef GPIO_InitStructure;
>>>>  I2C_InitTypeDef I2C_InitStructure;
>>>>
>>>>  if (id == 2)
>>>>      GPIO_PinRemapConfig(GPIO_Remap_I2C1, ENABLE);
>>>>
>>>>  // Setup PIO
>>>>  GPIO_StructInit( &GPIO_InitStructure );
>>>>  GPIO_InitStructure.GPIO_Pin = i2c_clock_pin[ id ] | i2c_data_pin[ id ];
>>>>  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD;
>>>>  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
>>>>  GPIO_Init( (GPIO_TypeDef*)i2c_port_data[ id ], &GPIO_InitStructure );
>>>>
>>>>  // Setup and interface
>>>>  /* I2C configuration */
>>>>  I2C_StructInit( &I2C_InitStructure );
>>>>  I2C_InitStructure.I2C_Mode = I2C_Mode_I2C;
>>>>  I2C_InitStructure.I2C_DutyCycle = I2C_DutyCycle_2;
>>>>  I2C_InitStructure.I2C_OwnAddress1 = 0x0;
>>>>  I2C_InitStructure.I2C_Ack = I2C_Ack_Enable;
>>>>  I2C_InitStructure.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit;
>>>>  I2C_InitStructure.I2C_ClockSpeed = speed;
>>>>
>>>>  RCC_APB1PeriphClockCmd(i2c_clks[ id ], ENABLE);
>>>>
>>>>  I2C_DeInit( (I2C_TypeDef*)i2cs[ id ] );
>>>>
>>>>  I2C_Cmd((I2C_TypeDef*)i2cs[ id ], ENABLE);
>>>>
>>>>  I2C_Init( (I2C_TypeDef*)i2cs[ id ], &I2C_InitStructure );
>>>>
>>>>
>>>>  // Return actual speed
>>>>  return speed;
>>>> }
>>>> //****************************************************************************
>>>>
>>>> How do people feel about this?  Would it also be good to have a way to
>>>> disable ports?
>>>
>>> Completely agreed. eLua does not address the issue of power
>>> consumption at all at this moment, so having a way to change this can
>>> only be a good thing. We just have to find a smart way. The first
>>> thing that comes to mind is to add 'enable'/'disable' (and maybe
>>> 'is_enabled') functions for each peripheral, with some additional
>>> rules to make life easier for a developer (for example, calling
>>> 'uart.setup' will automatically enable the given UART). This sounds a
>>> bit too simplistic to be a complete solution, but I think it it a good
>>> start.
>>
>> I think in some cases we do do the clocking in the setup functions,
>> other times it's just done at startup.
>>
>> I'd be fine with making clocking implicit in setup or usage of a
>> peripheral (since not everything has a setup function), requiring
>> enable/disable for everything would break existing functionality and
>> make code overly verbose.  On the Lua level this might not require
>> explicit enabling of clocking, but the underlying platform API would
>> include and make use of enable/disable functions to make this somewhat
>> transparent.  In addition, we could expose enable/disable functions
>> within Lua for direct control.
>>
>>>
>>> Best,
>>> Bogdan
>>>
>>>>
>>>> Once we come to a nice solution, our changes will be found:
>>>> https://github.com/crystalfontz/elua
>>>>
>>>> Thank you,
>>>>
>>>> Rob
>>>> _______________________________________________
>>>> 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: [phone]
>> _______________________________________________
>> 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

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

[Ivan - Omnima]

Hi,

We are finalising the port to our STM32Expander board at the moment.

We have added support for multiple boards for the STM32 platform but I'm
not sure whether this exactly the recommended way of doing it.

With all our changes, platform.c has become populated with series of
#ifdef BOARD== statements. For this reason we've decided to migrate our
platform code to a separate platform-omniext.c file.

Our version of the STM32 platform conf.lua file is attached here.

- The current version adds a #define to the Makefile for each supported
board so that #ifdef PLATFORM macros can be added to C code
- The file as includes "if comp.board:upper() == BOARD" statements to
select between components and modules for each specific port

Please let me know how you'd like to proceed with this.

Regards,
Ivan

Omnima Limited
Ivan Ignjatic
176 Kennington Road
Oxford OX1 5PG

Tel. [phone]
Fax. [phone]

Web: www.omnima.co.uk
Skype: omnimaautomation


On 15/02/2012 09:02, Bogdan Marinescu wrote:

> Hi,
>
> On Wed, Feb 15, 2012 at 12:47 AM, Rob Emanuele<[hidden email]>  wrote:
>> Ok, I'm going to look at adding enables and disables.  Maybe the setup
>> call implicitly enables the peripheral.
>>
>> So is anyone active in the STM32 port?
> Currently, only the AVR32 port has an official maintainer. STM32 is
> quite active though, with both James and me working on it and the
> community recently contributing support for the newer M4 cores from
> ST.
>
>> I'd like to clean it up, so it
>> is more like the AVR32 port.  Basically break out the differences
>> between the chips and boards into separate files.
> By all means, do that. It can't possibly be a bad thing and it might
> just clean things enough to get us courage to merge the M4 support :)
>
>> On a related note, what is conf.lua in the port?  It looks like
>> conf.py for SCons.
> eLua has an (yet still mostly unnoficial) Lua based build system. For
> this build system, conf.lua does what conf.py does for SConstruct.
>
> Best,
> Bogdan
>
>> Thanks,
>>
>> Rob
>>
>> On Tue, Feb 14, 2012 at 1:24 PM, James Snyder<[hidden email]>  wrote:
>>> On Tue, Feb 14, 2012 at 2:26 PM, Bogdan Marinescu
>>> <[hidden email]>  wrote:
>>>> Hi,
>>>>
>>>> On Tue, Feb 14, 2012 at 8:44 PM, Rob Emanuele<[hidden email]>  wrote:
>>>>> Greetings,
>>>>>
>>>>> We've started developing an STM32 port of eLua for our family of
>>>>> products such as, http://www.crystalfontz.com/product/CFA735YYKKR1
>>>>>
>>>>> We just completed a patch set for I2C and I have a question about the
>>>>> methodology to enabling ports and clocks.  In the current STM32 port
>>>>> the platform code initializes all of the clocks for each peripheral
>>>>> supported in functions such as cans_init(), spis_init(), etc.  Having
>>>>> all the clocks enabled when some may be unused wastes power and more
>>>>> importantly, can cause unexpected behaviour if two peripherals that
>>>>> share the same resources (pins, memory) conflict.  We do use some of
>>>>> the pins in a remap state for their alternate functions.
>>>>>
>>>>> I propose that we should not clock any peripheral (within reason,
>>>>> GPIOs and peripherals internal to lua need to be clocked) until it is
>>>>> setup.  For example, in this snip of my I2C code, I've created a "3rd"
>>>>> I2C port which is really just the first port remapped to new pins.  I
>>>>> am open to suggestions for better ways to do the remaps.  Anyway, the
>>>>> example:
>>>>>
>>>>> // ****************************************************************************
>>>>> // I2C support
>>>>> static const GPIO_TypeDef* i2c_port_data[] = { GPIOB, GPIOB, GPIOB };
>>>>> static const I2C_TypeDef* i2cs[] = { I2C1, I2C2, I2C1 };
>>>>> static const u32 i2c_clks[] = { RCC_APB1Periph_I2C1,
>>>>> RCC_APB1Periph_I2C2, RCC_APB1Periph_I2C1 };
>>>>> static const u16 i2c_clock_pin[] = { GPIO_Pin_6, GPIO_Pin_10, GPIO_Pin_8 };
>>>>> static const u16 i2c_data_pin[] = { GPIO_Pin_7, GPIO_Pin_11, GPIO_Pin_9 };
>>>>>
>>>>> #define I2C_TIMEOUT (500000)
>>>>>
>>>>> u32 platform_i2c_setup( unsigned id, u32 speed )
>>>>> {
>>>>>   GPIO_InitTypeDef GPIO_InitStructure;
>>>>>   I2C_InitTypeDef I2C_InitStructure;
>>>>>
>>>>>   if (id == 2)
>>>>>       GPIO_PinRemapConfig(GPIO_Remap_I2C1, ENABLE);
>>>>>
>>>>>   // Setup PIO
>>>>>   GPIO_StructInit(&GPIO_InitStructure );
>>>>>   GPIO_InitStructure.GPIO_Pin = i2c_clock_pin[ id ] | i2c_data_pin[ id ];
>>>>>   GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD;
>>>>>   GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
>>>>>   GPIO_Init( (GPIO_TypeDef*)i2c_port_data[ id ],&GPIO_InitStructure );
>>>>>
>>>>>   // Setup and interface
>>>>>   /* I2C configuration */
>>>>>   I2C_StructInit(&I2C_InitStructure );
>>>>>   I2C_InitStructure.I2C_Mode = I2C_Mode_I2C;
>>>>>   I2C_InitStructure.I2C_DutyCycle = I2C_DutyCycle_2;
>>>>>   I2C_InitStructure.I2C_OwnAddress1 = 0x0;
>>>>>   I2C_InitStructure.I2C_Ack = I2C_Ack_Enable;
>>>>>   I2C_InitStructure.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit;
>>>>>   I2C_InitStructure.I2C_ClockSpeed = speed;
>>>>>
>>>>>   RCC_APB1PeriphClockCmd(i2c_clks[ id ], ENABLE);
>>>>>
>>>>>   I2C_DeInit( (I2C_TypeDef*)i2cs[ id ] );
>>>>>
>>>>>   I2C_Cmd((I2C_TypeDef*)i2cs[ id ], ENABLE);
>>>>>
>>>>>   I2C_Init( (I2C_TypeDef*)i2cs[ id ],&I2C_InitStructure );
>>>>>
>>>>>
>>>>>   // Return actual speed
>>>>>   return speed;
>>>>> }
>>>>> //****************************************************************************
>>>>>
>>>>> How do people feel about this?  Would it also be good to have a way to
>>>>> disable ports?
>>>> Completely agreed. eLua does not address the issue of power
>>>> consumption at all at this moment, so having a way to change this can
>>>> only be a good thing. We just have to find a smart way. The first
>>>> thing that comes to mind is to add 'enable'/'disable' (and maybe
>>>> 'is_enabled') functions for each peripheral, with some additional
>>>> rules to make life easier for a developer (for example, calling
>>>> 'uart.setup' will automatically enable the given UART). This sounds a
>>>> bit too simplistic to be a complete solution, but I think it it a good
>>>> start.
>>> I think in some cases we do do the clocking in the setup functions,
>>> other times it's just done at startup.
>>>
>>> I'd be fine with making clocking implicit in setup or usage of a
>>> peripheral (since not everything has a setup function), requiring
>>> enable/disable for everything would break existing functionality and
>>> make code overly verbose.  On the Lua level this might not require
>>> explicit enabling of clocking, but the underlying platform API would
>>> include and make use of enable/disable functions to make this somewhat
>>> transparent.  In addition, we could expose enable/disable functions
>>> within Lua for direct control.
>>>
>>>> Best,
>>>> Bogdan
>>>>
>>>>> Once we come to a nice solution, our changes will be found:
>>>>> https://github.com/crystalfontz/elua
>>>>>
>>>>> Thank you,
>>>>>
>>>>> Rob
>>>>> _______________________________________________
>>>>> 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: [phone]
>>> _______________________________________________
>>> 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
> _______________________________________________
> 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

[BogdanM]

On Wed, Feb 15, 2012 at 11:36 AM, Ivan - Omnima <[hidden email]> wrote:

> Hi,
>
> We are finalising the port to our STM32Expander board at the moment.
>
> We have added support for multiple boards for the STM32 platform but I'm not
> sure whether this exactly the recommended way of doing it.
>
> With all our changes, platform.c has become populated with series of #ifdef
> BOARD== statements. For this reason we've decided to migrate our platform
> code to a separate platform-omniext.c file.

This is the way to go, for sure. The trick is then to identify all the
common parts properly, in order to avoid code duplication (a real
killer in my book). STM32 has a lot of support in eLua, so I'd say to
go with this route with all boards: keep as much of the common code as
possible in a common place (something like 'generic_platform.c') and
then add specific support for each board in turn in a file named
'<board(s)>.c'. More than one board can share the same board-specific
implementation file if that makes sense; in this case, either:

1. name the board-specific file properly (example: 'et_stm32_stm3210e_eval.c')
2. keep a C file per board and simply include another source file in
it (this is allowed in this particular case, although not generally
recommended). For example:

  et_stm32.c -> contains actualy code
  stm3210e_eval.c -> contains a single "#include "et_stm32.c" line

Identifying common parts is not going to be an easy task, as there
will be parts common to all boards, parts common to only 4 boards,
parts common to only 2 boards and so on. Still, this is preffered to
code duplication if you ask me.
The same principles apply for headers, including the dreaded platform_conf.h.

>
> Our version of the STM32 platform conf.lua file is attached here.
>
> - The current version adds a #define to the Makefile for each supported
> board so that #ifdef PLATFORM macros can be added to C code

eLua already generates macros automatically for this task. Compile
either with scons (or with build_elua.lua specifying 'disp_mode=all')
and you'll see the generated macros in the command line of the
compiler. I don't think you need to add other macros. Other than that,
your approach is fine.

Best,
Bogdan

> - The file as includes "if comp.board:upper() == BOARD" statements to select
> between components and modules for each specific port
>
> Please let me know how you'd like to proceed with this.
>
> Regards,
> Ivan
>
> Omnima Limited
> Ivan Ignjatic
> 176 Kennington Road
> Oxford OX1 5PG
>
> Tel. [phone]
> Fax. [phone]
>
> Web: www.omnima.co.uk
> Skype: omnimaautomation
>
>
>
> On 15/02/2012 09:02, Bogdan Marinescu wrote:
>>
>> Hi,
>>
>> On Wed, Feb 15, 2012 at 12:47 AM, Rob Emanuele<[hidden email]>  wrote:
>>>
>>> Ok, I'm going to look at adding enables and disables.  Maybe the setup
>>> call implicitly enables the peripheral.
>>>
>>> So is anyone active in the STM32 port?
>>
>> Currently, only the AVR32 port has an official maintainer. STM32 is
>> quite active though, with both James and me working on it and the
>> community recently contributing support for the newer M4 cores from
>> ST.
>>
>>> I'd like to clean it up, so it
>>> is more like the AVR32 port.  Basically break out the differences
>>> between the chips and boards into separate files.
>>
>> By all means, do that. It can't possibly be a bad thing and it might
>> just clean things enough to get us courage to merge the M4 support :)
>>
>>> On a related note, what is conf.lua in the port?  It looks like
>>> conf.py for SCons.
>>
>> eLua has an (yet still mostly unnoficial) Lua based build system. For
>> this build system, conf.lua does what conf.py does for SConstruct.
>>
>> Best,
>> Bogdan
>>
>>> Thanks,
>>>
>>> Rob
>>>
>>> On Tue, Feb 14, 2012 at 1:24 PM, James Snyder<[hidden email]>
>>>  wrote:
>>>>
>>>> On Tue, Feb 14, 2012 at 2:26 PM, Bogdan Marinescu
>>>> <[hidden email]>  wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Tue, Feb 14, 2012 at 8:44 PM, Rob Emanuele<[hidden email]>  wrote:
>>>>>>
>>>>>> Greetings,
>>>>>>
>>>>>> We've started developing an STM32 port of eLua for our family of
>>>>>> products such as, http://www.crystalfontz.com/product/CFA735YYKKR1
>>>>>>
>>>>>> We just completed a patch set for I2C and I have a question about the
>>>>>> methodology to enabling ports and clocks.  In the current STM32 port
>>>>>> the platform code initializes all of the clocks for each peripheral
>>>>>> supported in functions such as cans_init(), spis_init(), etc.  Having
>>>>>> all the clocks enabled when some may be unused wastes power and more
>>>>>> importantly, can cause unexpected behaviour if two peripherals that
>>>>>> share the same resources (pins, memory) conflict.  We do use some of
>>>>>> the pins in a remap state for their alternate functions.
>>>>>>
>>>>>> I propose that we should not clock any peripheral (within reason,
>>>>>> GPIOs and peripherals internal to lua need to be clocked) until it is
>>>>>> setup.  For example, in this snip of my I2C code, I've created a "3rd"
>>>>>> I2C port which is really just the first port remapped to new pins.  I
>>>>>> am open to suggestions for better ways to do the remaps.  Anyway, the
>>>>>> example:
>>>>>>
>>>>>> //
>>>>>> ****************************************************************************
>>>>>> // I2C support
>>>>>> static const GPIO_TypeDef* i2c_port_data[] = { GPIOB, GPIOB, GPIOB };
>>>>>> static const I2C_TypeDef* i2cs[] = { I2C1, I2C2, I2C1 };
>>>>>> static const u32 i2c_clks[] = { RCC_APB1Periph_I2C1,
>>>>>> RCC_APB1Periph_I2C2, RCC_APB1Periph_I2C1 };
>>>>>> static const u16 i2c_clock_pin[] = { GPIO_Pin_6, GPIO_Pin_10,
>>>>>> GPIO_Pin_8 };
>>>>>> static const u16 i2c_data_pin[] = { GPIO_Pin_7, GPIO_Pin_11,
>>>>>> GPIO_Pin_9 };
>>>>>>
>>>>>> #define I2C_TIMEOUT (500000)
>>>>>>
>>>>>> u32 platform_i2c_setup( unsigned id, u32 speed )
>>>>>> {
>>>>>>  GPIO_InitTypeDef GPIO_InitStructure;
>>>>>>  I2C_InitTypeDef I2C_InitStructure;
>>>>>>
>>>>>>  if (id == 2)
>>>>>>      GPIO_PinRemapConfig(GPIO_Remap_I2C1, ENABLE);
>>>>>>
>>>>>>  // Setup PIO
>>>>>>  GPIO_StructInit(&GPIO_InitStructure );
>>>>>>
>>>>>>  GPIO_InitStructure.GPIO_Pin = i2c_clock_pin[ id ] | i2c_data_pin[ id
>>>>>> ];
>>>>>>  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD;
>>>>>>  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
>>>>>>  GPIO_Init( (GPIO_TypeDef*)i2c_port_data[ id ],&GPIO_InitStructure );
>>>>>>
>>>>>>
>>>>>>  // Setup and interface
>>>>>>  /* I2C configuration */
>>>>>>  I2C_StructInit(&I2C_InitStructure );
>>>>>>
>>>>>>  I2C_InitStructure.I2C_Mode = I2C_Mode_I2C;
>>>>>>  I2C_InitStructure.I2C_DutyCycle = I2C_DutyCycle_2;
>>>>>>  I2C_InitStructure.I2C_OwnAddress1 = 0x0;
>>>>>>  I2C_InitStructure.I2C_Ack = I2C_Ack_Enable;
>>>>>>  I2C_InitStructure.I2C_AcknowledgedAddress =
>>>>>> I2C_AcknowledgedAddress_7bit;
>>>>>>  I2C_InitStructure.I2C_ClockSpeed = speed;
>>>>>>
>>>>>>  RCC_APB1PeriphClockCmd(i2c_clks[ id ], ENABLE);
>>>>>>
>>>>>>  I2C_DeInit( (I2C_TypeDef*)i2cs[ id ] );
>>>>>>
>>>>>>  I2C_Cmd((I2C_TypeDef*)i2cs[ id ], ENABLE);
>>>>>>
>>>>>>  I2C_Init( (I2C_TypeDef*)i2cs[ id ],&I2C_InitStructure );
>>>>>>
>>>>>>
>>>>>>
>>>>>>  // Return actual speed
>>>>>>  return speed;
>>>>>> }
>>>>>>
>>>>>> //****************************************************************************
>>>>>>
>>>>>> How do people feel about this?  Would it also be good to have a way to
>>>>>> disable ports?
>>>>>
>>>>> Completely agreed. eLua does not address the issue of power
>>>>> consumption at all at this moment, so having a way to change this can
>>>>> only be a good thing. We just have to find a smart way. The first
>>>>> thing that comes to mind is to add 'enable'/'disable' (and maybe
>>>>> 'is_enabled') functions for each peripheral, with some additional
>>>>> rules to make life easier for a developer (for example, calling
>>>>> 'uart.setup' will automatically enable the given UART). This sounds a
>>>>> bit too simplistic to be a complete solution, but I think it it a good
>>>>> start.
>>>>
>>>> I think in some cases we do do the clocking in the setup functions,
>>>> other times it's just done at startup.
>>>>
>>>> I'd be fine with making clocking implicit in setup or usage of a
>>>> peripheral (since not everything has a setup function), requiring
>>>> enable/disable for everything would break existing functionality and
>>>> make code overly verbose.  On the Lua level this might not require
>>>> explicit enabling of clocking, but the underlying platform API would
>>>> include and make use of enable/disable functions to make this somewhat
>>>> transparent.  In addition, we could expose enable/disable functions
>>>> within Lua for direct control.
>>>>
>>>>> Best,
>>>>> Bogdan
>>>>>
>>>>>> Once we come to a nice solution, our changes will be found:
>>>>>> https://github.com/crystalfontz/elua
>>>>>>
>>>>>> Thank you,
>>>>>>
>>>>>> Rob
>>>>>> _______________________________________________
>>>>>> 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: [phone]
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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
>

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

[Martin Guy]

On 15 February 2012 10:02, Bogdan Marinescu <[hidden email]> wrote:
> Currently, only the AVR32 port has an official maintainer.

Currently, only the AVR32 port has a maintainer.

>> I'd like to clean it up, so it
>> is more like the AVR32 port.  Basically break out the differences
>> between the chips and boards into separate files.

For AVR32, someone did that by creating
src/platform/avr32/EVK1100/evk1100.h
src/platform/avr32/EVK1100/evk1100_conf.h
src/platform/avr32/EVK1101/evk1101.h
src/platform/avr32/EVK1101/evk1101_conf.h
src/platform/avr32/MIZAR32/mizar32.h
src/platform/avr32/MIZAR32/mizar32_conf.h

then
src/platform/avr32/board.h includes .../SOMETHING/something.h
and
src/platform/avr32.platform_conf.h includes .../SOMETHING/something_conf.h

In practice the something.h are copies of one of the manufacturer's
SDK headers and the something_conf.h are all eLua-dependent
configurable items, and "board.h" is not architecture-wide, but is
only present in the two Atmel ports with no similarity between the
files' contents.

the stm32 port instead has some other similar idea, with all the files
in the same root (I wish the avr32 person has done this too. The
capitalised directories just make for extra typing)

So basically, the platform-independent files include
src/platform/*/platform_conf.h
and below that you can do whatever seems best to you, according to
what your SDK suggests

>> On a related note, what is conf.lua in the port?  It looks like
>> conf.py for SCons.
>
> eLua has an (yet still mostly unnoficial) Lua based build system. For
> this build system, conf.lua does what conf.py does for SConstruct.

So you have to remember that any change you make to conf.py also has
to be made in conf.lua. Or vice versa. The command-line syntax and
functionality for both should be the same, except where people have
modified one but not the other, introducing build system-dependent
bugs, and the Lua one doesn't support parallel builds so the compile
time is two, four or eight times longer, depending how many CPUs your
hardware has.  I haven't noticed any other differences in
functionality.

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

[Rob Emanuele-2]

Do you guys have opinions on how to handle remaps?

For example, on the CFA-735 we have 3 ways of using I2C on the H1
connector.  We expose I2C1 in 2 different ways and a variety of I2C2.

Would you want to call those I2C ids 1 to 3?  Or create a standard
interface for all the I2C ports and variants such as calling them 1 to
4 and then only allow the exposed ones on the board?

I leaning right now to having generic platform setup code and each
interface per board having a set of consts like this included into
platform.c:

static const GPIO_TypeDef* i2c_port_data[] = { GPIOB, GPIOB, GPIOB };
static const I2C_TypeDef* i2cs[] = { I2C1, I2C2, I2C1 };
static const u32 i2c_clks[] = { RCC_APB1Periph_I2C1,
RCC_APB1Periph_I2C2, RCC_APB1Periph_I2C1 };
static const u16 i2c_clock_pin[] = { GPIO_Pin_6, GPIO_Pin_10, GPIO_Pin_8 };
static const u16 i2c_data_pin[] = { GPIO_Pin_7, GPIO_Pin_11, GPIO_Pin_9 };


What I'm struggling with is the best way to mix configuring the chip
used (size, pin count, etc) with how its used (what pins are brought
out, show them all and let the user sort it) and how to overlay that
set details into a coherent and extendible set of configurations.

Last set of thoughts before I pick one mountain and dynamite it into
Mount Rushmore?

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

[Martin Guy]

On 16 February 2012 01:39, Rob Emanuele <[hidden email]> wrote:
> Do you guys have opinions on how to handle remaps?

Can you explain the problem more, as I'm not sure I understand the
problem properly.

What you're saying reminds me of the AVR32 feature whereby each pin of
the chip can be assigned to either be a GPIO pin or to carry one of
three other different signals.
Of, looking at it from each peripheral's point of view, each of its
signals can be programmed to appear on one of several different GPIO
pins. I don't know what happens if you program two of the capable pins
to carry the same signal!

In AVR32 world, the pin-function selection is done when each
peripheral is initialized, either during platform_init() or when its
eLua setup() function is called.  But on the boards we have, the
pin-function selection is defined per board at compile-time, since it
reflects which connectors or other componente the chip package's pins
are connected to.

Is that a similar system to what you're describing? And if so, do you
need to be able to select the function of each pin at runtime? Sory if
I'm being slow to understand, I'm not familiar with your device.

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

[Martin Guy]

As regards enabling clocks at startup, in AVR32, both assigning
functions to pins and enabling clocks is done either during
platform_init() or in the device's eLua setup() function when it is
mandatory to call that before using it. But almost everything does it
during platform_init()

If you wish to delay clock activation until the device is actually
used, I would suggest, for devices where calling a setup() function is
not mandatory, doing the usual (for pwm):
"static pwm_initialized = 0;" then at the start of every entry point
to the module "if (!pwm_initialized) { pwm_setup(); }" where
"pwm_setup() { ... pwm_initialized++; }" or something like that.
That lets you implement it and test it on just your platform without
having to implement it (or stubs of it) on all 12. Of course, if you
want to be able to pwm.disable() as well, then you can't avoid that.

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

[Rob Emanuele-2]

On the STM32 various pins can be GPIOs or a selection of peripheral functions.  In our product, we provide an expansion connector that the end user can use for a host of functions.  We want to provide that selection of functions in eLua.  It is similar to the avr.

On Feb 16, 2012, at 2:08 AM, Martin Guy <[hidden email]> wrote:

> On 16 February 2012 01:39, Rob Emanuele <[hidden email]> wrote:
>> Do you guys have opinions on how to handle remaps?
>
> Can you explain the problem more, as I'm not sure I understand the
> problem properly.
>
> What you're saying reminds me of the AVR32 feature whereby each pin of
> the chip can be assigned to either be a GPIO pin or to carry one of
> three other different signals.
> Of, looking at it from each peripheral's point of view, each of its
> signals can be programmed to appear on one of several different GPIO
> pins. I don't know what happens if you program two of the capable pins
> to carry the same signal!
>
> In AVR32 world, the pin-function selection is done when each
> peripheral is initialized, either during platform_init() or when its
> eLua setup() function is called.  But on the boards we have, the
> pin-function selection is defined per board at compile-time, since it
> reflects which connectors or other componente the chip package's pins
> are connected to.
>
> Is that a similar system to what you're describing? And if so, do you
> need to be able to select the function of each pin at runtime? Sory if
> I'm being slow to understand, I'm not familiar with your device.
>
>    M
> _______________________________________________
> 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

[Martin Guy]

On 16 February 2012 01:39, Rob Emanuele <[hidden email]> wrote:
> Do you guys have opinions on how to handle remaps?
>
> For example, on the CFA-735 we have 3 ways of using I2C on the H1
> connector.  We expose I2C1 in 2 different ways and a variety of I2C2.
>
> Would you want to call those I2C ids 1 to 3?  Or create a standard
> interface for all the I2C ports and variants such as calling them 1 to
> 4 and then only allow the exposed ones on the board?

Yes, I think that would work. I don't think that device IDs are
expected to have the same meanings between boards (except for the IDs
of eLua's virtual devices) so I expect option 1 will work.
AVR32 is worse yet, since it bit-bangs I2C on two GPIO lines so you
could potentially hijack any two random GPIO pins and turn them into
another I2C port. I never expect to support that; I just use the two
pins normally assigned to its one and only TWI controller.

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

[Brent Picasso]

Hello,

I'm working with a custom embedded port of Lua 5.1 and would like to
bring in the LTR patch to reduce memory usage.

I'd like to bring in the patch and experiment by switching one of my
Lua->C function bindings from standard lua_register() to using the LTR
convention.

Is it a matter of bringing in the following files into my lua library,
and re-compiling?

lrodefs.h
lrotable.c
lrotable.h

How deeply is the LTR patch into other parts of the base Lua codebase?

Thank you very much for any help!

Regards,
Brent Picasso
Autosport Labs
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

hi
  The Lua tiny ram patch as applicable to plain lua-5.1.4 is attached

      M

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

[Brent Picasso]

Thank you Martin! I'll let you know how it works out.

On 03/30/2012 06:37 AM, Martin Guy wrote:

hi
  The Lua tiny ram patch as applicable to plain lua-5.1.4 is attached

      M

_______________________________________________
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

[Brent Picasso]

Hi Martin,

I made some progress on enabling LTR in my port.

I got the patch applied and then attempted to register a test function using the instructions here:
http://www.eluaproject.net/doc/v0.8/en_arch_ltr.html

specifically, this code:

const luaR_entry mod_map[] = // note: no static this time
{
  { LRO_STRKEY( "f" ), LRO_FUNCVAL( f_implementation ) },
  { LRO_NILKEY, LRO_NILVAL }
};

// note: in this case the "luaopen_mod" function isn't really needed anymore
LUALIB_API int luaopen_mod( lua_State *L )
{
  return 0;
}

declaring my function this way didn't seem to register it correctly with lua; I felt something was missing. So I dug into the implementation of luaI_openlib().

Inspecting this function I then came up with a way to manually register functions in a 'light' way using the following macro:

#define lua_registerlight(L,n,f) (lua_pushlightfunction(L, (f)), lua_setglobal(L, (n)))

I have about 125 functions registered using the standard lua_register() ; switching to lua_registerlight()  netted me a memory usage savings before LTR of

23K to 13K usage as reported by print(collectgarbage("count")).  About 10K savings.

However, I'm not sure if I'm really using the full capability of the LTR patch.

Is the above approach still using RAM for each function registration? Is there a better way to register my C functions with no memory usage?

Thank you,


On 03/30/2012 06:37 AM, Martin Guy wrote:

hi
  The Lua tiny ram patch as applicable to plain lua-5.1.4 is attached

      M

_______________________________________________
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

[Brent Picasso]

Hi Martin,

Did a bit more digging- looks like the patch you provided didn't contain all of the optimizations described on the elua LTR page.

Specifically, there were quite a few differences in lrotable.c when comparing the patched file to what's currently in the elua project;

for example, the references to enable explicit unions is missing:

/* Return 1 if the given pointer is a rotable */
#ifdef LUA_META_ROTABLES
extern char stext[];
extern char etext[];
int luaR_isrotable(void *p) {
  return stext <= ( char* )p && ( char* )p <= etext;
}
#endif

The patch you provided for lua 5.1.4 - was it just an earlier version, or was it specifically limited for some reason?

Thanks for your help!


On 03/30/2012 03:33 PM, Brent Picasso wrote:

Hi Martin,

I made some progress on enabling LTR in my port.

I got the patch applied and then attempted to register a test function using the instructions here:
http://www.eluaproject.net/doc/v0.8/en_arch_ltr.html

specifically, this code:

const luaR_entry mod_map[] = // note: no static this time
{
  { LRO_STRKEY( "f" ), LRO_FUNCVAL( f_implementation ) },
  { LRO_NILKEY, LRO_NILVAL }
};

// note: in this case the "luaopen_mod" function isn't really needed anymore
LUALIB_API int luaopen_mod( lua_State *L )
{
  return 0;
}

declaring my function this way didn't seem to register it correctly with lua; I felt something was missing. So I dug into the implementation of luaI_openlib().

Inspecting this function I then came up with a way to manually register functions in a 'light' way using the following macro:

#define lua_registerlight(L,n,f) (lua_pushlightfunction(L, (f)), lua_setglobal(L, (n)))

I have about 125 functions registered using the standard lua_register() ; switching to lua_registerlight()  netted me a memory usage savings before LTR of

23K to 13K usage as reported by print(collectgarbage("count")).  About 10K savings.

However, I'm not sure if I'm really using the full capability of the LTR patch.

Is the above approach still using RAM for each function registration? Is there a better way to register my C functions with no memory usage?

Thank you,


On 03/30/2012 06:37 AM, Martin Guy wrote:

hi
  The Lua tiny ram patch as applicable to plain lua-5.1.4 is attached

      M

_______________________________________________
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

[Martin Guy]

hi
  It's the one from here
http://lua-users.org/lists/lua-l/2008-11/msg00331.html

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

[jbsnyder]

On Mon, Apr 2, 2012 at 12:29 PM, Brent Picasso <[hidden email]> wrote:

> Hi Martin,
>
> Did a bit more digging- looks like the patch you provided didn't contain all
> of the optimizations described on the elua LTR page.
>
> Specifically, there were quite a few differences in lrotable.c when
> comparing the patched file to what's currently in the elua project;
>
> for example, the references to enable explicit unions is missing:
>
> /* Return 1 if the given pointer is a rotable */
> #ifdef LUA_META_ROTABLES
> extern char stext[];
> extern char etext[];
> int luaR_isrotable(void *p) {
>   return stext <= ( char* )p && ( char* )p <= etext;
> }
> #endif
>
> The patch you provided for lua 5.1.4 - was it just an earlier version, or
> was it specifically limited for some reason?

The patch that was posted on the mailing list differs from what's now
in our main repository.  I'm not sure if there's a convenient
broken-out version of of what's currently applied.  Bogdan might be
able to answer that one.

If someone does manage to collect this, I'd be appreciative if it gets
posted to the list as I wouldn't mind putting it on a branch on my Lua
mirror repository:
https://github.com/jsnyder/lua

>
> Thanks for your help!
>
>
> Brent Picasso
> Autosport Labs
> Technology for Race and Street
> autosportlabs.com | twitter.com/AutosportLabs
>
> On 03/30/2012 03:33 PM, Brent Picasso wrote:
>
> Hi Martin,
>
> I made some progress on enabling LTR in my port.
>
> I got the patch applied and then attempted to register a test function using
> the instructions here:
> http://www.eluaproject.net/doc/v0.8/en_arch_ltr.html
>
> specifically, this code:
>
> const luaR_entry mod_map[] = // note: no static this time
> {
>   { LRO_STRKEY( "f" ), LRO_FUNCVAL( f_implementation ) },
>   { LRO_NILKEY, LRO_NILVAL }
> };
>
> // note: in this case the "luaopen_mod" function isn't really needed anymore
> LUALIB_API int luaopen_mod( lua_State *L )
> {
>   return 0;
> }
>
> declaring my function this way didn't seem to register it correctly with
> lua; I felt something was missing. So I dug into the implementation of
> luaI_openlib().
>
> Inspecting this function I then came up with a way to manually register
> functions in a 'light' way using the following macro:
>
> #define lua_registerlight(L,n,f) (lua_pushlightfunction(L, (f)),
> lua_setglobal(L, (n)))
>
> I have about 125 functions registered using the standard lua_register() ;
> switching to lua_registerlight()  netted me a memory usage savings before
> LTR of
>
> 23K to 13K usage as reported by print(collectgarbage("count")).  About 10K
> savings.
>
> However, I'm not sure if I'm really using the full capability of the LTR
> patch.
>
> Is the above approach still using RAM for each function registration? Is
> there a better way to register my C functions with no memory usage?
>
> Thank you,
>
> Brent Picasso
> Autosport Labs
> Technology for Race and Street
> autosportlabs.com | twitter.com/AutosportLabs
>
> On 03/30/2012 06:37 AM, Martin Guy wrote:
>
> hi
>   The Lua tiny ram patch as applicable to plain lua-5.1.4 is attached
>
>       M
>
>
>
> _______________________________________________
> 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: [phone]
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev