Hello all,
my experience so far with development on the Nano:
IAR 4.0 is said to work correctly, but is not available; IAR 5.4 compiles/links correctly the code published at http://code.google.com/p/dsonano/downloads/detail?name=DSO%20BenF%20v3%20for%20IAR5.0.rar, but the firmware downloaded on my Nano does not work. It is likely to be my fault, only I have no clue about what’s wrong and how to debug. Does anybody has instructions (or pointers to documentation) on how to get a fully working IAR 5.4 setup to start hacking on the available code?
Tormod’s Linux gcc port compiles and links, but again I have no success in running the resulting code on the Nano; in this case the problem is known and Tormod is working on it. I’d love to get a complete solution for developing on Linux, since that’s the platform I use for all of my everyday work. I’m willing to help as much as I can - so feel free to ask and I’ll do my best to support your efforts.
BenF is adding new interesting functions to its code, but we still lack a centralized place for developers to put their sources, so that we mere mortals can download and learn from. A single place where sources will be uploaded by developers is really needed in order to understand what’s going on. Any source version control would do, as far as I’m concerned: but please do choose one and stick to that.
the forum is great for communicating among developers and for the more focused users, but the instructions are too scattered among threads to be found by a casual reader. A wiki kept by interested users (and possibly kept alongside with the sources) would be a much better solution - I for one would personally spend some of my time reorganizing infos from the forums into documentation that will come handy in the future.
In short: things are converging towards making the scope a very promising embedded development platform. Feel free to ask, I’d love to help where I can.
And, of course, a very big THANK YOU to everyone involved in making the most of the DSO Nano.
IAR company has removed IAR4.0 link.If you want to use it,you can contact with IAR. I migrate the Ben’s project from IAR4.0 to IAR5.0. I found the final DFU file can not work.I know the reason , but I do not know how to solve it.
Thanks for Tormod’s work. I have a plan to migrate the DSOv1.1 source code to GCC. Hope I have more time to do it as soon as possible.
3.Thanks for BenF’s work. He gives us a good start.How to manage the version of the source code is a big problem for me.I just used svn before, but it’s discommodious,everyone needs a client. Do you have any suggestions?
Would you mind trying to explain us where the problem lies? Collectively we can solve problems that none of us would be able to tackle alone.
Well, everyone involved in developing needs a client for sure; but with a little scripting you might be able to automagically prepare a packaged firmware release after each code update for “mere mortals” to test.
As for which tool is best, I really don’t know. Given that firmware sources are very compact and lean, I’d say that it does not really matter much which one you choose - probably, sticking with the one most of the current developers (which means you, BenF and Tormod, at present) are familiar with would be the easiest path.
I think maybe Jerry meant that with svn, everybody who wants to commit changes needs an account on the svn server. With git they can post their own branch on gitorious or github or their own webserver, and the maintainer can pull them in and merge. Of course, in both cases, a contributor can post patches to a mailing list, and the maintainer pushes them to the repository.
Using git, if a developer works on a new feature, and splits the work up in logically separate commits, the final branch can be easily merged into the main repo, and each commit will be preserved in the git history. With svn, each patch must be committed individually, or be applied as one mega-patch, unless you are using git-svn of course I guess if we choose svn, many of us will still use git “at home”, which is fine.
I guess if we choose svn, many of us will still use git “at home”, which is fine.