eLua Development

Preprocessor Stuff

Classic

List

Threaded

10 messages Options

jbsnyder

Preprocessor Stuff

Hi -

I've got the toolchain up and running on a Mac, most of the
instructions worked fine for me with the one exception that (unlike on
a Linux machine I'd tried before) for the steps where an autoconf was
called for, doing so actually didn't go quite right and resulted in
the configure scripts not recognizing many of the options being
enabled. Luckily, things seem to build OK with the out-of-the-box
configure scripts with the latest versions of the libraries required.

My real reason for making this post, however, is related to the build
process and in particular how things are handled by the preprocessor.
I was trying to make a patch for the lm3s platform files so that
another type of display (the OSRAM type OLED display, which I later
realized isn't actually on my Rev C LM3S6965) could be used. When I
was trying to use some if blocks so that display support could switch
between the RIT and OSRAM types, I noticed that the if statements
didn't seem to work as expected. with ELUA_CPU and ELUA_BOARD for
example. An easy way to demonstrate this is to run the preprocessor
on platform.c in the lm3s platform folder. In advance, I'll point out
that the following lines are found within:

#if ELUA_CPU == LM3S8962
#define UARTS_COUNT 2
#elif ELUA_CPU == LM3S6965
#define UARTS_COUNT 3
#endif

and as well, look at the function uarts_init(), which contains the line:

for( i = 0; i < UARTS_COUNT; i ++ )

If I run the preprocessor with -DELUA_CPU= LM3S6965 I would expect
the UARTS_COUNT in the line from uarts_init() to be replaced with the
number 3, but this is not what I get.

If I run the following: arm-elf-cpp -DELUA_CPU=LM3S6965 platform.c |
less

and then locate the same for loop, instead I see:

for( i = 0; i < 2; i ++ )

Is this handled correctly with a different compiler preprocessor? I'm
using GCC 4.3.2, which I compiled per the instructions on the eLua
site. Having looked at the documentation for the gcc preprocessor, I
don't think this would be expected to work either. using the gcc -D
flags with numbers definitely works, but these tokens for the
different platforms doesn't, at least for me.

I would make a patch for some sort of fix, but I figured I'd touch
base first.

Love the project, and it runs great on my LM3S6965 :-)

Best.

P.S. I was also really really happy to see an ls command added since
the 0.5 release.

--
James Snyder
Biomedical Engineering
Northwestern University
jbsnyder at fanplastic.org
http://fanplastic.org/key.txt
ph: (847) 644-2322

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

jbsnyder

Preprocessor Stuff

Just looked at the commit log. I see this is being adjusted in other
places. What would be the standard fix for this sort of thing?
Should it just be an ifdef for LM3S6965 instead?

Also, the display module doesn't seem to start up correctly on my
LM3S6965 when I run the pong application. on disp.init I can see the
last image that was displayed very dimly, but it doesn't seem to come
fully on or allow writing new things. I'm trying to see if maybe
something in the driver lib has changed since the versions in eLua in
case that might make the difference...

-jsnyder

On Jan 6, 2009, at 4:58 PM, James Snyder wrote:

> Hi -
>
> I've got the toolchain up and running on a Mac, most of the
> instructions worked fine for me with the one exception that (unlike
> on a Linux machine I'd tried before) for the steps where an autoconf
> was called for, doing so actually didn't go quite right and resulted
> in the configure scripts not recognizing many of the options being
> enabled. Luckily, things seem to build OK with the out-of-the-box
> configure scripts with the latest versions of the libraries required.
>
> My real reason for making this post, however, is related to the
> build process and in particular how things are handled by the
> preprocessor. I was trying to make a patch for the lm3s platform
> files so that another type of display (the OSRAM type OLED display,
> which I later realized isn't actually on my Rev C LM3S6965) could be
> used. When I was trying to use some if blocks so that display
> support could switch between the RIT and OSRAM types, I noticed that
> the if statements didn't seem to work as expected. with ELUA_CPU and
> ELUA_BOARD for example. An easy way to demonstrate this is to run
> the preprocessor on platform.c in the lm3s platform folder. In
> advance, I'll point out that the following lines are found within:
>
> #if ELUA_CPU == LM3S8962
> #define UARTS_COUNT 2
> #elif ELUA_CPU == LM3S6965
> #define UARTS_COUNT 3
> #endif
>
> and as well, look at the function uarts_init(), which contains the
> line:
>
> for( i = 0; i < UARTS_COUNT; i ++ )
>
> If I run the preprocessor with -DELUA_CPU= LM3S6965 I would expect
> the UARTS_COUNT in the line from uarts_init() to be replaced with
> the number 3, but this is not what I get.
>
> If I run the following: arm-elf-cpp -DELUA_CPU=LM3S6965 platform.c |
> less
>
> and then locate the same for loop, instead I see:
>
> for( i = 0; i < 2; i ++ )
>
> Is this handled correctly with a different compiler preprocessor?
> I'm using GCC 4.3.2, which I compiled per the instructions on the
> eLua site. Having looked at the documentation for the gcc
> preprocessor, I don't think this would be expected to work either.
> using the gcc -D flags with numbers definitely works, but these
> tokens for the different platforms doesn't, at least for me.
>
> I would make a patch for some sort of fix, but I figured I'd touch
> base first.
>
> Love the project, and it runs great on my LM3S6965 :-)
>
> Best.
>
>
> P.S. I was also really really happy to see an ls command added since
> the 0.5 release.
>
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> jbsnyder at fanplastic.org
> http://fanplastic.org/key.txt
> ph: (847) 644-2322
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev

--
James Snyder
Biomedical Engineering
Northwestern University
jbsnyder at fanplastic.org
http://fanplastic.org/key.txt
ph: (847) 644-2322

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

Dado Sutter

Preprocessor Stuff

In reply to this post by jbsnyder

Hello,

On Tue, Jan 6, 2009 at 20:58, James Snyder <jbsnyder at fanplastic.org> wrote:

> Hi -
> I've got the toolchain up and running on a Mac, most of the instructions
> worked fine for me with the one exception that (unlike on a Linux machine
> I'd tried before) for the steps where an autoconf was called for, doing so
> actually didn't go quite right and resulted in the configure scripts not
> recognizing many of the options being enabled. Luckily, things seem to
> build OK with the out-of-the-box configure scripts with the latest versions
> of the libraries required.
>

Thanks for the report !

> My real reason for making this post, however, is related to the build
> process and in particular how things are handled by the preprocessor. I was
> trying to make a patch for the lm3s platform files so that another type of
> display (the OSRAM type OLED display, which I later realized isn't actually
> on my Rev C LM3S6965) could be used. When I was trying to use some if
> blocks so that display support could switch between the RIT and OSRAM types,
> I noticed that the if statements didn't seem to work as expected. with
> ELUA_CPU and ELUA_BOARD for example. An easy way to demonstrate this is to
> run the preprocessor on platform.c in the lm3s platform folder. In advance,
> I'll point out that the following lines are found within:
>
> #if ELUA_CPU == LM3S8962
> #define UARTS_COUNT 2
> #elif ELUA_CPU == LM3S6965
> #define UARTS_COUNT 3
> #endif
>
> and as well, look at the function uarts_init(), which contains the line:
>
> for( i = 0; i < UARTS_COUNT; i ++ )
>
> If I run the preprocessor with -DELUA_CPU= LM3S6965 I would expect the
> UARTS_COUNT in the line from uarts_init() to be replaced with the number 3,
> but this is not what I get.
>
> If I run the following: arm-elf-cpp -DELUA_CPU=LM3S6965 platform.c | less
>
> and then locate the same for loop, instead I see:
>
> for( i = 0; i < 2; i ++ )
>

This seems to be a typing error sorry :(
The #elif ELUA_CPU == LM3S6965 should be #elif ELUA_CPU == LM3S*8*965
My LM kit has an LM3S8962 so I've actually never tried to run the image :(

Is this handled correctly with a different compiler preprocessor? I'm using
> GCC 4.3.2, which I compiled per the instructions on the eLua site. Having
> looked at the documentation for the gcc preprocessor, I don't think this
> would be expected to work either. using the gcc -D flags with numbers
> definitely works, but these tokens for the different platforms doesn't, at
> least for me.
>

Hopefully it is not a GCC problem.

> I would make a patch for some sort of fix, but I figured I'd touch base
> first.
>
> Love the project, and it runs great on my LM3S6965 :-)
>

So nice to hear that !!!!!! :)

>
> Best.
>
>
> P.S. I was also really really happy to see an ls command added since the
> 0.5 release.
>

Thanks again :) It is hard to make a code contribution when we have Bogan
coding furiously :-o :) :)

Best
Dado

>
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> jbsnyder at fanplastic.org
> http://fanplastic.org/key.txt
> ph: (847) 644-2322
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

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

Dado Sutter

Preprocessor Stuff

On Tue, Jan 6, 2009 at 22:13, Dado Sutter <dadosutter at gmail.com> wrote:

> Hello,
> This seems to be a typing error sorry :(
> The #elif ELUA_CPU == LM3S6965 should be #elif ELUA_CPU == LM3S*8*965
> My LM kit has an LM3S8962 so I've actually never tried to run the image
> :(
>

Oooops, bad guess :(

Best
Dado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090106/c07828d1/attachment.html

jbsnyder

Preprocessor Stuff

In reply to this post by Dado Sutter

On Jan 6, 2009, at 6:13 PM, Dado Sutter wrote:

>
> My real reason for making this post, however, is related to the
> build process and in particular how things are handled by the
> preprocessor. I was trying to make a patch for the lm3s platform
> files so that another type of display (the OSRAM type OLED display,
> which I later realized isn't actually on my Rev C LM3S6965) could be
> used. When I was trying to use some if blocks so that display
> support could switch between the RIT and OSRAM types, I noticed that
> the if statements didn't seem to work as expected. with ELUA_CPU and
> ELUA_BOARD for example. An easy way to demonstrate this is to run
> the preprocessor on platform.c in the lm3s platform folder. In
> advance, I'll point out that the following lines are found within:
>
> #if ELUA_CPU == LM3S8962
> #define UARTS_COUNT 2
> #elif ELUA_CPU == LM3S6965
> #define UARTS_COUNT 3
> #endif
>
> and as well, look at the function uarts_init(), which contains the
> line:
>
> for( i = 0; i < UARTS_COUNT; i ++ )
>
> If I run the preprocessor with -DELUA_CPU= LM3S6965 I would expect
> the UARTS_COUNT in the line from uarts_init() to be replaced with
> the number 3, but this is not what I get.
>
> If I run the following: arm-elf-cpp -DELUA_CPU=LM3S6965 platform.c |
> less
>
> and then locate the same for loop, instead I see:
>
> for( i = 0; i < 2; i ++ )
>
> This seems to be a typing error sorry :(
> The #elif ELUA_CPU == LM3S6965 should be #elif ELUA_CPU == LM3S8965
> My LM kit has an LM3S8962 so I've actually never tried to run the
> image :(

Actually the 6 is correct, at least as far as what is written on my
chip :-)

Judging from some other commits by Bogdan, I think he's encountering
the same issue as well, e.g.:

commit message: fix yet another preprocessor error
--- a/src/newlib/stubs.c
+++ b/src/newlib/stubs.c
@@ -394,7 +394,7 @@ DM_DEVICE* std_get_desc()

#endif // #if !defined( BUILD_CON_GENERIC ) && !
defined( BUILD_CON_TCP )

-#if ELUA_PLATFORM == AVR32
+#ifdef AVR32
void* memcpy( void *dst, const void* src, size_t len )
{
char *pdest = ( char* )dst;

I have since also gotten the display working on my 6965. I basically
just updated all the driver library stuff from luminary, and tried to
keep any of what looked like modifications for eLua consistent (the
usart library, for example, had a function that returns void in the
current driver lib, so I modified it to merge the luminary updates,
while presumably keeping the function behaving as before). I'll be
happy to submit it all as a patch, but it is a bunch of files ;-)

--
James Snyder
Biomedical Engineering
Northwestern University
jbsnyder at fanplastic.org
http://fanplastic.org/key.txt
ph: (847) 644-2322

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

Dado Sutter

Preprocessor Stuff

In reply to this post by jbsnyder

Dear James,
The disp module was written to allow us to test some driver integration
techniques (and to play Pong !!! :) but pls note it is not in it's final
form and the Lua functions are not generic enough to deserve to form an eLua
Module yet.
But yes, it works fine in our LM3S8962 and I would like to help you make
it work on the LM3S6965. I need to check how (and if) the lib code is
adapted to each model but it should be the same.
We are not planning to release the disp module (at least not the way it
is) in the next version. But I've been doing some tests with "platform
dependent modules", that would expose devices and some utility functions,
specifically to a known board (ex: buttons, speaker, leds, the oled,
......).
I don't remember now if it is on trunk (and I should :-o) but the very
last version of Pong I wrote, does a *require("LM3S")* in Lua, to include
this "platform dependend module" and to ilustrate require() use in eLua.

Best
Dado

On Tue, Jan 6, 2009 at 21:52, James Snyder <jbsnyder at fanplastic.org> wrote:

> Just looked at the commit log. I see this is being adjusted in other
> places. What would be the standard fix for this sort of thing? Should it
> just be an ifdef for LM3S6965 instead?
> Also, the display module doesn't seem to start up correctly on my LM3S6965
> when I run the pong application. on disp.init I can see the last image that
> was displayed very dimly, but it doesn't seem to come fully on or allow
> writing new things. I'm trying to see if maybe something in the driver lib
> has changed since the versions in eLua in case that might make the
> difference...
>
> -jsnyder
>
> On Jan 6, 2009, at 4:58 PM, James Snyder wrote:
>
> Hi -
> I've got the toolchain up and running on a Mac, most of the instructions
> worked fine for me with the one exception that (unlike on a Linux machine
> I'd tried before) for the steps where an autoconf was called for, doing so
> actually didn't go quite right and resulted in the configure scripts not
> recognizing many of the options being enabled. Luckily, things seem to
> build OK with the out-of-the-box configure scripts with the latest versions
> of the libraries required.
>
> My real reason for making this post, however, is related to the build
> process and in particular how things are handled by the preprocessor. I was
> trying to make a patch for the lm3s platform files so that another type of
> display (the OSRAM type OLED display, which I later realized isn't actually
> on my Rev C LM3S6965) could be used. When I was trying to use some if
> blocks so that display support could switch between the RIT and OSRAM types,
> I noticed that the if statements didn't seem to work as expected. with
> ELUA_CPU and ELUA_BOARD for example. An easy way to demonstrate this is to
> run the preprocessor on platform.c in the lm3s platform folder. In advance,
> I'll point out that the following lines are found within:
>
> #if ELUA_CPU == LM3S8962
> #define UARTS_COUNT 2
> #elif ELUA_CPU == LM3S6965
> #define UARTS_COUNT 3
> #endif
>
> and as well, look at the function uarts_init(), which contains the line:
>
> for( i = 0; i < UARTS_COUNT; i ++ )
>
> If I run the preprocessor with -DELUA_CPU= LM3S6965 I would expect the
> UARTS_COUNT in the line from uarts_init() to be replaced with the number 3,
> but this is not what I get.
>
> If I run the following: arm-elf-cpp -DELUA_CPU=LM3S6965 platform.c | less
>
> and then locate the same for loop, instead I see:
>
> for( i = 0; i < 2; i ++ )
>
> Is this handled correctly with a different compiler preprocessor? I'm
> using GCC 4.3.2, which I compiled per the instructions on the eLua site.
> Having looked at the documentation for the gcc preprocessor, I don't think
> this would be expected to work either. using the gcc -D flags with numbers
> definitely works, but these tokens for the different platforms doesn't, at
> least for me.
>
> I would make a patch for some sort of fix, but I figured I'd touch base
> first.
>
> Love the project, and it runs great on my LM3S6965 :-)
>
> Best.
>
>
> P.S. I was also really really happy to see an ls command added since the
> 0.5 release.
>
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> jbsnyder at fanplastic.org
> http://fanplastic.org/key.txt
> ph: (847) 644-2322
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> jbsnyder at fanplastic.org
> http://fanplastic.org/key.txt
> ph: (847) 644-2322
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

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

BogdanM

Preprocessor Stuff

In reply to this post by jbsnyder

Hi,

This is a mistake I keep making with the C preprocessor, I'll fix it as soon
as possible. We need to define macros like LM3S8962 and test #ifdef LM3S8962
instead.

Best,
Bogdan

On Wed, Jan 7, 2009 at 12:58 AM, James Snyder <jbsnyder at fanplastic.org>wrote:

> Hi -
> I've got the toolchain up and running on a Mac, most of the instructions
> worked fine for me with the one exception that (unlike on a Linux machine
> I'd tried before) for the steps where an autoconf was called for, doing so
> actually didn't go quite right and resulted in the configure scripts not
> recognizing many of the options being enabled. Luckily, things seem to
> build OK with the out-of-the-box configure scripts with the latest versions
> of the libraries required.
>
> My real reason for making this post, however, is related to the build
> process and in particular how things are handled by the preprocessor. I was
> trying to make a patch for the lm3s platform files so that another type of
> display (the OSRAM type OLED display, which I later realized isn't actually
> on my Rev C LM3S6965) could be used. When I was trying to use some if
> blocks so that display support could switch between the RIT and OSRAM types,
> I noticed that the if statements didn't seem to work as expected. with
> ELUA_CPU and ELUA_BOARD for example. An easy way to demonstrate this is to
> run the preprocessor on platform.c in the lm3s platform folder. In advance,
> I'll point out that the following lines are found within:
>
> #if ELUA_CPU == LM3S8962
> #define UARTS_COUNT 2
> #elif ELUA_CPU == LM3S6965
> #define UARTS_COUNT 3
> #endif
>
> and as well, look at the function uarts_init(), which contains the line:
>
> for( i = 0; i < UARTS_COUNT; i ++ )
>
> If I run the preprocessor with -DELUA_CPU= LM3S6965 I would expect the
> UARTS_COUNT in the line from uarts_init() to be replaced with the number 3,
> but this is not what I get.
>
> If I run the following: arm-elf-cpp -DELUA_CPU=LM3S6965 platform.c | less
>
> and then locate the same for loop, instead I see:
>
> for( i = 0; i < 2; i ++ )
>
> Is this handled correctly with a different compiler preprocessor? I'm
> using GCC 4.3.2, which I compiled per the instructions on the eLua site.
> Having looked at the documentation for the gcc preprocessor, I don't think
> this would be expected to work either. using the gcc -D flags with numbers
> definitely works, but these tokens for the different platforms doesn't, at
> least for me.
>
> I would make a patch for some sort of fix, but I figured I'd touch base
> first.
>
> Love the project, and it runs great on my LM3S6965 :-)
>
> Best.
>
>
> P.S. I was also really really happy to see an ls command added since the
> 0.5 release.
>
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> jbsnyder at fanplastic.org
> http://fanplastic.org/key.txt
> ph: (847) 644-2322
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

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

BogdanM

Preprocessor Stuff

...and by the way, this isn't completely true :) When I did -DAVR32 for the
AVR32 fix, I ran /rom/info.lua, and I had the surprise to learn that I'm
running on the platform called "1" instead of AVR32 :) (this is because of
the way the PD module is built). You should use a descriptive name that is
not the CPU or the platform name. The current fix for this (which I didn't
have a chance to commit yet) is to do -D*FOR*AVR32 instead, and test for
this.

Best,
Bogdan

On Wed, Jan 7, 2009 at 9:54 AM, Bogdan Marinescu <bogdan.marinescu at gmail.com
> wrote:

> Hi,
>
> This is a mistake I keep making with the C preprocessor, I'll fix it as
> soon as possible. We need to define macros like LM3S8962 and test #ifdef
> LM3S8962 instead.
>
> Best,
> Bogdan
>
> On Wed, Jan 7, 2009 at 12:58 AM, James Snyder <jbsnyder at fanplastic.org>wrote:
>
>> Hi -
>> I've got the toolchain up and running on a Mac, most of the instructions
>> worked fine for me with the one exception that (unlike on a Linux machine
>> I'd tried before) for the steps where an autoconf was called for, doing so
>> actually didn't go quite right and resulted in the configure scripts not
>> recognizing many of the options being enabled. Luckily, things seem to
>> build OK with the out-of-the-box configure scripts with the latest versions
>> of the libraries required.
>>
>> My real reason for making this post, however, is related to the build
>> process and in particular how things are handled by the preprocessor. I was
>> trying to make a patch for the lm3s platform files so that another type of
>> display (the OSRAM type OLED display, which I later realized isn't actually
>> on my Rev C LM3S6965) could be used. When I was trying to use some if
>> blocks so that display support could switch between the RIT and OSRAM types,
>> I noticed that the if statements didn't seem to work as expected. with
>> ELUA_CPU and ELUA_BOARD for example. An easy way to demonstrate this is to
>> run the preprocessor on platform.c in the lm3s platform folder. In advance,
>> I'll point out that the following lines are found within:
>>
>> #if ELUA_CPU == LM3S8962
>> #define UARTS_COUNT 2
>> #elif ELUA_CPU == LM3S6965
>> #define UARTS_COUNT 3
>> #endif
>>
>> and as well, look at the function uarts_init(), which contains the line:
>>
>> for( i = 0; i < UARTS_COUNT; i ++ )
>>
>> If I run the preprocessor with -DELUA_CPU= LM3S6965 I would expect the
>> UARTS_COUNT in the line from uarts_init() to be replaced with the number 3,
>> but this is not what I get.
>>
>> If I run the following: arm-elf-cpp -DELUA_CPU=LM3S6965 platform.c | less
>>
>> and then locate the same for loop, instead I see:
>>
>> for( i = 0; i < 2; i ++ )
>>
>> Is this handled correctly with a different compiler preprocessor? I'm
>> using GCC 4.3.2, which I compiled per the instructions on the eLua site.
>> Having looked at the documentation for the gcc preprocessor, I don't think
>> this would be expected to work either. using the gcc -D flags with numbers
>> definitely works, but these tokens for the different platforms doesn't, at
>> least for me.
>>
>> I would make a patch for some sort of fix, but I figured I'd touch base
>> first.
>>
>> Love the project, and it runs great on my LM3S6965 :-)
>>
>> Best.
>>
>>
>> P.S. I was also really really happy to see an ls command added since the
>> 0.5 release.
>>
>> --
>> James Snyder
>> Biomedical Engineering
>> Northwestern University
>> jbsnyder at fanplastic.org
>> http://fanplastic.org/key.txt
>> ph: (847) 644-2322
>>
>>
>> _______________________________________________
>> Elua-dev mailing list
>> Elua-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>>
>

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

Frédéric THOMAS-5

Preprocessor Stuff

In reply to this post by jbsnyder

Hi there,

I did the early LM3S6965 port using a Mac built toolchain, and it used
to work. That was 6 months ago however, and I have not maintained it.
In the meantime, toolchain components certainly changed, and eLua as
well. No display nor ethernet support back then.

James, I am curious as to how you send your code to the board using
the Mac ? The only reliable method I had was to use the Luminary tool
under Windows (in a VM) :(

Fred

On Jan 6, 2009, at 23:58 , James Snyder wrote:

BogdanM

Preprocessor Stuff

Yes, it worked just fine when you wrote it. It stopped doing so after I
"optimized" it :)

Best,
Bogdan

On Wed, Jan 7, 2009 at 2:11 PM, Fr?d?ric Thomas <berlios.de at thomascorner.com
> wrote:

> Hi there,
>
> I did the early LM3S6965 port using a Mac built toolchain, and it used
> to work. That was 6 months ago however, and I have not maintained it.
> In the meantime, toolchain components certainly changed, and eLua as
> well. No display nor ethernet support back then.
>
> James, I am curious as to how you send your code to the board using
> the Mac ? The only reliable method I had was to use the Luminary tool
> under Windows (in a VM) :(
>
> Fred
>
>
> On Jan 6, 2009, at 23:58 , James Snyder wrote:
>
> > Hi -
> >
> > I've got the toolchain up and running on a Mac, most of the
> > instructions worked fine for me with the one exception that (unlike
> > on a Linux machine I'd tried before) for the steps where an autoconf
> > was called for, doing so actually didn't go quite right and resulted
> > in the configure scripts not recognizing many of the options being
> > enabled. Luckily, things seem to build OK with the out-of-the-box
> > configure scripts with the latest versions of the libraries required.
> >
> > My real reason for making this post, however, is related to the
> > build process and in particular how things are handled by the
> > preprocessor. I was trying to make a patch for the lm3s platform
> > files so that another type of display (the OSRAM type OLED display,
> > which I later realized isn't actually on my Rev C LM3S6965) could be
> > used. When I was trying to use some if blocks so that display
> > support could switch between the RIT and OSRAM types, I noticed that
> > the if statements didn't seem to work as expected. with ELUA_CPU and
> > ELUA_BOARD for example. An easy way to demonstrate this is to run
> > the preprocessor on platform.c in the lm3s platform folder. In
> > advance, I'll point out that the following lines are found within:
> >
> > #if ELUA_CPU == LM3S8962
> > #define UARTS_COUNT 2
> > #elif ELUA_CPU == LM3S6965
> > #define UARTS_COUNT 3
> > #endif
> >
> > and as well, look at the function uarts_init(), which contains the
> > line:
> >
> > for( i = 0; i < UARTS_COUNT; i ++ )
> >
> > If I run the preprocessor with -DELUA_CPU= LM3S6965 I would expect
> > the UARTS_COUNT in the line from uarts_init() to be replaced with
> > the number 3, but this is not what I get.
> >
> > If I run the following: arm-elf-cpp -DELUA_CPU=LM3S6965 platform.c |
> > less
> >
> > and then locate the same for loop, instead I see:
> >
> > for( i = 0; i < 2; i ++ )
> >
> > Is this handled correctly with a different compiler preprocessor?
> > I'm using GCC 4.3.2, which I compiled per the instructions on the
> > eLua site. Having looked at the documentation for the gcc
> > preprocessor, I don't think this would be expected to work either.
> > using the gcc -D flags with numbers definitely works, but these
> > tokens for the different platforms doesn't, at least for me.
> >
> > I would make a patch for some sort of fix, but I figured I'd touch
> > base first.
> >
> > Love the project, and it runs great on my LM3S6965 :-)
> >
> > Best.
> >
> >
> > P.S. I was also really really happy to see an ls command added since
> > the 0.5 release.
> >
> > --
> > James Snyder
> > Biomedical Engineering
> > Northwestern University
> > jbsnyder at fanplastic.org
> > http://fanplastic.org/key.txt
> > ph: (847) 644-2322
> >
> > _______________________________________________
> > Elua-dev mailing list
> > Elua-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/elua-dev
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>

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