another bizarre architecture
in [Embedded]
|
From: CBFalconer on 7 Feb 2007 23:35 rickman wrote: > CBFalconer <cbfalco...(a)yahoo.com> wrote: >> Didi wrote: >> .... snip ... >> >>> The most critical rule I believe I have defined for myself is >>> "never write at once more than you can hold in your head". >>> After debugging a piece which is < your brain capacity, move >>> on to the next piece :-). >> >> The corollary to that is "keep your functions short. One >> screenful is usually enough"/ > > Interesting. I was taught (back in the days of a CRT being a > separate entity from the computer) the screenful rule of "thumb". > But I have been working lately with Forth and am becomming a firm > believer in the smaller the routine, the better. This certainly > works in Forth and works well. These all derive from the functioning of the brain. It has been experimentally determined that the human brain cannot accurately keep track of more than roughly six or seven entities at once. This is known as the 'rule of seven'. -- <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt> <http://www.securityfocus.com/columnists/423> "A man who is right every time is not likely to do very much." -- Francis Crick, co-discover of DNA "There is nothing more amazing than stupidity in action." -- Thomas Matthews
From: Jonathan Kirwan on 8 Feb 2007 03:02 On 7 Feb 2007 17:52:33 -0800, "rickman" <gnuarm(a)gmail.com> wrote: ><snip> >If C had an easy way to interactively test routines as they were >written, I would say C was the clear winner (no stack to fuss with). ><snip> I'm not familiar with all c implementations, but Microsoft developed a QuickC program (I still use their v2.0 of that) and it allows similar debugging to QuickBASIC, which is okay. Also, there are several c interpreters out there, like Lua. These, I believe, allow you to test routines a little more conveniently than separate compilation/link/run does. (I don't know much about Lua, except that I've been interested to try it out at some point. As I read it, Lua is an extension language, has no notion of "main," only works embedded in a host program; the host can invoke functions to execute a piece of Lua code, can write and read Lua variables, and can register C functions to be called by Lua code. The free Lua distribution also includes a complete Lua interpreter as a separate program you can use to test routines, I think.) Jon
From: Jonathan Kirwan on 8 Feb 2007 03:11 On Thu, 08 Feb 2007 08:02:53 GMT, I wrote: ><snip> >(I don't know much about Lua, except that I've been interested to try >it out at some point. As I read it, Lua is an extension language, has >no notion of "main," only works embedded in a host program; the host >can invoke functions to execute a piece of Lua code, can write and >read Lua variables, and can register C functions to be called by Lua >code. The free Lua distribution also includes a complete Lua >interpreter as a separate program you can use to test routines, I >think.) Hmm. Never mind about Lua. It's not c. Just c-like. But there do seem to be other c interpreters out there that are c and not c-like, given some of the google results I've just skimmed. Jon
From: David Brown on 8 Feb 2007 03:37 John Larkin wrote: > On Mon, 05 Feb 2007 09:45:44 +0100, David Brown > <david(a)westcontrol.removethisbit.com> wrote: > >> John Larkin wrote: >>> On Fri, 02 Feb 2007 15:13:53 GMT, Vladimir Vassilevsky >>> <antispam_bogus(a)hotmail.com> wrote: >>> >>>> Jan Panteltje wrote: >>>> >>>> >>>>>> It is better to stay on the earth rather then fall on somebody's head. >>>>>> Masking the errors is the worst practice. >>>>> Yes that is true. >>>>> But you have to try one day to fly.... Errors will show you where to improve. >>>> Deadlines. That's another reason for the software to be the far from >>>> perfect. >>> >>> So, you will actually release software that you know is buggy, or that >>> you haven't tested, because of some schedule? Please tell me who you >>> work for, so I can be sure to never buy their stuff. >>> >> John, this is comp.arch.embedded - the answer is *always* "it depends". >> For some products, it is vital to hit the schedule - even if there are >> known bugs or problems. Perhaps you ship the hardware now, and upgrade >> the software later - perhaps you ship the whole thing even with its >> outstanding problems. For other products, you have to set the highest >> possible standards, and quality cannot be lowered for any purpose. I >> have no idea what sort of systems VV works with - they could well be of >> the sort where issues such as cost and timing are more important than >> quality and reliability. > > There are two methodologies to consider: > > 1. Write a lot of code fast. Once you get a clean compile, start > testing it on the hardware and look for bugs. Keep fixing bugs until > it's time that you have to ship. Intend to find the rest of the bugs > later, which usually means when enough customers complain. > > 2. Write and comment the code carefully. Read through it carefully to > look for bugs, interactions, optimizations. Fix or entirely rewrite > anything that doesn't look right. Figure more review time than coding > time. NOW fire it up on the hardware and test it. > > Method 2, done right, makes it close to impossible to ship a product > with bugs, because most of the bugs are found before you even run the > code. Nobody can walk up and say "we have to ship it now, we'll finish > debugging later." > > Method 2 is faster, too. > > John > Method 2 is an ideal to strive for, but it is not necessarily possible - it depends on the project. In some cases, you know what the program is supposed to do, you know how to do it, and you can specify, design, code and even debug the software before you have the hardware. There's no doubt that leads to the best software - the most reliable, and the most maintainable. If you are making a system where you have the time, expertise (the customer's expertise - I am taking the developer's expertise for granted here :-), and budget to support this, then that is great. But in many cases, the customer does not know what they want until you and they have gone through several rounds of prototyping, viewing, and re-writing. As a developer, you might need a lot of trial and error getting software support for your hardware to work properly. Sometimes you can do reasonable prototyping of the software in a quick and dirty way (like a simulation on a PC) to establish what you need, just like breadboarding to test your electronics ideas, but not always. A "development" project is, as the name suggests, something that changes with time. Now, I am not suggesting that Method 1 is a good thing - just that your two methods are black and white, while reality is often somewhat grey. What do you do when a customer is asking for a control system for a new machine he is designing, but is not really sure how it should work? Maybe the mechanics are not finished - maybe they can't be finished until the software is also in place. You go through a lot of cycles of rough specification, rough design, rough coding, rough testing with the customer, and repeat as needed. Theoretically, you could then take the finished system, see what it does, write a specification based on that, and re-do the software from scratch to that specification using Method 2 above. If the machine in question is a jet engine, then that's a very good idea - if it is an automatic rose picker, then it's unlikely that the budget will stretch. I think a factor that makes us appear to have different opinions here is the question of who is the customer. For most of my projects, we make electronics and software for a manufacturer who builds it into their system and sells it on to end users. You, I believe, specify and design your own products which you then sell to end users. From our point of view, you are your own customers. It is up to the customer (i.e., the person who knows what the product should do) to give good specifications. As a producer of high-end technical products, you might be able to give such good specifications - for many developers, their customers are their company's marketing droids or external customers, and they don't have the required experience. As a developer, you can do the best you can with the material you have - but don't promise perfection! Programming from specifications is like walking on water - it's easy when it's frozen.
From: David Brown on 8 Feb 2007 03:56
Jonathan Kirwan wrote: > On Thu, 08 Feb 2007 08:02:53 GMT, I wrote: > >> <snip> >> (I don't know much about Lua, except that I've been interested to try >> it out at some point. As I read it, Lua is an extension language, has >> no notion of "main," only works embedded in a host program; the host >> can invoke functions to execute a piece of Lua code, can write and >> read Lua variables, and can register C functions to be called by Lua >> code. The free Lua distribution also includes a complete Lua >> interpreter as a separate program you can use to test routines, I >> think.) > > Hmm. Never mind about Lua. It's not c. Just c-like. But there do > seem to be other c interpreters out there that are c and not c-like, > given some of the google results I've just skimmed. > > Jon Indeed, Lua is not C. It is basically an interpreted scripting language (although you can have bytecode compilation, like Python or Java), implemented as a library to be linked into your C program. It's easy to make your own modules that expose your C functions and data to Lua. The library is quite small (especially with the patches to use integers instead of floats for all numbers) - if you have a 32-bit micro then you should have plenty of power even with just on-chip memories. Connect the Lua interpreter to a serial port interface, and you've got an extendible programmable command line interface into the heart of your program. I've done this a couple of times - I should get in the habit of doing it more. |