Simply stated, any program that doesn’t please the user is poor quality.
I’ve been using OCD almost since the day it was released to the public. At svn263, we were satisfied that it did all we needed - flash parts, provide a gdb interface, and provide watchpoints. So we froze the config file and no longer updated OCD. At the same time we froze the other tools – gcc, as, ld, binutils, gdb. There nothing worse than updating development tools because even regression testing won’t catch all the bugs that may be introduced by a new compiler or linker.
Recently I updated to Ubuntu 9.10, and along the way lost some libraries that OCD depended on. So rather than try to resurrect the old system I just installed OCD using synoptic, getting version r2403-1.
After many hours of searching for information about all the old commands that are now unknown, I managed to get the Amontec tiny talking to my board. I didn’t find any official documentation that was any different than the frozen-in-time tutorial, just some snippets here and there on the web.
I’m not sure it’s programming properly because it gives me this error: "Verification will fail since checksum in image(0xe1a00000) written to flash was different from calculated vector checksum(0xb9205f80).
To remove this warning modify build tools on developer PC to inject correct LPC vector checksum."
I haven’t changed the compiler or linker, since they too were frozen at the same time OCD was frozen. Am I expected to figure out why tools that have worked for 3 years need to be modified because OpenOCD is doing something different?
I’ve been writing software for embedded systems from before the start of Unix design, well before C was available. In all that time, two rules have kept code jockeys under control.
If you’re going to change something, write the documentation first.
If your changes break anyone else’s code, you have to fix it.
No one expects open source programs to be commercial quality, some are better and a great number are worse for the simple reason that user documentation isn’t a concern.
As it turns out I was able to revert back to using the frozen version of OpenOcd quite easily, so I’m back to my working config files.
As someone who has written a lot of embedded code, some of which has been used in extremely dangerous process control systems, freezing the development tools before the first code release is a `best practice’.
smead:
As it turns out I was able to revert back to using the frozen version of OpenOcd quite easily, so I’m back to my working config files.
Congratulations, then you can evaluate the new version on a parallel track and find out how you need to change your config files without any panic.
smead:
As someone who has written a lot of embedded code, some of which has been used in extremely dangerous process control systems, freezing the development tools before the first code release is a `best practice’.
True, that is one variable.
And a known bug is easier to handle than a unknown one.
But I was thinking about the time “between” or in the beginning of a new project.
You need to check for updates at some point in time,
