[En-Nut-Discussion] Moving to Subversion
Harald Kipp
As soon as remaining bugs in 4.7 are fixed, I will create a new branch
4.8 to get a new stable release published.
As suggested by Thiago and others, we may finally take the chance and
move the resulting CVS HEAD 4.9 to a Subversion repository. I do have
some SVN experience (egnite is using it internally for some time), but
not with the Sourceforge implementation. And I never converted a project
from CVS to SVN. Anyway, some hints had been posted in this list and
I'll probably find more in the web.
While moving, we may be able to solve another problem, which is caused
by the current directory structure. When using the GNU autotools for the
first time, conflicts appeared.
The source tree nut became the top directory when running 'make
distcheck'. This introduced conflicts with existing files, which had
been solved by renaming files or moving them to lib/. The remaining
problem is, that the Linux/OS X user must manually create a new top
directory, install the distribution in that directory and manually
create a link (e.g. linking nut to ethernut-4.6.4).
I'd suggest the following new structure
trunk/
nutos/
nut/
app/
arch/
...
tags/
branches/
with nutos as a new top level directory containing the configure script
etc. and the existing source tree nut/ in a subdirectory.
This way we will get the same top level structure when installing Nut/OS
on different platforms
ethernut-x.y.z/
nut/
nutapp/
nutbld/
Comments?
Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Tim DeBaillie
Tim
--
Tim DeBaillie
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Marti Raudsepp
On Sun, Dec 21, 2008 at 1:58 PM, Harald Kipp <haral...@egnite.de> wrote:
> As suggested by Thiago and others, we may finally take the chance and
> move the resulting CVS HEAD 4.9 to a Subversion repository.
May I suggest considering distributed version control systems before
making that decision? Lots of open source projects are already
migrating from Subversion to distributed systems; as far as I can tell
it's only a matter of time when SVN meets the same fate as CVS.
If you're not yet familiar with distributed VCSes, here are main advantages:
* Branching and merging is much very natural because it's the normal
mode of operation. Every time you clone, you get a new branch. Every
time you want to get the changes from a diverging repository, you
merge.
* Revisions can be commited by anyone and later merged into the main
repository by trusted users: The version control system is useful for
those without commit access.
* In general, DVCSes put less constraints on workflows. You can use
them like a centralized systems, but you won't want to, once you get
to understand them.
* Maintaining, publishing and merging back experimental or third-party
repositories is much easier. This is especially useful for maintaining
private changes on top of the official Nut/OS source tree.
* Even if written in Python, distributed systems are usually
significantly faster than Subversion. :)
* No central point of failure.
* Offline operation. You can make multiple commits locally before
pushing them up to the public server.
* (At least in Mercurial), changesets can be e-mailed around like
patches, but they retain their metadata (commiter name, commit time
and base revision) and always apply cleanly.
These advantages may not seem significant at first in face of SVN's
popularity, but they enable lots of flexibility. Many OSS projects
have considered the switch worthwhile. For more information, Linus's
Google Talk about git touches all the aspects of why distribution
matters: http://www.youtube.com/watch?v=4XpnKHJAok8
There are 3 popular DVCSes that are worth considering: git, Mercurial
and Bazaar. All of them provide similar functionality, although each
has its advantages and drawbacks. (I myself prefer Mercurial)
Marti
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Adam Dybkowski
> There are 3 popular DVCSes that are worth considering: git, Mercurial
> and Bazaar. All of them provide similar functionality, although each
> has its advantages and drawbacks. (I myself prefer Mercurial)
BTW: Huge projects like Android OS use git. Think about it, maybe it's
the easiest to maintain or provides more features than the others. It's
client command line syntax is very similar to svn or cvs.
--
Adam Dybkowski
adyb...@wp.pl
http://dybkowski.net/
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Harald Kipp
> May I suggest considering distributed version control systems before
> making that decision? Lots of open source projects are already
> migrating from Subversion to distributed systems; as far as I can tell
> it's only a matter of time when SVN meets the same fate as CVS.
Many thanks for this valuable entry.
This one may be of interest
http://www.diffen.com/difference/Git_(software)_vs_Mercurial_(software)
Naturally I prefer software written in C and always had been skeptical
about Python based tools. However, in this case I'm tending to favor
Mercurial as it seems to be less Linux-centric.
Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Thiago A. Corrêa
Just my opinion on this, please don't take anything personaly.
On Fri, Feb 27, 2009 at 2:05 PM, Marti Raudsepp <ma...@juffo.org> wrote:
> May I suggest considering distributed version control systems before
> making that decision? Lots of open source projects are already
> migrating from Subversion to distributed systems; as far as I can tell
> it's only a matter of time when SVN meets the same fate as CVS.
Subversion is actively developed, recently they improved their merging
algorithms.
Different projects have different requirements, just because others
are using something else, it doesn't mean we should.
Also, we host our code, bugtracker, etc at SourceForge. Anything
different than CVS or SVN would be considering moving the hosting of
the code at least.
There is also another concern: The revision history. SVN has ways of
converting the CVS repository without loosing the history.
> If you're not yet familiar with distributed VCSes, here are main advantages:
> * Branching and merging is much very natural because it's the normal
> mode of operation. Every time you clone, you get a new branch. Every
> time you want to get the changes from a diverging repository, you
> merge.
On the other hand, normal operation is different from what we are used
to. I for one was never able to understand git, and I'm not going to
try either.
> * Revisions can be commited by anyone and later merged into the main
> repository by trusted users: The version control system is useful for
> those without commit access.
I use buildroot with my own copy of the repository (vendor branches)
and I do svn merge from the upstream tree directly into my working
copy.
So, nothing new.
> * In general, DVCSes put less constraints on workflows. You can use
> them like a centralized systems, but you won't want to, once you get
> to understand them.
We might have something between 3 to 5 active developers right now,
and I'm including myself, even though I commit just every now and
then. I don't see how that would benefit us. On the other hand moving
from CVS to subversion gives us atomic commits, so we can see from svn
log what changed in all files. That alone is an advantage. Granted,
every modern version control system does that, but at least svn makes
sense to us considering what we have always used up to now.
> * Maintaining, publishing and merging back experimental or third-party
> repositories is much easier. This is especially useful for maintaining
> private changes on top of the official Nut/OS source tree.
Vendor branches is one possibility, see my buildroot example above.
> * Even if written in Python, distributed systems are usually
> significantly faster than Subversion. :)
I've used Subversion for ages, and performance of subversion itself
have never seem to bother me. We spend far more time wainting for gcc
to do it's job every day than subversion or CVS for that matter.
> * No central point of failure.
Sourceforge manages that for us for free.
> * Offline operation. You can make multiple commits locally before
> pushing them up to the public server.
That might be nice.
> * (At least in Mercurial), changesets can be e-mailed around like
> patches, but they retain their metadata (commiter name, commit time
> and base revision) and always apply cleanly.
We don't have nearly the same requirements as the Linux Kernel on that
matter. We have few patches submited.
Sure it would be very nice if we could get more ppl to get involved,
but I don't think the vcs is what will attract them our way, whatever
may it be.
> These advantages may not seem significant at first in face of SVN's
> popularity, but they enable lots of flexibility. Many OSS projects
> have considered the switch worthwhile. For more information, Linus's
> Google Talk about git touches all the aspects of why distribution
> matters: http://www.youtube.com/watch?v=4XpnKHJAok8
>
Mozilla and many others had also ruled them out publicly. Until
recently Git's win32 support was praticaly unexistant. And from what I
could find, it's still a bit awkward. Depending on cygwin isn't
properly supporting Win32, just like providing win32 binaries to run
under Wine isn't properly supporting Linux.
We should consider what are our requirements and make up our mind for
ourselfs, not based on other project's decisions.
Kind Regards,
Thiago A. Correa
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Edwin van den Oetelaar
> Hi,
>
> Just my opinion on this, please don't take anything personaly.
>
> On Fri, Feb 27, 2009 at 2:05 PM, Marti Raudsepp <ma...@juffo.org> wrote:
>> May I suggest considering distributed version control systems before
>> making that decision? Lots of open source projects are already
>> migrating from Subversion to distributed systems; as far as I can tell
>> it's only a matter of time when SVN meets the same fate as CVS.
>
> Subversion is actively developed, recently they improved their merging
> algorithms.
> Different projects have different requirements, just because others
> are using something else, it doesn't mean we should.
> Also, we host our code, bugtracker, etc at SourceForge. Anything
> different than CVS or SVN would be considering moving the hosting of
> the code at least.
I would like to add to that.
Subversion works on my systems, it integrates nicely with Windows via
Turtoise and with my Gnome Desktop, Eclipse (which I also use for AVR)
and Komodo (perl/python).
It has a command line interface I understand. (since I used CVS before)
We should choose the tool that is best for the project, not the tool
that is in fashion this week.
just my opinion,
Greetings,
Edwin
Ps. For your info, SourceForge will be integrating Git in their system.
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Harald Kipp
> Just my opinion on this, please don't take anything personaly.
Bummer! Would have been a good chance for a flame war. ;-)
I agree with some of your arguments, many of them I'm not able to
comment because I do not know much about DVCSs yet.
> recently Git's win32 support was praticaly unexistant. And from what I
> could find, it's still a bit awkward. Depending on cygwin isn't
> properly supporting Win32, just like providing win32 binaries to run
> under Wine isn't properly supporting Linux.
AFAIK there is a mingw based version available now.
Anyway, your critics are mostly related to git. Mercurial seems to
provide better Win32, OS X and internationalization support.
> We should consider what are our requirements and make up our mind for
> ourselfs, not based on other project's decisions.
Yes and no. Definitely we have to make our own judgement. On the other
hand you can't change a VCS easily so it is important to look to other
project's decisions just to make sure that the selected VCS will have a
long future.
Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Edwin van den Oetelaar
It seems that I spoke too soon, it looks like mercurial has everything I
need, Eclipse/Komodo(5.0)/TurtoiseHG/Gnome integration, a command line
that is understandable.
Geezzz things move fast...
Gr,
Edwin
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Harald Kipp
> Subversion works on my systems, it integrates nicely with Windows via
> Turtoise and with my Gnome Desktop, Eclipse (which I also use for AVR)
> and Komodo (perl/python).
http://www.vectrace.com/mercurialeclipse/
http://git.or.cz/gitwiki/EclipsePlugin
> It has a command line interface I understand. (since I used CVS before)
> We should choose the tool that is best for the project, not the tool
git even has a SVN interface.
> that is in fashion this week.
Definitely. But we can be sure, that the Linux kernel development team
don't use git because it is fashion.
Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Harald Kipp
> Mozilla and many others had also ruled them out publicly. Until
https://developer.mozilla.org/en/Mozilla_Source_Code_(Mercurial)
Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
duane ellis
used CVS before)
FYI - there is a major problem mixing cygwin cmdline + Win32 GUI
(tortoise), and this sucks big time.
http://tortoisesvn.tigris.org/faq.html#multiclients
-Duane
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Marti Raudsepp
<thiago...@gmail.com> wrote:
> Just my opinion on this, please don't take anything personaly.
> Different projects have different requirements, just because others
> are using something else, it doesn't mean we should.
Certainly, but my point pretty much is that distributed version
control systems can do anything that SVN can, and more. Why settle for
the inferior?
> Also, we host our code, bugtracker, etc at SourceForge. Anything
> different than CVS or SVN would be considering moving the hosting of
> the code at least.
For those of us who hate SourceForce, that would be a bonus.
> There is also another concern: The revision history. SVN has ways of
> converting the CVS repository without loosing the history.
As do other version control systems.
> On the other hand, normal operation is different from what we are used
> to. I for one was never able to understand git, and I'm not going to
> try either.
I can second that, git used to have awful documentation and a terrible
command line interface; this has changed a lot recently.
Mercurial always tried to be the user-friendlier one. I can recommend
Bryan O’Sullivan's "Distributed revision control with Mercurial" book
for an introduction: http://hgbook.red-bean.com/hgbook.html
>> * Revisions can be commited by anyone and later merged into the main
>> repository by trusted users: The version control system is useful for
>> those without commit access.
> I use buildroot with my own copy of the repository (vendor branches)
True, you can do that, though it sounds a bit tedious.
> I've used Subversion for ages, and performance of subversion itself
> have never seem to bother me. We spend far more time wainting for gcc
> to do it's job every day than subversion or CVS for that matter.
I used to think that SVN was fast too. Now every time I need to use
SVN, I find myself tapping my fingers on the table. Sure, compilation
also takes time, but we aren't switching the compiler here.
Here's a few more points that popped into my mind why I prefer hg:
* With SVN, if you try to commit to a repository that has newer
changes, you have to merge local changes with HEAD before you can
actually commit. This always seemed backwards to me, and tends to
confuse people who are new to SVN.
* A built-in web server that you can launch typing just 'hg serve'.
This can be accessed with a browser as well as cloned/pulled from. I
never liked ViewVC.
* Mercurial queues (a'la quilt) provides a nice way to experiment with
larger (multi-revision) changes locally. It takes time to learn how to
use it though.
* Having commit and push as distinct steps means that there's a window
of opportunity to correct last minute mistakes. 'hg rollback' is handy
for undoing the latest commit.
* Metadata is kept in .hg under the top-level directory -- instead of
a .svn in each subdirectory of the project.
Marti
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Henrik Maier
> From: en-nut-discu...@egnite.de [mailto:en-nut-discussion-
> bou...@egnite.de] On Behalf Of Harald Kipp
>
> Many thanks for this valuable entry.
>
> This one may be of interest
> http://www.diffen.com/difference/Git_(software)_vs_Mercurial_(software)
>
> Naturally I prefer software written in C and always had been skeptical
> about Python based tools. However, in this case I'm tending to favor
> Mercurial as it seems to be less Linux-centric.
>
> Harald
A while ago I also moved to a distributed revision control system and chose
Mercurial over Git. Mercurial seems easier to learn and use and I develop
mostly on Windows, so a good Windows integration and support is important
for me.
>From http://hgbook.red-bean.com/hgbookch1.html#x5-180001.6:
"Git has a very large command set, with version 1.5.0 providing 139
individual commands. It has something of a reputation for being difficult to
learn. Compared to Git, Mercurial has a strong focus on simplicity."
The other issue is that Git depends on shell scripts which is an issue on
Windows platforms.
I am very happy with Mercurial for my purposes and I found it straight
forward to use. I consider it as a good candidate to look at when evaluation
a replacement for CVS.
Henrik
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Thiago A. Corrêa
On Sun, Mar 1, 2009 at 5:14 PM, Harald Kipp <haral...@egnite.de> wrote:
> Definitely. But we can be sure, that the Linux kernel development team
> don't use git because it is fashion.
Actually, they use it because they made it themselfs and it was
designed around their specific needs. The sending of patches around in
emails is very important to their development model, with different
maintainers, hundreds of specialized mailling lists, etc, while for us
it has never been. Patches are hard to come by, and often slip away if
not posted at the SF tracker.
> Yes and no. Definitely we have to make our own judgement. On the other
> hand you can't change a VCS easily so it is important to look to other
> project's decisions just to make sure that the selected VCS will have a
> long future.
Harald, that would be assuming that subversion developers counts how
many ppl use it and that they would just stop development had this
count gone down some magic number. That's not true, otherwise we would
have all moved to FreeRTOS (God forbid *smile*).
Ultimately it will be your decision as the project admin, but I hope
you take into consideration all of the raised points. IMHO, subversion
would serve us well and future support shouldn't be a concern if we
use it, since it is going strong.
Business will never switch to git for instance, as there is no user
control that we often require in the corporate world. Subversion has
it's own place, as has git or Mercurial and BitKeeper. There is no
reason to believe otherwise.
macs...@aol.com
We have an ethernut that we can program, but does not respond to either the serial port or the the ethernet port. It was working, and we had programmed it several times.
The red and green lights come on, but not the yellow.?
I have reloaded basemon.hex, but it does the same: no response on the serial port or the ethernet.
It does respond to the JTAG interface (using avr-dude). We can upload hex files, but they appear not to execute.
Any ideas?
Thanks,
Pete Allison
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Harald Kipp
macs...@aol.com wrote:
> (I've never gotten a response posting here, so I'm not expecting much....)
Sorry to hear this. I checked the archive and indeed there had been a
single reply to 4 of your postings.
Please have a look to
http://lists.egnite.de/pipermail/en-nut-discussion/2008-November/thread.html
Your posts are hidden within other threads. Many people use this
threaded view with their mail clients and may overlook your posting or
worse, may consider it annoying when appearing in a wrong context.
Quoting http://www.catb.org/~esr/faqs/smart-questions.html:
"Do not simply hit reply to a list message in order to start an entirely
new thread. This will limit your audience. Some mail readers, like mutt,
allow the user to sort by thread and then hide messages in a thread by
folding the thread. Folks who do that will never see your message.
Changing the subject is not sufficient. Mutt, and probably other mail
readers, looks at other information in the e-mail's headers to assign it
to a thread, not the subject line. Instead start an entirely new e-mail."
Beside that, your last post would have gained more attention of Ethernut
1.3 users, if it would have stated, that the problem appears on this
board version.
> I have reloaded basemon.hex, but it does the same: no response on the serial port or the ethernet.
Using Basemon to verify board function is always the best method. But
there are still several pitfalls like the terminal emulator connection,
the fuse settings and the power supply.
Make sure, that the jumpers are correctly set, as the "Important Note" at
http://www.ethernut.de/en/hardware/enut1/index.html
explains.
To make sure that your terminal emulator is working correctly, remove
the DB9 from the Ethernut board and connect pins 2 and 3. When typing in
the emulator window, you should see an echo.
Try another power supply. Make sure it is a DC type and provides at
least 9V under load.
Check the fuse settings
http://www.ethernut.de/en/isp/fuses.html
(Sorry, I do not have the avrdude values available right now, but should
be something like ext=0xff, hi=0x82 and lo=0x3f)
If all this won't help, please contact your dealer or write to info at
egnite dot de.
Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Harald Kipp
>> Yes and no. Definitely we have to make our own judgement. On the other
>> hand you can't change a VCS easily so it is important to look to other
>> project's decisions just to make sure that the selected VCS will have a
>> long future.
>
> Harald, that would be assuming that subversion developers counts how
> many ppl use it and that they would just stop development had this
> count gone down some magic number. That's not true, otherwise we would
> have all moved to FreeRTOS (God forbid *smile*).
Good point! ;-)
But probably I got your point more clearly. Several projects move away
from centric version control. I agree that this does not mean that
Subversion will die in the near future. I assume, that its user base is
still increasing. Btw. the ancient RCS is still in use today and running
fine on the latest hardware and OSes.
> Ultimately it will be your decision as the project admin,
Unfortunately yes. Unfortunately because making the wrong decision may
drive the rest of our community towards FreeRTOS. ;-)
Please do not miss my answer to Marti's post, which I will write now.
Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Harald Kipp
> Here's a few more points that popped into my mind why I prefer hg:
> * With SVN, if you try to commit to a repository that has newer
> changes, you have to merge local changes with HEAD before you can
> actually commit. This always seemed backwards to me, and tends to
> confuse people who are new to SVN.
I remember a cry out when I was a project leader many years ago, forcing
my team to switch from SourceSafe to CVS: "Editing files without locking
them will end up in total anarchy!"
In reality these conflicts are quite rare with small teams and, if they
appear, are most often solved automatically by CVS/SVN.
While following some discussions of the Mozilla project, I had the
feeling that the way such conflicts are solved with Mercurial was the
most confusing part for most developers. Not even one of the Mercurial
developers was able to explain the procedure in a few words.
Why do we move away from CVS anyway? It is very robust and relatively
easy to use. Well, the reason is, that SVN is even more easy to handle.
There is no other reason than that. I'm the one who currently creates
the branches, which is natural for a project leader and release manager
in one person. If I remember correctly, I'm also the only one
maintaining the branches, which is strange. I hope that Subversion will
attract more developers to take care of branches. But even if not, being
able to refer to a specific SVN repository revision would make snapshots
dispensable.
Why do we have snapshots anyway? Many of our "clients" are no software
guys. They have a hard job in learning C and version control, patches,
SSH or bug trackers are total mysteries to them. At least half of the
patches from people without CVS write access are posted as email
attaches, sometimes containing the full source tree.
IMHO it is most important to get more people involved in contributing
actively. In that sense, I think that nothing can beat the idiot-proof
update-edit-commit procedure of SVN, specifically in case of conflicts.
> * Having commit and push as distinct steps means that there's a window
> of opportunity to correct last minute mistakes. 'hg rollback' is handy
> for undoing the latest commit.
According to Murphy, mistakes are discovered after the push. :-)
A minor argument against Mercurial is its inability to convert system
specific line endings. That may not be a big deal for most of us, but
will be a needless annoyance for newbies.
Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Marti Raudsepp
> IMHO it is most important to get more people involved in contributing
> actively. In that sense, I think that nothing can beat the idiot-proof
> update-edit-commit procedure of SVN, specifically in case of conflicts.
Fair enough, thanks for considering the alternatives. :)
Marti
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
macs...@aol.com
Sorry, should have included the version, 1.3g.
We have not changed any of the jumpers. Like I said, it was working fine, I uploaded a new build, and it never responded.
We are using the SP Duo (?) cable and the PC's serial port with avr-dude.
Thinking back, it's possible that I may have carelessly connected the JTAG cable to the SPI connector on the board, although I have programmed it many times.?
I know it's not the other way around becase that SPI cable is folded up such that the connector is not accessible,?to prevent this.
If this is indeed what I have done, is the board repairable? avr-dude reports the fuses are okay. I'm pretty sure the power supply is okay. I did check the power supply fuse on the board, and it is okay. Also, I believe the clock is running on the processor, but I will check this again.
I will check them per the information you provided.
Thanks,
Pete Allison
Hi Pete,
Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Thiago A. Corrêa
On Mon, Mar 2, 2009 at 9:03 AM, <macs...@aol.com> wrote:
> If this is indeed what I have done, is the board repairable? avr-dude reports the fuses are okay. I'm pretty sure the power supply is okay. I did check the power supply fuse on the board, and it is okay. Also, I believe the clock is running on the processor, but I will check this again.
>
> I will check them per the information you provided.
>
As a rule of thumb, if you can read valid values from the board, then
both your MCU and your programmer should be Ok. It's possible that
only a peripheral of the chip could be damaged.
In your place, I would try to change the bootmon code just slightly to
toggle the working leds at points of it's initialization, to make sure
it's executing.
Perhaps someone else could think of an easier way?
Do you have an osciloscope? Could you probe the ethernet lines to see
if it's changing (atmega is trying to talk to realtek chip)?
Harald Kipp
> Thinking back, it's possible that I may have carelessly connected the JTAG cable to the SPI connector on the board, although I have programmed it many times.?
With Ethernut 1.3 Rev-G you can use either JTAG or SPI, both will work.
However, only one must be connected.
Plugging JTAG into the SPI socket or vice versa, which Atmel had made
possible by specifying the same form factor, will immediately blow the
overcurrent fuse.
This is not the case with your board, because LEDs are still lit.
> If this is indeed what I have done, is the board repairable? avr-dude reports the fuses are okay. I'm pretty sure the power supply is okay. I did check the power supply fuse on the board, and it is okay. Also, I believe the clock is running on the processor, but I will check this again.
avrdude will also report good fuses, if the ATmega103 compatibility fuse
has been programmed. But in this case no ATmega128 code will run
anymore. You have to compare the real fuse settings against the data
sheet. The avrdude manual explains how to read them out.
Again, if nothing helps, contact your dealer or egnite.
Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Harald Kipp
> In your place, I would try to change the bootmon code just slightly to
Bootmon, Basemon, who cares? ;-)
Basemon is a minimalist test application, which runs on AVR boards even
if the external memory bus is broken. It only requires a running CPU and
a working RS232 interface.
Bootmon, as you know, is an Ethernet enabled boot loader for ARM based
target boards.
Ah, btw. Pete: Did you use our pre-compiled Basemon binary?
http://www.ethernut.de/arc/
Basemon is critical and may not work with all compiler versions. So
better use a pre-compiled binary.
Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
macs...@aol.com
> Ah, btw. Pete: Did you use our pre-compiled Basemon binary?
No, I rebuilt what came on CD. I will get it and try it.
Thanks,
Pete
-----Original Message-----
From: Harald Kipp <haral...@egnite.de>
To: Ethernut User Chat (English) <en-nut-d...@egnite.de>
Sent: Mon, 2 Mar 2009 7:32 am
Subject: Re: [En-Nut-Discussion] Dead Ethernut
Thiago A. Corrêa wrote:
> In your place, I would try to change the bootmon code just slightly to
Bootmon, Basemon, who cares? ;-)
Basemon is a minimalist test application, which runs on AVR boards even
f the external memory bus is broken. It only requires a running CPU and
working RS232 interface.
Bootmon, as you know, is an Ethernet enabled boot loader for ARM based
arget boards.
Ah, btw. Pete: Did you use our pre-compiled Basemon binary?
ttp://www.ethernut.de/arc/
asemon is critical and may not work with all compiler versions. So
etter use a pre-compiled binary.
Harald
_______________________________________________
ttp://lists.egnite.de/mailman/listinfo/en-nut-discussion
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Pete Allison
I got the zip file (basemon.zip) from the archive. There is a bin and a hex
file. With my limited experience with embedded systems, I have only worked
with hex files. Are the files the same?
If not, how do I upload the bin file? Same as the hex?
Sorry for all the "newbie" questions. I really appreciate the help.
BTW, my hat is off to ALL who contributed to this platform. It will save us
mountains of money and precious time. Everything we needed, except for our
application specific code, is available in the distribution! I've written
protocol stacks in the past and was not looking forward to doing so again,
when we found Ethernut!
Pete
-----Original Message-----
From: en-nut-discu...@egnite.de
[mailto:en-nut-discu...@egnite.de] On Behalf Of Harald Kipp
Sent: Monday, March 02, 2009 7:32 AM
To: Ethernut User Chat (English)
Subject: Re: [En-Nut-Discussion] Dead Ethernut
Thiago A. Corrêa wrote:
Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Thiago A. Corrêa
On Mon, Mar 2, 2009 at 11:58 AM, Pete Allison <macs...@aol.com> wrote:
> Harald,
>
> I got the zip file (basemon.zip) from the archive. There is a bin and a hex
> file. With my limited experience with embedded systems, I have only worked
> with hex files. Are the files the same?
>
> If not, how do I upload the bin file? Same as the hex?
>
Yes, they are the basically same thing, except that the hex format
contains the address/offsets inside the file.
For example, the AVR32 flash starts at 0x8000000. So, to program those
with a bin file, one must specify that address to the programmer,
while the .hex already contains that information.
Bin file is usually usefull for the bootloader, as it's code can be
simplified by not having to parse the .hex format :)
Ole Reinhardt
> We have an ethernut that we can program, but does not respond to either
> the serial port or the the ethernet port. It was working, and we had
> programmed it several times.
Sorry, I can't realy imaging that or you'r the very unlucky one, who
fall through the cracks. In case of no response don't hesitate to check
back a few days later and to resend your question, perhaps with a short
notice like "urgent" or something similar in the subject line.
Sometimes, when there is much traffic on the mailing lists, some
questions get lost...
btw: I searched your last mails in my mail history and found, that you
sometimes answered another mail and just changed the header. In this
case the mail will be sorted into the mail-thread you ansered to and
won't open a new thread. Much people use the threaded view in their mail
client and not just sorted by date. So you question might got lost this
way too.
So I'll try to answer your old questions too in some more mails.
Now to your problem:
a.) First a question:
Which Ethernut board do you use? Have you just tried a build a short
program, that will just toggle an I/O pin e.g. every second? (Connect an
led to see if it blinks)
b.) If you use an AVR based ethernut. Have you perhaps enabled the
ATMega103 mode? (Check your fuse settings)
c.) Have you correctly configured NutOS before building?
d.) Which compiler version do you use on which platform? There was the
avr-gcc version 4.3.0 up to 4.3.1 which (at least on linux) produced non
working code.
In case you have this compiler version (check it with avr-gcc --version)
use a newer / older one.
> The red and green lights come on, but not the yellow.?
>
> I have reloaded basemon.hex, but it does the same: no response on the serial port or the ethernet.
e.) Have you pressed and hold down space on the serial terminal when
booting? Basemon will just talk to you, when it received the space key.
f.) Have you checked your serial settings of your serial terminal
program? Are you shure you have not enabled handshake?
g.) Try to clear the eeprom contents. You might got a non working
setting.
h.) Checking ethernet is not that simple if you don't know the IP
address you gave to the board. Try to use wireshark
(http://www.wireshark.org/) to sniff the ethernet traffic.
Bye,
Ole Reinhardt
--
_____________________________________________________________
| |
| Embedded-IT Hard- und Softwarelösungen |
| |
| Ole Reinhardt Tel. / Fax: +49 (0)271 7420433 |
| Luisenstraße 29 Mobil: +49 (0)177 7420433 |
| 57076 Siegen eMail: ole.re...@embedded-it.de |
| Germany Web: http://www.embedded-it.de |
| UstID / VAT: DE198944716 |
|_____________________________________________________________|
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Pete Allison
This was a working ethernut board. I had programmed it several times using
avrdude and a STK500 adapter using the JTAG programming interface. We have
not had any problems until now.
I can upload hex files, but the Atmel processor does not seem to execute
them. I believe the clock is running.
I may have carelessly connected the JTAG cable on the STK500 adapter to the
SPI connector on the ethernut board, instead of the JTAG connector.
I don't know if this has caused any damage. It's the only thing I can think
of.
I have reloaded basemon.hex, and I get the same response. Avrdude reports a
successful upload, that the fuses are okay, but the code never executes.
I did try the code in question on another ethernut board and it works fine.
I must have damaged it somehow.
BTW, don't spend anytime on my previous questions. I have figured most of
out them myself, the important ones, at least. Good learning experience.
Pete Allison
-----Original Message-----
From: en-nut-discu...@egnite.de
[mailto:en-nut-discu...@egnite.de] On Behalf Of Ole Reinhardt
Sent: Monday, March 02, 2009 2:39 AM
To: Ethernut User Chat (English)
Subject: Re: [En-Nut-Discussion] Dead Ethernut
Hi Pete,
Now to your problem:
Bye,
Ole Reinhardt
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Kevin Rock
Your problem sounds much like what I had a few months ago. I tried AVR Freaks and only got smart ass remarks. I tried this list and got no response at all. I figured I had blown the board so I ordered another one and a few other dev boards with the Atmel 128 chip on it. The Mavric board showed me my code was fine but the programmer code from the AVR studio was flawed. I had tried flashing the programmer but that changed nothing. I still could not program my Ethernut board. It was frozen. Then the folks who sold me the Mavric board helped me get it working with avrdude. Now I use the AVR studio environment to write code and debug but program the boards with avrdude. I have not touched my new Ethernut board at all. I am programming the old one now with avrdude and there is no problem. I just avoid using the programming software from AVR studio and I'm fine. You may want to check the fuses though. You may have reset one and locked the system.
Good luck,
Kevin.
From: macs...@aol.com
To: en-nut-d...@egnite.de
Subject: Re: [En-Nut-Discussion] Dead Ethernut
Date: Mar 1, 2009 10:02 PM(I've never gotten a response posting here, so I'm not expecting much....)
We have an ethernut that we can program, but does not respond to either the serial port or the the ethernet port. It was working, and we had programmed it several times.
The red and green lights come on, but not the yellow.?
I have reloaded basemon.hex, but it does the same: no response on the serial port or the ethernet.
It does respond to the JTAG interface (using avr-dude). We can upload hex files, but they appear not to execute.