Your wish has been granted:
There are (were?) a few other more or less completed C interpreters. From memory, (not time to search now,) there was one included with CERN's Root project, the UPS debugger, Instant-C mentioned elsethread, etc.
Roberto Waltman
[ Please reply to the group, return address is invalid ]
The way I heard it was that this is the number of objects that you can look at and *know* instantly how many there are, without actually counting them. I use this sometime when counting out parts that are say scattered on a table. I can "count" them 5 at a time, no matter the configuration of each group of 5.
If you recall in the movie the "rain man" could do exactly this, but with hundreds of items. I can just manage 5...
-- John Devereux
improve.
There's no doubt that the task to be performed may change; it usually does. But that doesn't mean you have to use Method 1 on whatever code is changed. On the contrary, the easiest way to create bugs is to dash off quick changes without taking into account the entire context and interactions. A change in the spec is no excuse for abandoning careful coding practices.
What we do is write the manual first, and get the customer to agree that's what he wants, and use the manual as our design spec. Changes may still happen, but the mechanism is to edit the manual and get agreement again, then change the code. Carefully, without hacks.
And, when we're done, we have a manual!
The surest way to have bugs is to assume their inevitability. We expect, from ourselves, perfect, bug-free code, and tell our customers that they can expect bug-free products from us. When people say "all software has bugs" it really means that *their* software has bugs.
John
That's correct, I missed the point on being embeddable. Still, I used it for a while (Linux version) and found it useful to quickly write and debug small programs, (that could then be recompiled for an embedded target.)
Roberto Waltman
[ Please reply to the group, return address is invalid ]
I don't like interrupts. The state of a system can become unpredictable if important events can happen at any time. A periodically run, uninterruptable state machine has no synchronization problems. Interrupts to, say, put serial input into a buffer, and
*one* periodic interrupt that runs all your little state blocks, are usually safe. Something like interrupting when a switch closes can get nasty.John
Not an endorsement, I've never used this.
-- John Doty, Noqsi Aerospace, Ltd. -- Specialization is for robots.
There is also something called ch. Seemed quite useful when I tried it a few years ago.
--
"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
which is, of course, event driven software. which is (AIUI) what windows is all about. perhaps that explains it.
Cheers Terry
Polling at, say, 1000 times a second is plenty fast enough to save an engine, if it can be saved. In the case of an overspeed, the actual rpm limit check would be done in software, so there's no overspeed interrupt as such. If you snap a shaft in the hp stage of a big steam turbine, the blades *will* fly off before you can close the steam valve.
No, but I almost ripped a ship off the dock at Avondale Shipyards, on the Mississippi. I got it up to almost 60 RPM while tweaking a nonlinear function generator (120 RPM is full power.)
We are doing overspeed trip stuff these days. That's scairy.
My customers do deliberately destroy a jet engine at full speed, to make sure the blade containment is adequate. The big commercial jet engines have a huge band of epoxy-kevlar wrapped around the front of the engine to catch the big (~~12 foot) fan blades.
John
I have spun communication satellites on a test stand at Honeywell Satellite Systems Division.
I stood behind a huge building pillar in case it decided to do untoward things ;-)
...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice:(480)460-2350 | |
| E-mail Address at Website Fax:(480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food.
I suspect you would have likes the NS32000, 32 bit, 16 registers, hex assembly, near perfect instruction set symmetry. real purty in my book.
-- JosephKK Gegen dummheit kampfen die Gotter Selbst, vergebens. --Schiller
"[..]
Deadlines. That's another reason for the software to be the far from perfect.
[..]" John Larkin replied:"So, you will actually release software that you know is buggy, or that you haven't tested, because of some schedule? [..]"
In 2001 I learnt that the Rosetta spacecraft of the European Space Agency (
Regards, Colin Paul Gloster
Interrupts should normally only be used when polling is unsuitable - either because you need fast reactions, or because you don't want to have to add polling mechanisms. I've seen programs where pressing a switch triggers an interrupt causing action such as messages on a screen, which is daft. The person pressing the switch will not notice the delay polling would cause, it completely messes up the timing of important interrupts, and can cause conflicts between the main program loop (which may be writing to the screen at the time). Very bad.
On the other hand, I often use a software timer setup where program modules can register a function to be called regularly in the background. When the hardware timer underlying this system times out, it's interrupt handler calls all the pending software timer functions after first re-enabling interrupts. In this way, I can have predictable periodic functions that may take significant run time (though less than a timer tick in total) without affecting fast interrupts, and without having to be polled in the main loop. Of course, sometimes the timer function merely sets a flag that *is* polled in the main loop - it depends on the situation. I've even had programs where the main loop is nothing but a "sleep" instruction, with everything handled in interrupts this way.
improve.
Indeed - I am not advocating Method 1, just saying that a pure Method 2 is not always possible or even appropriate.
On some products, we can do that - and there is no doubt that it is best for everyone when that is the case. Unfortunately it is not always possible - it depends highly on the customer, the type of project, and limitations such as time and budget.
I mostly agree. There is certainly no excuse for saying that all software has bugs - and there is no reason for coding in a way which makes bugs almost inevitable. But on some sorts of systems, you *do* have to assume that there may be bugs in the software. To a fair extent, it does not really matter if the failure is due to the software, the electronics, or outside effects (unexpected temperature changes, physical damage, cosmic rays, or whatever) - you have to assume the possibility of the control system failing. That's all part of risk analysis.
Bug-free code is about quality. Top quality products cost time and money, and are thus not always appropriate - "good enough" is, after all, good enough. Perhaps they will save time and money in the long run, but perhaps not - and perhaps the customer has little money at the start and would rather deal with long term costs even if they turn out to be higher. For some jobs, the appropriate quality for the software is zero bugs, but in many cases you can tolerate minor flaws as long as the job gets done. The real dangers with software bugs, unlike other flaws in a system, is that they are often hidden, and they can have unexpectedly wide consequences. Modularisation and isolation of software parts can be a big win here - your critical control loops can be bug-free, while glitches in display code might be tolerated.
"There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C. A. R. Hoare
Don't worry about Vladimir. He is the next thing to a troll. I think he really does believe what he says, but he is not very tactful and often misinformed. But what he says works in his little world. So be kind to him.
You must be joking? While event and interrupt are quite different things, to claim that windows is "event driven" with its many seconds range latencies is laughable at best. A wanna-be event dirven, may be :-).
Dimiter
------------------------------------------------------ Dimiter Popoff Transgalactic Instruments
------------------------------------------------------
I never said it was good, and the last bit ("perhaps..." et al) is indicative of my low opinion of windoze.
[snip]tell me about it. A couple of years back I developed some testers that used a PC to talk to a range of little blue I/O boxes. The PC(s) were >=
1GHz pentiummyjigs, and our pc guru (who is good) couldnt even get a guaranteed 1ms interrupt out of the poxy OS.Cheers Terry
I thought this was the case, although I now see my posting did not show it.
Oh I am sure nobody can even dream of 1mS latency with windows. Some time ago, when they had only NT, a guy told me 22 mS was the best achievable (he was living in a windows world, though, so I don't know if this was possible or wishfull thinking).
Dimiter
ISTR thats about what chris offered me. absolute shit, even a poxy PIC can do better
BTW, if you want to top post, snip out all the other stuff - there was enough in your top post to make it all superfluous. that way us bottom-posters dont have to :)
Cheers Terry
"Event driven" is a classification of how something operates. A "Pinto" was a car. Windows uses the event FIFO model. This ensures that the events are taken in turn. It doesn't ensure that they are acted on quickly. This model actually makes it harder to react quickly to events but it saves having to implement event commutation. Consider this happening:
Disk operation complete Mouse moved to the right 10 mickeys Printer port interrupt Serial interrupt Mouse button clicked
You can safely move the mouse action down the list to after the serial interrupt. In an interrupt priority system it could be. Windows, however can't easily do this sort of thing,
-- -- kensmith@rahul.net forging knowledge
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.