Mixed arm and thumb code
Locked
|
I'm starting to work with the Periodic Interval Timer on the AT91SAM7S and I believe I need to have the interrupt handlers be compiled as 32bit Arm instructions rather than 16bit Thumb instructions. I'm not familiar with scons, but is there an easy way that I can pass custom options to specific C files to control whether the -mthumb option is passed? Or, is the 'irqHandler' in the board_cstartup.s capable of calling the interrupt handler as thumb code? As best I can tell this is not the case and any C code called from the 'irqHandler' must be 32 bit Arm code.
Thanks, Mike |
|
|
On Thu, Mar 26, 2009 at 12:28 PM, mpthompson <[hidden email]> wrote:
This questin haunted me for quite a while now, and the answer seems to be no, there's no easy way to do this in scons. I'm sure there's a harder way :), but I just don't know how to do it. Check out src/platform/at91sam7x/platform.c though, you'll find that your interrupts can work just fine in Thumb mode, provided that you write them properly (platform.c already has examples of timer interrupt and UART RX interrupt). Best, Bogdan -- _______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Bogdan Marinescu wrote:
> This questin haunted me for quite a while now, and the answer seems to > be no, there's no easy way to do this in scons. I'm sure there's a > harder way :), but I just don't know how to do it. Check out > src/platform/at91sam7x/platform.c though, you'll find that your > interrupts can work just fine in Thumb mode, provided that you write > them properly (platform.c already has examples of timer interrupt and > UART RX interrupt). Ah, thanks for the tip. I didn't think of checking the SVN trunk files for examples of interrupts with the AT91SAM7. With that information I was able to get the Periodic Interval Timer to function properly. I've been working on getting Jesus work with the FatFS working under the AT91SAM7 and the mmc.c file needs timer functionality to process timeouts. I've got the code compiling, but not functioning :-(. I'm going to need to figure out some way of running GDB. Mike _______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by BogdanM
On Thu, 26 Mar 2009 23:30:49 Bogdan Marinescu wrote:
> On Thu, Mar 26, 2009 at 12:28 PM, mpthompson > <[hidden email]<mailto:[hidden email]>> wrote: > > I'm starting to work with the Periodic Interval Timer on the AT91SAM7S and > > I believe I need to have the interrupt handlers be compiled as 32bit Arm > > instructions rather than 16bit Thumb instructions. I'm not familiar with > > scons, but is there an easy way that I can pass custom options to specific > > C files to control whether the -mthumb option is passed? Or, is the > > 'irqHandler' in the board_cstartup.s capable of calling the interrupt > > handler as thumb code? As best I can tell this is not the case and any C > > code called from the 'irqHandler' must be 32 bit Arm code. > > This questin haunted me for quite a while now, and the answer seems to be > no, there's no easy way to do this in scons. Under these circumstances I'd be questioning whether scons is the right tool for the job. Tools are not there to make life difficult, and if one doesn't work, it is time to find another. IMHO Arnim. _______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
I've not tried these, but one of the responses in this thread might
help: http://scons.tigris.org/ds/viewMessage.do?dsForumId=1272&dsMessageId=1290233 I'm not hugely familiar with scons, but it would seem strange if it wouldn't do something like this. On Mar 26, 2009, at 2:44 PM, Arnim Littek wrote: > On Thu, 26 Mar 2009 23:30:49 Bogdan Marinescu wrote: >> On Thu, Mar 26, 2009 at 12:28 PM, mpthompson >> <[hidden email]<mailto:[hidden email]>> wrote: >>> I'm starting to work with the Periodic Interval Timer on the >>> AT91SAM7S and >>> I believe I need to have the interrupt handlers be compiled as >>> 32bit Arm >>> instructions rather than 16bit Thumb instructions. I'm not >>> familiar with >>> scons, but is there an easy way that I can pass custom options to >>> specific >>> C files to control whether the -mthumb option is passed? Or, is >>> the >>> 'irqHandler' in the board_cstartup.s capable of calling the >>> interrupt >>> handler as thumb code? As best I can tell this is not the case >>> and any C >>> code called from the 'irqHandler' must be 32 bit Arm code. >> >> This questin haunted me for quite a while now, and the answer seems >> to be >> no, there's no easy way to do this in scons. > > Under these circumstances I'd be questioning whether scons is the > right tool > for the job. Tools are not there to make life difficult, and if one > doesn't > work, it is time to find another. IMHO > > Arnim. > _______________________________________________ > Elua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev James Snyder Biomedical Engineering Northwestern University [hidden email] http://fanplastic.org/key.txt ph: (847) 448-0386 _______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
PGP.sig (201 bytes) |
|
In reply to this post by Arnim Littek
On Thu, Mar 26, 2009 at 16:44, Arnim Littek <[hidden email]> wrote:
Under the same philosophy of "doing the most we can in Lua", I've been checking the possibility of using Hamster. Asko is here in the list with us and is checking what went wrong with my first try on using it. I'm not sure if it will solve this issue though, as Hamster is also based on scons. Best Dado
_______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Just a general question... Why do people hate make so much? Its extremely powerful and IMO easy(er) to use for dependency tracking build systems then any other language... Not to mention the fact that anyone that is already using GCC has gmake installed, where that can't be said about any other build tool...
Just my 0.02 currency units. Mike On Sat, Mar 28, 2009 at 12:07 PM, Dado Sutter <[hidden email]> wrote:
_______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Well, personally I have a simple rule: if I keep on forgetting stuff I learn about a tool, it's not good enough for me. With make, I could never remember $@, $?, $< and other syntax stuff. Not to mention that the whole tabbing thing drives me insane. This is reminescent of the old Unix days (somebody here ever tried to modify an old sendmail.cf file ? :), and frankly (besides their unquestionable place in history) I don't think too high of them, mainly because I find them counterproductive. It's the same reason I'll never get along with perl, for example. And the list could go on :) I think we're progressing towards better tools, and although they are far from perfect, I get along with them just fine. scons is an example of such tool for me. Plus, on the more practical side, I could never do the kind of scripting I do in SConstruct with make.
Best, Bogdan On Sat, Mar 28, 2009 at 9:49 PM, Mike Panetta <[hidden email]> wrote: Just a general question... Why do people hate make so much? Its extremely powerful and IMO easy(er) to use for dependency tracking build systems then any other language... Not to mention the fact that anyone that is already using GCC has gmake installed, where that can't be said about any other build tool... _______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
The reason most people (me included) don't remember stuff about make is because not vary many people spend time writing build scripts. Most of the time we as programmers are writing actual code, not writing the stuff to build it. I hardly ever use python or ruby, so I am always looking up stuff on how to use them when I need to use them in a project. If I used that same rule to describe these languages then I would have to say they suck too. But they don't. :)
The tabbing does not bother me. At least not as much as pythons tabbing issues. A proper text editor will handle it for you anyway these days. As for not being able to do something with make that you can do with sconstruct, I highly doubt its due to any lacking features of make. Its more likely due to the level of familiarity you have with make vs python/scons. If make were as inflexible as you say, I highly doubt a build as complex as the Linux kernel would use it. For instance, scons seems to lack good support for directory recursion, and directory level build rules, unless you hack on it quite a bit. I once rewrote the eLua build system to factor out all the build rules into separate sconstruct files (I *HATE* long file lists with directory garbage in them), it was an immense task that could have been done extremely simply in make. I have in the past spent enough time as a build manager of large projects to realize that there truly is nothing as powerful as make in existence. You might want to pair something with it, like automake/autoconf or rubys make file generating tools, but I have yet to find a tool as simple (and as small!) as make. Mike On Sat, Mar 28, 2009 at 4:09 PM, Bogdan Marinescu <[hidden email]> wrote: Well, personally I have a simple rule: if I keep on forgetting stuff I learn about a tool, it's not good enough for me. With make, I could never remember $@, $?, $< and other syntax stuff. Not to mention that the whole tabbing thing drives me insane. This is reminescent of the old Unix days (somebody here ever tried to modify an old sendmail.cf file ? :), and frankly (besides their unquestionable place in history) I don't think too high of them, mainly because I find them counterproductive. It's the same reason I'll never get along with perl, for example. And the list could go on :) I think we're progressing towards better tools, and although they are far from perfect, I get along with them just fine. scons is an example of such tool for me. Plus, on the more practical side, I could never do the kind of scripting I do in SConstruct with make. _______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
The reason most people (me included) don't remember stuff about make is because not vary many people spend time writing build scripts. You're right, but IMO there's a level beyond this, a more philosophical one, that takes into account the overall design principles and usability features of the tool. And this is not dependent on how much time you spend using that tool, it's more a feeling you get when using it, something that comes from intuition (which in turn comes mostly from your own personal experience, so there's not such thing as a single universal truth in this area). The tabbing does not bother me. At least not as much as pythons tabbing issues. A proper text editor will handle it for you anyway these days. Touche on the Python tabbing. Still, I somehow like Python much more than I like make. Yes, I know they're very different tools, but once again I'm talking about the feeling I get by using each of them. As for not being able to do something with make that you can do with sconstruct, I highly doubt its due to any lacking features of make. Its more likely due to the level of familiarity you have with make vs python/scons. If make were as inflexible as you say, I highly doubt a build as complex as the Linux kernel would use it. I don't recall ever saying that make is inflexible. If I did, I have to apologize, because I find make one of the most flexible tools I ever encountered. But its flexibility comes at the price of expresivity and user friendliness (or, in other words, the sheer beauty of the language :) ) IMO. A price that some people (me included) aren't willing to pay unless they absolutely have to. If we were to follow the same principle in programming, we'd probably have to use C and nothing else, since it's such a flexible language. In the end, everybody needs to find his own balance and decide on the tool he finds most suitable for his own needs and preferences. It's always good to be able to make a choice. For instance, scons seems to lack good support for directory recursion, and directory level build rules, unless you hack on it quite a bit. I once rewrote the eLua build system to factor out all the build rules into separate sconstruct files (I *HATE* long file lists with directory garbage in them), it was an immense task that could have been done extremely simply in make. I think you can do that simpler in scons too, but I might be wrong. I do recall some quite simple scons scripts that dealt with recurssion somewhere in the internet :) I have in the past spent enough time as a build manager of large projects to realize that there truly is nothing as powerful as make in existence. That's the kind of statement that I generally find "too absolute" to be reasonable, but maybe you have indeed a vast experience with _lots_ of different build systems and tools. I only tried make combined with automake/autoconf (and I completely dislike them for the same reasons I dislike make), cmake (just a quick sip), some strange system based on DOS batch files :), and that's it (with the exception of scons, obviously). You might want to pair something with it, like automake/autoconf or rubys make file generating tools, but I have yet to find a tool as simple (and as small!) as make. Lua ? (I know, I know, I'm just being mean here :) ). I won't argue with the "small" part, but "small" is simply not something I'm after in a build tool. Please understand that I'm not trying to convince you that make is a bad tool, because I don't believe that. I'm just answering to your "why do you hate make" question. And I'm stating this because I don't want to start yet another religious war, although it would be a first for our mailing list :) Best, Bogdan PS. Hmmm ... sounds to me like you'd like to contribute a make-based build system to eLua ? :D
_______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Sat, Mar 28, 2009 at 5:05 PM, Bogdan Marinescu <[hidden email]> wrote:
True. Language preference always seems to come down to a personal thing anyway. :) As far as being a general purpose tool, make sucks. Its not even a very pretty language, but it gets the job done.
That makes (no pun intended??) sense.
Make is flexible, but ugly as hell. ;) I would never use it as a general purpose thing (I don't think you even could, there are some things make can't do, like math IIRC) but it is good for what it was designed for. I am not saying that you can't or should not use other languages to do build tasks. I am however saying that using a language that was designed for it is probably better then (more efficient than?) shoehorning another language in to doing the task. The fact that the scons package had to be developed to do something that is intrinsic to make is kind of proof of this IMO.
In this case I guess what I mean by simple was I would not have had to look it up in a manual to do it with make... Also, IIRC PWD/CWD issues are handled differently by scons/python vs make, which kind of confused me at first, but made sense when I started thinking of scons in terms of a single python process executing from project root, vs the way you normally do things in make. The main reason for the frustration was that in make based build systems (usually, not always) you can just 'cd' into part of the project tree and run a make there to (re)make just that part of the tree (say if you were editing files in that directory or whatever and you wanted to run a build test). With scons, as far as I know, there is no way to replicate this behaviour. You have no choice but to run the entire build from the project root dir. Please correct me if I am wrong here!
It is kind of absolute I guess. I have used scons in this project, and had exposure to it from a few other things, but never really had to *use* (maintain its use) except with eLua. I have designed some ruby modules, they sort of have their own build system, but its main purpose is to manage the construction of makefiles, so they technically use make. I have used a custom lisp based makefile management system, but again it used make on the backend. Most of the stuff I had to manage used autoconf/automake, which again is really just a makefile management system... Hmm even the buildroot based embedded stuff I had to integrate with/manage used make.... I guess I have been exposed to quite a bit of software that needed to be built, but most of it used make at some point! I have never really thought about it until now! Actually now that I think of it, are there really any build tools out there other then scons and derivatives that *don't* use make at some point?? I can't think of any off hand, but most of the software I build is either something I manage so uses make or a make manager, or foss/gnu type software which mostly uses autoconf....
Hmm, now I do find that interesting. The point of a build tool (IMO) is to make it easy to build software. This does not necessarily mean make it easy to write the build scripts, but it does mean that a piece of software should *just build* when you unpack it. As a software developer, there has been quite a bit of things that I wanted to play with but never have because they did not compile *out of the box*. I'm not talking about having to resolve dependencies due to external libs or whatever, I mean if I have to mess with the build system to get a piece of software I just want to use to even build, then its probably not worth my time. For the most part, software that uses make as a build system *just builds*. I can't say that for anything else, because for things like scons, you would (for the most part) have to go download scons, and maybe even python, and maybe (at an extreme) build them, before you can even build the scons managed code! Thats quite a bit of work just to do a task you will more then likely only do once (build the software then install it). This is why small in a build system is good. :) Think of all the people that don't have a fast connection that have to download a tool that may take many minutes to download and only a few to use. I would figure that being a person in a country where its hard to get hardware shipped/sourced you of all people would appreciate that. Imagine if we made people buy a hardware dongle (download a special build software) to do eLua development. Now quite a few of the people that want to do the development are in countries where buying and shipping the hardware is very difficult (slow network connection). That may be a bad analogy, but I think it fits to explain where I am coming from with my idea of build systems...
Hmm, a religious war around make would indeed be an odd one, esp for a first on a list. ;) Sorry if it seems like I am trying to start one, as I am not. I just never have understood the want of some to apply a large and generic tool to the job of a very specific and seldom used problem domain. Especially when there already exists a universally available and specifically designed tool for the job. Thats an issue with me, not anyone else. :)
I could if you really wanted. I could even make it fancy with a graphical configuration tool like the Linux kernel has (in fact it would be the same tool). In one way that would be nice to have as it seperates platform configuration out of the code, but I don't think eLua is big enough to actually *need* that feature right now. Thanks for the great debate :), Mike
_______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Interesting :) By following your logic, I'd probably come to the same conclusion I expressed in my previous message: everything but C is redundant :) since C was there from the very beginning, and everything that followed has the same functionality in the end, although the means to express it are different. Me, I _really_ like when there are many ways to do a given task, each suitable for certain kind of people. Efficiency can also be measured in more than one way, for example by factoring in the time one needs to learn a new build system, or maintenance issues. We use both make and scons where I work, and what I observed is that people that had some (spurious) bad experiences with make in the past feel more comfortable with scons. This doesn't prove much, but is consistent with my views.
I'm not sure about this. I know you can do "scons -C" just like you do "make -C", so maybe scons has support for what you want if you use multiple SConstruct files. But I didn't test this.
In software, history dies hard :) which has both good and bad parts. And, from what I could gather, most "hardcore" programmers are generally reluctant to change. I'm no exception; this week we talked about the new C++ standard proposal at work, and I was completely outraged by some of its new parts, until I started to think about them and realized that most of them make sense. Why would build systems be different? :)
I don't know of any.
Well, thanks for this. It seems that I was so focused on how much I dislike make that I forgot to think from the perspective of the end user when it comes to building. This is indeed a very good argument towards make, and one of the reasons it is still so popular. Maybe it's not fair, but so is life :)
You don't have to compile scons, fortunately, but everything else is true.
That makes sense, although it's more of an exceptional case; I would imagine that if you have enough bandwidth to download eLua, you could spare some for python/scons too. If you want to do serious development and you don't have access at least to a medium quality Internet connection, your developer life won't be easy anyway. Sad, but true.
It might be an issue with you, yes :) Once again, try to apply your own logic to programming languages in general, and see where it takes you. And I wouldn't consider a build system something "seldom used"; quite on the contrary, a build system is present everywhere but in the most trivial projects.
So how do we convince you to really want it? :) Cause really, all this discussion had the (good) side effect of convincing me that a make-based build system is a good thing, at least as an alternative (although having a project with two different build systems to choose from seems just plain weird). In particular, I'm very curious how you'll manage to duplicate the non-build-specific parts in SConstruct using make, like all the platform/CPU mappings, the filesystem/board mapping and so on.
It might not need it, but it's surely on the top 5 of our "TODO" list, and we'd very much like to have it as soon as possible. It's the kind of thing that makes a project look really professional (see for example Ethernut) and it saves you from reading all the documentation about the configuration parameters (although I put a LOT of effort into writing that, so part of me doesn't really want this to happen :D Kidding, of course).
You too! Best, Bogdan
_______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Mike Panetta
On Sun, Mar 29, 2009 at 01:20, Mike Panetta <[hidden email]> wrote:
Well, I can't think of a worse country to get hardware/components than Brasil today. On the other hand, I have a 27~30 Mbps bandwidth on my Lab :). At home, the average connection in Rio, at least for TI guys is ~8Mbps. 25Mbps is available in some areas but is still expensive. For ordinary connections, the average is 2~4 Mbps (ADSL, Cable and some radio). Wideband coverage is reasonable in the main/big cities, poor in most others and almost absent in the rest of the country, that is just too big for this matter. Things are changing fast though, compared to other infra-structure growth.
Hamster ? Asko ? :) (it is actually scons under the hood but with Lua driving it)
I think I've mentined before, the idea of a IUP based building system and we have actually creted a framework prototype for this. But it was done by some students, it needs a good cleanup (=redo it right :) and _time_ to work on it :( :( Should I try to restart to work on this _now_ (=right after v0.6 release) ?
Dado
_______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Actually, it's not. Hamster started as a Lua wrapper around SCons but the final version was able to run with either Gnu make, SCons, or _nothing_ as the back- end. It still borrows heavily (and extends) the SCons interface, since I found it good. -asko Dado Sutter kirjoitti 29.3.2009 kello 17:39: > Hamster ? Asko ? :) > (it is actually scons under the hood but with Lua driving it) _______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by mpthompson
Sometime on 3/28/2009, Mike Panetta wrote:
>Actually now that I think of it, are there really any build >tools out there >other then scons and derivatives that *don't* use make at some >point?? I >can't think of any off hand, but most of the software I build >is either >something I manage so uses make or a make manager, or foss/gnu >type software >which mostly uses autoconf.... Ant, the build system that seems to be preferred by the Java crowd, is completely unlike Make, and does not use make on the back end, unless extended with a custom build step that invokes make. It takes a whole-project view of the build, and IMHO doesn't mix well with the notion of building just this subtree of a project. On the other hand, the whole Java language design choice of storing source files in directory paths named after their fully-qualified class names is so hostile to that kind of development that you (or at least me, coming from a lot of background with make on more platforms than I want to count) don't even notice that lack as you fight all the other barriers that development in Java seems to throw your way. I'm reasonably sure that attempting to get make to drive the build of a serious Java project would drive anyone around the bend. Getting Ant to build "foreign" language (i.e. some C files implementing a few JNI classes) sources was surprisingly easy, unlike my attempts to do real work that needed "custom" (meaning non-standard) build steps in most IDEs. In some ways it was easier to get Ant to build them than it was to use the C code from the Java application. But that is part of a rant about Java that is even further off topic than this discussion of build systems ;-) There is even NAnt, which is a port of Ant to the .NET universe. One of the barriers to getting started with Ant that I noticed was its use of the full expressive power of XML to describe the build. For me, all that XML punctuation really gets in the way of what all boils down to wanting to describe the dependency graph, decorated by build instructions. I've always felt that make does that part really well, with a minimum of extraneous punctuation. Getting slightly closer to the list's topic, my only exposure to scons was not positive: for reasons that made sense at the time I needed to build VLC from sources on Solaris. Not only were the 33 libraries a barmier (most of which needed patching, and all needed building on the target platform) but the final straw was tripping over one that needed scons to build, which meant finding a working Python for Solaris, and learning scons to fix the inevitable platform-specific build issues. By that point, the return on the investment became negative, and we abandoned the whole idea. I have to agree with Mike's general message that a good build system really has to work out-of-the-box for distribution with a portable project. Otherwise, getting it setup and working becomes yet another barrier to adoption of the system. Ross Berteig [hidden email] Cheshire Engineering Corp. http://www.CheshireEng.com/ _______________________________________________ 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 |