Dado Sutter |
On Sun, Mar 13, 2011 at 08:57, Nuccio Raciti <[hidden email]> wrote: Hi Bogdan, For projects and code forked from other repos, please take a look on github's concept of "Pull Request" at http://help.github.com/pull-requests/ Nuccio Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Nuccio Raciti |
good, thanks.
Il giorno dom, 13/03/2011 alle 10.25 -0300, Dado Sutter ha scritto: > > > On Sun, Mar 13, 2011 at 08:57, Nuccio Raciti <[hidden email]> > wrote: > Hi Bogdan, > > I made the GitHub fork, now a my project > https://github.com/nuccioraciti/eLuaWebServer > is there. > > Regarding the network support for AVR32, I can prepare a patch > file or > if you prefer I can use the great GitHub (in which case I > might need > help). > > Let me know. > > For projects and code forked from other repos, please take a look on > github's concept of "Pull Request" at > http://help.github.com/pull-requests/ > > > Nuccio > > Best > Dado > > > > > > > _______________________________________________ > 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 |
I didn't take a look before, but essentially the one main thing we'd
like for people to do when making their own public copies with modifications is to use the GitHub fork button so that it will keep your public copy connected with ours so that if there are modifications on your version it will show up here: https://github.com/elua/elua/network It looks like Nuccio's version is doing so. Doing this is as simple as following the instructions provided by GitHub (pretty much initiated by going to https://github.com/elua/elua and clicking the "Fork" button), and will make it easy to allow us to pull changes back in when they're ready to merge back into the main project (as has been mentioned before). -jsnyder On Sun, Mar 13, 2011 at 8:28 AM, Nuccio Raciti <[hidden email]> wrote: > good, thanks. > > Il giorno dom, 13/03/2011 alle 10.25 -0300, Dado Sutter ha scritto: >> >> >> On Sun, Mar 13, 2011 at 08:57, Nuccio Raciti <[hidden email]> >> wrote: >> Hi Bogdan, >> >> I made the GitHub fork, now a my project >> https://github.com/nuccioraciti/eLuaWebServer >> is there. >> >> Regarding the network support for AVR32, I can prepare a patch >> file or >> if you prefer I can use the great GitHub (in which case I >> might need >> help). >> >> Let me know. >> >> For projects and code forked from other repos, please take a look on >> github's concept of "Pull Request" at >> http://help.github.com/pull-requests/ >> >> >> Nuccio >> >> Best >> Dado >> >> >> >> >> >> >> _______________________________________________ >> 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 [hidden email] PGP: http://fanplastic.org/key.txt Phone: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Dado Sutter |
On Sun, Mar 13, 2011 at 21:37, James Snyder <[hidden email]> wrote: I didn't take a look before, but essentially the one main thing we'd Yes it is. Doing this is as simple The only other work at github I know of (from Marcelo Politzer) is also based on a fork. Other eLua-based applications exist at github (ex: Thiago Naves) and do not always need to be forks of the "main" project if they are, for example, Lua code applications. I think we all have a lot to learn with the github way of living and we seem to have started well. -jsnyder Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Dado Sutter |
On Sun, Mar 13, 2011 at 22:06, Dado Sutter <[hidden email]> wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Nuccio Raciti |
In reply to this post by Martin Guy
Hi,
I did a GitHub fork in order to push eth support: https://github.com/Mizar32/elua ... but it doesn't work using the "-Os" (the standard one for eLua) optimisation, so it needs further investigation before the delivery. Has anyone had similar problems? Il giorno sab, 12/03/2011 alle 00.10 +0100, Martin Guy ha scritto: > On 10 March 2011 17:23, Nuccio Raciti <[hidden email]> wrote: > > I have a first (and limited) version of the web server, working enough > > for a little demo. > > > > here: http://mizar32.dyndns.org/ > > > > Also there is a little AJAX application running on EVK1100. > > Grande! E complimenti! :) > > Can you extract the patch(es) to enable avr32 eth support as a first thing? > > Or send me (or make public? :) the modified version and tell me which > version it's based on and I'll see if I can prepare a patch > > M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Martin Guy |
On 14 March 2011 15:24, Nuccio Raciti <[hidden email]> wrote:
> I did a GitHub fork in order to push eth support: > https://github.com/Mizar32/elua > ... but it doesn't work using the "-Os" (the standard one for eLua) > optimisation, so it needs further investigation before the delivery. > > Has anyone had similar problems? Thanks. How do I test this? I was hoping for the "net" Lua module (as implemented on lm3s platform) but doing the obvious copying of lines from lm3s/platform_conf.h into avr32/MIZAR32/mizar32_conf.h and enabling anything that uses the net module, such as BUILD_CON_TCP or the NET module, still results in the compilation error src/elua_uip.o: In function 'elua_net_send': ... "undefined reference to `platform_eth_force_interrupt'" M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Hi,
On Tue, Mar 15, 2011 at 7:37 AM, Martin Guy <[hidden email]> wrote: > On 14 March 2011 15:24, Nuccio Raciti <[hidden email]> wrote: >> I did a GitHub fork in order to push eth support: >> https://github.com/Mizar32/elua >> ... but it doesn't work using the "-Os" (the standard one for eLua) >> optimisation, so it needs further investigation before the delivery. >> >> Has anyone had similar problems? > > Thanks. How do I test this? > I was hoping for the "net" Lua module (as implemented on lm3s platform) > but doing the obvious copying of lines from lm3s/platform_conf.h into > avr32/MIZAR32/mizar32_conf.h and enabling anything that uses the net > module, such as BUILD_CON_TCP or the NET module, still results in the > compilation error > > src/elua_uip.o: In function 'elua_net_send': > ... "undefined reference to `platform_eth_force_interrupt'" You still need to implement the Ethernet platform interface functions: http://www.eluaproject.net/en_arch_platform_eth.html Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
In reply to this post by Martin Guy
After a deep investigation, I discovered that the problem disappears building just "elua_uip.c" with no "-Os"
("-O2" or "-O3" are OK) nuccio > Hi, > I did a GitHub fork in order to push eth support: > https://github.com/Mizar32/elua > ... but it doesn't work using the "-Os" (the standard one for eLua) > optimisation, so it needs further investigation before the delivery. > Has anyone had similar problems? _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
On 15 March 2011 11:37, Nuccio Raciti <[hidden email]> wrote:
> After a deep investigation, I discovered that the problem disappears building just "elua_uip.c" with no "-Os" > ("-O2" or "-O3" are OK) Maybe this? https://bugs.launchpad.net/ubuntu/+source/gcc-avr/+bug/620646 For which one workaround is to remove the "static" declaration from one function, which would stop the function from being inlined. If removing "static" from all functions in that file fixes the problem, you can do a binary chop to identify the function(s) that need this change to work round the compiler bug. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
>problem, you can do a binary chop to identify the function(s) that
> need this change to work round the compiler bug. It is a good idea, I'm going to do it ... thanks N Il giorno mer, 16/03/2011 alle 00.18 +0100, Martin Guy ha scritto: > On 15 March 2011 11:37, Nuccio Raciti <[hidden email]> wrote: > > After a deep investigation, I discovered that the problem disappears building just "elua_uip.c" with no "-Os" > > ("-O2" or "-O3" are OK) > > Maybe this? > https://bugs.launchpad.net/ubuntu/+source/gcc-avr/+bug/620646 > > For which one workaround is to remove the "static" declaration from > one function, which would stop the function from being inlined. > If removing "static" from all functions in that file fixes the > problem, you can do a binary chop to identify the function(s) that > need this change to work round the compiler bug. > > M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
In reply to this post by Martin Guy
On Wed, Mar 16, 2011 at 1:18 AM, Martin Guy <[hidden email]> wrote:
Wow. Good catch, thank you. I wasn't even going to consider inlining problems at -Os. Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Nuccio Raciti |
In reply to this post by Martin Guy
The problem was related to the structure "elua_uip_state s" (**) that
should have been declared as "volatile". Ciao, N (**) line 279, file elua_uip.c, function elua_uip_appcall(). Il giorno mer, 16/03/2011 alle 00.18 +0100, Martin Guy ha scritto: > On 15 March 2011 11:37, Nuccio Raciti <[hidden email]> wrote: > > After a deep investigation, I discovered that the problem disappears building just "elua_uip.c" with no "-Os" > > ("-O2" or "-O3" are OK) > > Maybe this? > https://bugs.launchpad.net/ubuntu/+source/gcc-avr/+bug/620646 > > For which one workaround is to remove the "static" declaration from > one function, which would stop the function from being inlined. > If removing "static" from all functions in that file fixes the > problem, you can do a binary chop to identify the function(s) that > need this change to work round the compiler bug. > > M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
In reply to this post by BogdanM
2011/3/16 Bogdan Marinescu <[hidden email]>:
> > > On Wed, Mar 16, 2011 at 1:18 AM, Martin Guy <[hidden email]> wrote: >> >> On 15 March 2011 11:37, Nuccio Raciti <[hidden email]> wrote: >> > After a deep investigation, I discovered that the problem disappears >> > building just "elua_uip.c" with no "-Os" >> > ("-O2" or "-O3" are OK) >> >> Maybe this? >> https://bugs.launchpad.net/ubuntu/+source/gcc-avr/+bug/620646 >> >> For which one workaround is to remove the "static" declaration from >> one function, which would stop the function from being inlined. >> If removing "static" from all functions in that file fixes the >> problem, you can do a binary chop to identify the function(s) that >> need this change to work round the compiler bug. > > Wow. Good catch, thank you. I wasn't even going to consider inlining > problems at -Os. > Best, > Bogdan if you want to make it clear that the inline did the evil, you can declare it as: "static ... __attribute__((noinline));". To me, it seems a more clear way to show it. > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > -- best, Marcelo _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
In reply to this post by Martin Guy
Hi,
what about an eLua simulator: 1- with the network support (using a TUN/TAP device http://en.wikipedia.org/wiki/TUN/TAP). 2- running as a user space linux application. 3- using the linux FS as /mmc /rom file systems. is someone interested? nuccio _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Hi,
On Thu, Mar 17, 2011 at 3:48 PM, Nuccio Raciti <[hidden email]> wrote:
Hi, There is already a target ('sim') that does 2 and 3 above. Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
really?
I thought we should restart the PC for every run. the "sim" target is different of "i386" one? Ciao, nuccio Il giorno gio, 17/03/2011 alle 15.51 +0200, Bogdan Marinescu ha scritto: > Hi, > > On Thu, Mar 17, 2011 at 3:48 PM, Nuccio Raciti > <[hidden email]> wrote: > Hi, > what about an eLua simulator: > > 1- with the network support (using a TUN/TAP device > http://en.wikipedia.org/wiki/TUN/TAP). > 2- running as a user space linux application. > 3- using the linux FS as /mmc /rom file systems. > > > There is already a target ('sim') that does 2 and 3 above. > > > Best, > Bogdan > > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
On Thu, Mar 17, 2011 at 4:06 PM, Nuccio Raciti <[hidden email]> wrote: really? Yes ;) I thought we should restart the PC for every run. Yes. You get an executable that you can run using ./run_elua_sim.sh (Linux only)
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
good news,
I will try to add the network support... ciao, nuccio Il giorno gio, 17/03/2011 alle 16.12 +0200, Bogdan Marinescu ha scritto: > On Thu, Mar 17, 2011 at 4:06 PM, Nuccio > Raciti <[hidden email]> wrote: > really? > > > Yes ;) > > I thought we should restart the PC for every run. > the "sim" target is different of "i386" one? > > > Yes. You get an executable that you can run using ./run_elua_sim.sh > (Linux only) > > > Best, > Bogdan > > > > > Il giorno gio, 17/03/2011 alle 15.51 +0200, Bogdan Marinescu > ha scritto: > > > Hi, > > > > On Thu, Mar 17, 2011 at 3:48 PM, Nuccio Raciti > > <[hidden email]> wrote: > > Hi, > > what about an eLua simulator: > > > > 1- with the network support (using a TUN/TAP device > > http://en.wikipedia.org/wiki/TUN/TAP). > > 2- running as a user space linux application. > > 3- using the linux FS as /mmc /rom file systems. > > > > > > There is already a target ('sim') that does 2 and 3 above. > > > > > > Best, > > Bogdan > > > > > > > > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
On Thu, Mar 17, 2011 at 11:17, Nuccio Raciti <[hidden email]> wrote: good news, Cool. Last year, Thiago Naves and Marcelo Politzer were also experimenting with Proteus (http://www.labcenter.com/products/vsm_overview.cfm), trying to find a suitable target to embedd eLua. It would be great to have an eLua simulator on this kind of environment, as it already has interesting views and debug tools for the peripherals and even for simulated externally hardware connected to the MCU. As it has happened to eLua on the real world, I hope it is just a matter of time that new and larger (RAM & ROM) MCUs appear on the Proteus supported set. ciao, Best
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Free forum by Nabble | Edit this page |