Preprocessor Stuff

[jbsnyder]

Yeah, so far I am running the flash tool in a VM :(

I have gotten OpenOCD to burn something to flash on the board, but unfortunately, so far, it doesn't seem to start up after I reset the board.  I'm going to continue to mess around with it to see if I can get it working.  OpenOCD at least supposedly supports this board for flashing.  The debug stuff seems to work OK (though I've not tested it extensively).  I'll post something if I manage to get another solution working.

I wouldn't say that the port is really broken, more just that I think a few things like that if statement an define aren't.

I've attached some patches for updated lm3s driver libraries, which seem to have allowed the OLED display to work on my device.  The "piano" application still makes no sound at the moment, and so I'm still investigating that.

One quick question Fred:  what terminal program were you using on the Mac?  Were you using minicom?  I've tried kermit, screen and a few other things.  I've found that it's difficult to get the terminal settings quite right, it doesn't do carriage returns in all cases which results in the prompt moving towards the right side of the screen if one keeps hitting enter.  Any ideas?

Is anyone on the dev team familiar with git?  I've checked out the eLua repo using git svn, and I might throw up my branch to GitHub just so that I have an online location where I can access things from multiple machines.  It would also make it easy to show changes to you guys without having commit access.  Would that be OK?

-jsnyder

----- Original Message -----
From: "Fr?d?ric Thomas" <berlios.de at thomascorner.com>
To: "eLua development list" <elua-dev at lists.berlios.de>
Sent: Wednesday, January 7, 2009 6:11:34 AM GMT -06:00 US/Canada Central
Subject: Re: [eLua-dev] Preprocessor Stuff

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: [phone]
>
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: elua-lm3s-driverlibupdate.patch.gz
Type: application/x-gzip
Size: 15087 bytes
Desc: not available
Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090107/7bff3e0e/attachment-0001.gz 

[BogdanM]

On Wed, Jan 7, 2009 at 4:21 PM, James Snyder <jbsnyder at fanplastic.org>wrote:

> Yeah, so far I am running the flash tool in a VM :(


Have you two checked the LM3S forums? I think I saw people there that used
OpenOCD to flash LM3S chips, and maybe even some scripts (although my
memories in this area could be fuzzy).

I have gotten OpenOCD to burn something to flash on the board, but
> unfortunately, so far, it doesn't seem to start up after I reset the board.
>  I'm going to continue to mess around with it to see if I can get it
> working.


Weird. Did you read back the flash to make sure that it was written
correctly?


> I wouldn't say that the port is really broken, more just that I think a few
> things like that if statement an define aren't.


Agreed.


> I've attached some patches for updated lm3s driver libraries, which seem to
> have allowed the OLED display to work on my device.  The "piano" application
> still makes no sound at the moment, and so I'm still investigating that.


Will take a look just after I clear up some of the mess around here and
commit some stuff.


> One quick question Fred:  what terminal program were you using on the Mac?
>  Were you using minicom?  I've tried kermit, screen and a few other things.
>  I've found that it's difficult to get the terminal settings quite right, it
> doesn't do carriage returns in all cases which results in the prompt moving
> towards the right side of the screen if one keeps hitting enter.  Any ideas?


This is a real tough one. One of the main reasons I still use Windows as my
primary OS is that I have TeraTerm there, and so far nothin beats it. I
don't know about Mac, but I wasn't able to find a suitable terminal emulator
even under Linux.


> Is anyone on the dev team familiar with git?  I've checked out the eLua
> repo using git svn, and I might throw up my branch to GitHub just so that I
> have an online location where I can access things from multiple machines.
>  It would also make it easy to show changes to you guys without having
> commit access.  Would that be OK?


I am vaguely familiar with GIT; I read some small tutorials and I like the
idea, although I never used it.
As for the other repo, it will be OK if you use it in read-only mode,
otherwise not so OK, as I'm trying to avoid code forking as much as
possible.
I'm curious, although a bit OT: do you prefer GIT over SVN or the other way
around?

Best,
Bogdan

>
>
> -jsnyder
>
> ----- Original Message -----
> From: "Fr?d?ric Thomas" <berlios.de at thomascorner.com>
> To: "eLua development list" <elua-dev at lists.berlios.de>
> Sent: Wednesday, January 7, 2009 6:11:34 AM GMT -06:00 US/Canada Central
> Subject: Re: [eLua-dev] Preprocessor Stuff
>
> 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: [phone]
> >
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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/decad06f/attachment.html 

[Frédéric THOMAS-5]

> One quick question Fred:  what terminal program were you using on  
> the Mac?  Were you using minicom?  I've tried kermit, screen and a  
> few other things.  I've found that it's difficult to get the  
> terminal settings quite right, it doesn't do carriage returns in all  
> cases which results in the prompt moving towards the right side of  
> the screen if one keeps hitting enter.  Any ideas?

Heh, I was using HyperTerminal since I could not manage to get the  
FTDI/OpenOCD/Eclipse stuff to work on the Mac side :)

For the CRLF issue, I guess one way to fix it would be to add these in  
the eLua code, no ?

Fred

[BogdanM]

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

> > One quick question Fred:  what terminal program were you using on
> > the Mac?  Were you using minicom?  I've tried kermit, screen and a
> > few other things.  I've found that it's difficult to get the
> > terminal settings quite right, it doesn't do carriage returns in all
> > cases which results in the prompt moving towards the right side of
> > the screen if one keeps hitting enter.  Any ideas?
>
> Heh, I was using HyperTerminal since I could not manage to get the
> FTDI/OpenOCD/Eclipse stuff to work on the Mac side :)

For the CRLF issue, I guess one way to fix it would be to add these in
> the eLua code, no ?


Currently, eLua completely ignores CR chars on input and considers NL chars
as line ends. This takes care of both DOS/Windows (CR/LF) and Unix (LF). I
don't know about Mac, but I'm quite sure that a terminal emulation program
should give the user an option to set his line endings.

Best,
Bogdan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090107/32cc4185/attachment-0001.html 

[Frédéric THOMAS-5]

> Currently, eLua completely ignores CR chars on input and considers  
> NL chars as line ends. This takes care of both DOS/Windows (CR/LF)  
> and Unix (LF). I don't know about Mac, but I'm quite sure that a  
> terminal emulation program should give the user an option to set his  
> line endings.

IMHO:

eLua should send CR + LF when it means "move the cursor one line down  
and to the leftmost column" because this is how a real printer did  
work historically, and therefore the proper way to do it according to  
most terminal type standards (including telnet, 3270, etc). The  
(arbitrary) choice of line ending supported by the client OS should  
not matter.

Most terminal programs give the choice of what to SEND when return is  
pressed. Few have the option to replace incoming CR or LF or  
combination thereof into the appropriate line ending for the platform,  
because IMHO such an option would be likely to interfere with any  
rudimentary "ANSI graphics" or "special effects" the host would try to  
perform.

A good serial program for the Mac is ZTerm. Has not been updated in  
years, but neither did serial communications :)

Fred

[BogdanM]

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

> > Currently, eLua completely ignores CR chars on input and considers
> > NL chars as line ends. This takes care of both DOS/Windows (CR/LF)
> > and Unix (LF). I don't know about Mac, but I'm quite sure that a
> > terminal emulation program should give the user an option to set his
> > line endings.
>
> IMHO:
>
> eLua should send CR + LF when it means "move the cursor one line down
> and to the leftmost column" because this is how a real printer did
> work historically, and therefore the proper way to do it according to
> most terminal type standards (including telnet, 3270, etc). The
> (arbitrary) choice of line ending supported by the client OS should
> not matter.

As explained, this behaviour applies to the *input *part*. *What I didn't
explain is that on *output* every NL char is automatically prepended with a
CR char, for the exact same reasons you enumerated here.

Best,
Bogdan


> _______________________________________________
> 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/98ed7906/attachment.html