AVR32 PX patch (again/still)
Locked
|
Bodgan
Can I apply my patch to give sensible names to the PX pins on AVR32? It works fine, the existing names are nonsense, and the integer version for Mizar32 in 0.8 doesn't fit in 128KB, whereas it does with this patch. You owned the issue a few weeks ago, but seem to be doing other things. 0.8 seems like another disaster release, like 0.7 which didn't even compile for EVK1100. Of course I appreciate the effort but the releases I've seen so far seem to need either an -rc phase, or (at this point) an 0.8.1 a few weeks later just to fix the three or four critical bugs that have been found since the release. That way, any distros that pick up eLua as part of them get a better version with less work to find patches for a working version. What do you say? Of course, you have the whole make-release process scripted? ;-) M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Tue, Feb 22, 2011 at 13:02, Martin Guy <[hidden email]> wrote: Bodgan True, true and I'm sorry for that too :( Again, it is simply a matter of the always lacking time and our (at least for now) impossibility to "live from" and for eLua :( Learning how to better manage an Open Source project is also a lesson I get on a daily basis from all of you and I'm very thankful for that. This means that there are chances I end up learning something eventually. I really feel that things are beginning to change now with true collaboration and I've been strongly focusing on the points that can make it come true (ie: the tracker launch, the wiki, a more modern site, a new doc structure and now a minimum refactoring that can allow easier platforms and modules ports contributions) but you are right and not only test policies but a minimum test-team is becoming extremely important too. What do you say? Of course, you have the whole make-release process ;-) M Best Dado _______________________________________________ _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hi,
>> Bodgan >> Can I apply my patch to give sensible names to the PX pins on AVR32? I've been meaning to do this myself this week-end but just couldn't find the time. I apologize for that. Please don't apply it yet, I'll take a look at it _today_ and most likely commit it. My idea to move it to to the platform interface layer proved to be non-trivial (and weird) so I abandoned it, I'll just patch the GPIO module as you suggested initially. I'll just do a quick sanity check and apply it. >> It works fine, the existing names are nonsense, and the integer >> version for Mizar32 in 0.8 doesn't fit in 128KB, whereas it does with >> this patch. I have no idea why it doesn't work for you. I just downloaded the eLua 0.8 source tarball from BerliOS and did this: bogdanm@bogdanm-desktop:~/work/elua/elua0.8$ scons board=mizar32 target=lualong prog -j2 [skip] progfunc_avr32(["prog"], ["elua_lualong_at32uc3a0128.elf"]) text data bss dec hex filename 121344 1364 1480 124188 1e51c elua_lualong_at32uc3a0128.elf Generating binary image... scons: done building targets. Also I can't imagine why your GPIO patch would have such a big impact on the Mizar32 image size. Yet another reason to take a better look at the patch :) >> 0.8 seems like another disaster release, like 0.7 which didn't even >> compile for EVK1100. Actually it did, but for an older version of the Atmel tools (headers and libraries); the newer library used a different API. This is what you get when dependencies such as headers and libraries are not part of the project. I think AVR32 is currently the only eLua target that has external dependencies. But yes, ATEVK1100 built just fine, the best proof is the ATEVK1100 binary image that is part of the 0.7 release. That said, while I'm the first to acknowledge that eLua has its (many) problems, I definitely wouldn't call 0.8 a "disaster release". But of course that's just me :) >> Of course I appreciate the effort but the >> releases I've seen so far seem to need either an -rc phase, or (at >> this point) an 0.8.1 a few weeks later just to fix the three or four >> critical bugs that have been found since the release. What exactly are the "three of four" _critical_ bugs in 0.8 ? >> What do you say? Of course, you have the whole make-release process >> scripted? ;-) Of course I do :) Making a new release is a fairly quick process, it's actually the overhead of uploading everything to BerliOS and creating a new release on their system that's more significant. But I'm sorry, at this point I simply don't see a need for it. Points to clarify: - why does Mizar32 work for me but not for you ? - what are the critical bugs you're referring to ? Best, Bogdan >> >> _______________________________________________ >> 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 |
|
|
OK, I think I know why. You're using the multiple allocator (which you
should) and I assumed that's hardcoded in the build script (and it's not). My bad. Back to the drawing board :) Best, Bogdan On Tue, Feb 22, 2011 at 8:12 PM, Bogdan Marinescu <[hidden email]> wrote: > Hi, > >>> Bodgan >>> Can I apply my patch to give sensible names to the PX pins on AVR32? > > I've been meaning to do this myself this week-end but just couldn't > find the time. I apologize for that. Please don't apply it yet, I'll > take a look at it _today_ and most likely commit it. My idea to move > it to to the platform interface layer proved to be non-trivial (and > weird) so I abandoned it, I'll just patch the GPIO module as you > suggested initially. I'll just do a quick sanity check and apply it. > >>> It works fine, the existing names are nonsense, and the integer >>> version for Mizar32 in 0.8 doesn't fit in 128KB, whereas it does with >>> this patch. > > I have no idea why it doesn't work for you. I just downloaded the eLua > 0.8 source tarball from BerliOS and did this: > > bogdanm@bogdanm-desktop:~/work/elua/elua0.8$ scons board=mizar32 > target=lualong prog -j2 > [skip] > progfunc_avr32(["prog"], ["elua_lualong_at32uc3a0128.elf"]) > text data bss dec hex filename > 121344 1364 1480 124188 1e51c elua_lualong_at32uc3a0128.elf > Generating binary image... > scons: done building targets. > > Also I can't imagine why your GPIO patch would have such a big impact > on the Mizar32 image size. Yet another reason to take a better look at > the patch :) > >>> 0.8 seems like another disaster release, like 0.7 which didn't even >>> compile for EVK1100. > > Actually it did, but for an older version of the Atmel tools (headers > and libraries); the newer library used a different API. This is what > you get when dependencies such as headers and libraries are not part > of the project. I think AVR32 is currently the only eLua target that > has external dependencies. But yes, ATEVK1100 built just fine, the > best proof is the ATEVK1100 binary image that is part of the 0.7 > release. > That said, while I'm the first to acknowledge that eLua has its (many) > problems, I definitely wouldn't call 0.8 a "disaster release". But of > course that's just me :) > >>> Of course I appreciate the effort but the >>> releases I've seen so far seem to need either an -rc phase, or (at >>> this point) an 0.8.1 a few weeks later just to fix the three or four >>> critical bugs that have been found since the release. > > What exactly are the "three of four" _critical_ bugs in 0.8 ? > >>> What do you say? Of course, you have the whole make-release process >>> scripted? ;-) > > Of course I do :) Making a new release is a fairly quick process, it's > actually the overhead of uploading everything to BerliOS and creating > a new release on their system that's more significant. But I'm sorry, > at this point I simply don't see a need for it. Points to clarify: > > - why does Mizar32 work for me but not for you ? > - what are the critical bugs you're referring to ? > > Best, > Bogdan > > >>> >>> _______________________________________________ >>> 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 |
|
|
Sorry again, I'm confusing myself :) I thought you said at some point
that you don't really need the multiple allocator in Mizar32 because you'd use only the external SDRAM as the main memory (which is also what the platform_conf.h of Mizar32 suggests). The multiple allocator is only used if you need to allocate memory from multiple non-contigous address spaces (for example internal RAM and external RAM). This is why Mizar23 uses the simple allocator by default. Best, Bogdan On Tue, Feb 22, 2011 at 9:45 PM, Bogdan Marinescu <[hidden email]> wrote: > OK, I think I know why. You're using the multiple allocator (which you > should) and I assumed that's hardcoded in the build script (and it's > not). My bad. Back to the drawing board :) > > Best, > Bogdan > > On Tue, Feb 22, 2011 at 8:12 PM, Bogdan Marinescu > <[hidden email]> wrote: >> Hi, >> >>>> Bodgan >>>> Can I apply my patch to give sensible names to the PX pins on AVR32? >> >> I've been meaning to do this myself this week-end but just couldn't >> find the time. I apologize for that. Please don't apply it yet, I'll >> take a look at it _today_ and most likely commit it. My idea to move >> it to to the platform interface layer proved to be non-trivial (and >> weird) so I abandoned it, I'll just patch the GPIO module as you >> suggested initially. I'll just do a quick sanity check and apply it. >> >>>> It works fine, the existing names are nonsense, and the integer >>>> version for Mizar32 in 0.8 doesn't fit in 128KB, whereas it does with >>>> this patch. >> >> I have no idea why it doesn't work for you. I just downloaded the eLua >> 0.8 source tarball from BerliOS and did this: >> >> bogdanm@bogdanm-desktop:~/work/elua/elua0.8$ scons board=mizar32 >> target=lualong prog -j2 >> [skip] >> progfunc_avr32(["prog"], ["elua_lualong_at32uc3a0128.elf"]) >> text data bss dec hex filename >> 121344 1364 1480 124188 1e51c elua_lualong_at32uc3a0128.elf >> Generating binary image... >> scons: done building targets. >> >> Also I can't imagine why your GPIO patch would have such a big impact >> on the Mizar32 image size. Yet another reason to take a better look at >> the patch :) >> >>>> 0.8 seems like another disaster release, like 0.7 which didn't even >>>> compile for EVK1100. >> >> Actually it did, but for an older version of the Atmel tools (headers >> and libraries); the newer library used a different API. This is what >> you get when dependencies such as headers and libraries are not part >> of the project. I think AVR32 is currently the only eLua target that >> has external dependencies. But yes, ATEVK1100 built just fine, the >> best proof is the ATEVK1100 binary image that is part of the 0.7 >> release. >> That said, while I'm the first to acknowledge that eLua has its (many) >> problems, I definitely wouldn't call 0.8 a "disaster release". But of >> course that's just me :) >> >>>> Of course I appreciate the effort but the >>>> releases I've seen so far seem to need either an -rc phase, or (at >>>> this point) an 0.8.1 a few weeks later just to fix the three or four >>>> critical bugs that have been found since the release. >> >> What exactly are the "three of four" _critical_ bugs in 0.8 ? >> >>>> What do you say? Of course, you have the whole make-release process >>>> scripted? ;-) >> >> Of course I do :) Making a new release is a fairly quick process, it's >> actually the overhead of uploading everything to BerliOS and creating >> a new release on their system that's more significant. But I'm sorry, >> at this point I simply don't see a need for it. Points to clarify: >> >> - why does Mizar32 work for me but not for you ? >> - what are the critical bugs you're referring to ? >> >> Best, >> Bogdan >> >> >>>> >>>> _______________________________________________ >>>> 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 |
|
|
In reply to this post by Martin Guy
On Tue, Feb 22, 2011 at 6:02 PM, Martin Guy <[hidden email]> wrote:
> Bodgan > Can I apply my patch to give sensible names to the PX pins on AVR32? > It works fine, the existing names are nonsense, and the integer > version for Mizar32 in 0.8 doesn't fit in 128KB, whereas it does with > this patch. > You owned the issue a few weeks ago, but seem to be doing other things. Patch commited to trunk. Again, sorry it took so long. Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by BogdanM
On 22 February 2011 20:45, Bogdan Marinescu <[hidden email]> wrote:
> OK, I think I know why. You're using the multiple allocator >... > bogdanm@bogdanm-desktop:~/work/elua/elua0.8$ scons board=mizar32 target=lualong prog -j2 > text data bss dec hex filename > 121344 1364 1480 124188 1e51c elua_lualong_at32uc3a0128.elf No, I'm using newlib, which is smaller, not simple which is even smaller but had that startup time problem scons board=mizar32 target=lualong allocator=newlib optram=0 ... Programming 123164 bytes in 4 segments. Verifying flash: ================================================== 100.0% Verify failed at address 0x80020000. Expected 00, read e1. If you're interested in "size" I get: 120320 1364 1480 123164 1e11c elua_lualong_at32uc3a0128.elf I guess you're not counting the BSS and DATA in the 120KB, > What exactly are the "three of four" _critical_ bugs in 0.8 ? Well, in the AVR stuff there was the EVK1100 serial port not working at all due to being configured in SERMUX mode, the image being >128KB for Mizar32 by default, I forget if there were others. I would include the PX patch in the release fixes, but then I have a vested interest in not wanting to have to document two incompatible sets of pin names. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Tue, Feb 22, 2011 at 20:45, Martin Guy <[hidden email]> wrote:
I think this was an option (not a bug), to allow the use of RFS (Remote File System) and terminal sharing the same UART, an important feature for eLua but not very well documented yet for new users. the image being >128KB for Mizar32 by default, I forget if there were Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Martin Guy
...did I mention how much I hate "reply all" ? :)
---------- Forwarded message ---------- From: Bogdan Marinescu <[hidden email]> Date: Wed, Feb 23, 2011 at 10:05 AM Subject: Re: [eLua-dev] AVR32 PX patch (again/still) To: Martin Guy <[hidden email]> On Wed, Feb 23, 2011 at 1:45 AM, Martin Guy <[hidden email]> wrote: > No, I'm using newlib, which is smaller, not simple which is even > smaller but had that startup time problem > > scons board=mizar32 target=lualong allocator=newlib optram=0 > ... > > Programming 123164 bytes in 4 segments. > Verifying flash: ================================================== 100.0% > Verify failed at address 0x80020000. Expected 00, read e1. > > If you're interested in "size" I get: > 120320 1364 1480 123164 1e11c elua_lualong_at32uc3a0128.elf > > I guess you're not counting the BSS and DATA in the 120KB, We've been over this before and I maintain my position: a target downloader program should NOT write the .bss segment into Flash. It makes not sense at all to write into Flash something that is ALWAYS 0. There's a reason why the .bss segment has the type NOLOAD in the elf section headers and even a basic downloader tool should take this into account. I do not intend to modify eLua to compensate for faulty 3rd party tools especially when there are alternatives: - Linux: use dfu-programmer - Windows: use FLIP (batchisp) Both will flash a hex file instead of the elf. The hex image is correctly generated by the eLua build system (it doesn't contain the .bss image) so you won't have this problem anymore. Try this if you have some time: 1. svn update the Lua trunk 2. $ sudo luarocks install lpack 3. $ sudo luarocks install luafilesystem 4. put your board in DFU mode and connect it to the PC 5. $ lua build_elua.lua board=mizar32 target=lualong burn This sequence build the image and uses dfu-programmer to write it to target, all with a single command. I'm really curious if that works for you. > Well, in the AVR stuff there was the EVK1100 serial port not working > at all due to being configured in SERMUX mode, Hmmmm. I can understand why that would be regarded as an issue by some and as a feature by others :) The rationale behind this decision (leaving RFS + sermux enabled for ATEVK1100) was that EVK1100 has enough resources to accomodate a larger configuration and RFS is a nice thing to have. That said, I understand the downside, plus I know that this kind of stuff should really be documented somewhere (most likely on the wiki). > the image being >128KB for Mizar32 by default, I forget if there were > others. I think another issue was the HW flow control not working properly on AVK1100 and possibly other AVR32 targets. I didn't have time to investigate, sorry. Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On 23 February 2011 09:06, Bogdan Marinescu <[hidden email]> wrote:
> a target > downloader program should NOT write the .bss segment into Flash. Absolutely. This is verified by the fact that the same image, written with dfu-programmer, fits. Long live open source. > Try this if you have some time: > > 1. svn update the Lua trunk > 2. $ sudo luarocks install lpack > 3. $ sudo luarocks install luafilesystem > 4. put your board in DFU mode and connect it to the PC > 5. $ lua build_elua.lua board=mizar32 target=lualong burn Works fine, and fits even without the optram and allocator options. Great! Unlike most programs, eLua is getting smaller! :) >> Well, in the AVR stuff there was the EVK1100 serial port not working >> at all due to being configured in SERMUX mode, > > Hmmmm. I can understand why that would be regarded as an issue by some > and as a feature by others :) The rationale behind this decision > (leaving RFS + sermux enabled for ATEVK1100) was that EVK1100 has > enough resources to accomodate a larger configuration and RFS is a > nice thing to have. In default configurations, one usually gives a standard setup that is similar for all boards, in this case console on first serial port, which was also the eLua config for evk1100 up to 0.799999. The effect is that one tries the release with the expected setup and gets garbage on the console. SERMUX + RFS seems to me a "Book 2" feature, not a basic config, or if it's "the way to go", maybe all boards should be configured that way by default. > I think another issue was the HW flow control not working properly on > AVK1100 and possibly other AVR32 targets. I didn't have time to > investigate, sorry. Yes, the recent fix for flow control on AVR32 didn't seem to work when I tried to test it. My results were not definitely conclusive. However, that's not an issue for a release, since it has never worked. Oh, and I apologise for the term "disaster release". Too strong. However, my expectation of a release is that it basically works out of the box, and that hasn't been true of either of the releases I've seen. Maybe I'm just being unlucky to be using the AVR32 platforms, but what I'm seeing is that the range of supported platforms is not tested much, and the releases seem to push a lot of new features into eLua at the last minute. The first can be fixed by adding a short phase of community testing to the release procedure, either as release candidates or as post-release correction steps (0.8.1 or whatever) to the release branch, the same as Linux, GCC and other projects. The second is a common effect in open source releases, the rush to finish and include various works in progress in the last days before a release. Again, a phase of release testing would help with this; better if merging of new functionality happens just after a release, not just before. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
for i = 1, 100 do
print "I WILL PUSH THE 'REPLY ALL' BUTTON NEXT TIME" end On Fri, Feb 25, 2011 at 10:09 AM, Bogdan Marinescu <[hidden email]> wrote: > On Wed, Feb 23, 2011 at 3:23 PM, Martin Guy <[hidden email]> wrote: >> Works fine, and fits even without the optram and allocator options. >> Great! Unlike most programs, eLua is getting smaller! :) > > If only we could keep this trend while adding more functionality ... :) > >> In default configurations, one usually gives a standard setup that is >> similar for all boards, in this case console on first serial port, >> which was also the eLua config for evk1100 up to 0.799999. The effect >> is that one tries the release with the expected setup and gets garbage >> on the console. >> SERMUX + RFS seems to me a "Book 2" feature, not a basic config, or if >> it's "the way to go", maybe all boards should be configured that way >> by default. > > That makes a lot of sense. There are more ways to handle this but one > of them is indeed providing a "basic configuration" for all board in > the official builds. And, of course, defining what a "base > configuration" actually is. > >> Oh, and I apologise for the term "disaster release". Too strong. >> However, my expectation of a release is that it basically works out of >> the box, and that hasn't been true of either of the releases I've >> seen. Maybe I'm just being unlucky to be using the AVR32 platforms, >> but what I'm seeing is that the range of supported platforms is not >> tested much, and the releases seem to push a lot of new features into >> eLua at the last minute. > > Yes, that's my bad. The hardware flow control was definitely pushed in > a hurry, without testing it on all platforms (which is even more > annoying because at this point there are exactly two platform on which > HW flow control is implemented). It is also true that eLua needs a LOT > of work in the testing department. > >> The first can be fixed by adding a short phase of community testing to >> the release procedure, either as release candidates or as post-release >> correction steps (0.8.1 or whatever) to the release branch, the same >> as Linux, GCC and other projects. >> The second is a common effect in open source releases, the rush to >> finish and include various works in progress in the last days before a >> release. Again, a phase of release testing would help with this; >> better if merging of new functionality happens just after a release, >> not just before. > > Thank you very much for your this. I consider myself a good programmer > but I know I'm a walking disaster in the testing department. Most of > the problems with eLua releases stem directly from this. But I'm > trying to learn :) > > Best, > Bogdan > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |