I have this feeling that I have given away one of my best ever product ideas. I'll expect royalties from anybody who profits from it. ;-)
Hmmm... It seems to me that the cost of the slides is in producing them and is incurred regardless of whether they are shown in a meeting, so I wouldn't add their cost to a clock that measures the cost of a meeting. I mention this primarily to provide an example of how easy it is to generate design errors without complete problem analysis.
--
========================================================================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
mkesti@gv.net | - The Who, Bargain
For normal slides, that would be correct --- and the cost would be amortized over many meetings, as the slides are recycled, so it would be unjust to count it as an inherent cost of the individual meeting.
But the grandparent spefically talked of PP slides. Those extra $100 are costs, but they're too indirect to be obvious. They're actually compensation for damages done to the audience during the meeting. So they should be proportional to the number of attendees, too. For better effect, add punitive damages per different colour and per different font used, and double the resulting fee for every completely superfluous animated effect.
-- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
How about a $50 penalty for using the word 'Leverage'? Unless the meeting is about moving things about using large bits of metal of course.
Andy
"Andy Sinclair" wrote
So, you're saying that after the meeting, everybody should stick around?
My first reaction to the _time is money meeting reminder machine_ was that meetings are where all the important work gets done. I know I'm gonna get shot for saying that. Really, I would have kicked myself in the arse if I weren't sitting in a chair.
Then again.... nevermind. Here is a holiday poem for the overly embedded mind.
If the ocean were vodka And I was a duck I'd swim to the bottom And drink my way up
But the ocean's not vodka And I'm not a duck So pass me the bottle And shut the hell up!
Happy holidays, everyone. Enjoy your families and don't bother building temperature sensors into the cocoa cups.
Mike
I imagine they'll want to have a meeting first to discuse it. D'oh!
If they are shown, every slide should reduce a bar displaying the average effective IQ in the room. Once it drops below a safety set-point, the fire alarms should ring to evacuate -- hopefully everyone will still remember what the warning is for.
-- Ron Sharp. FLASH! Intelligence of mankind decreasing. Details at ... uh, when the little hand is on the ....
There seems to be a lot of anger in this group regarding meetings.
Many years ago, when I first began consulting, a client took me aside, and pointed out that one of the responsibilities of a consultant is to bring some discipline to meetings. Remember that outside help is often hired because the inside crew is bogged down. But also keep in mind the general principles laid out in Gerald Weinberg's "Secrets of Consulting" -- they're as valid today, as when first published.
If you take some control over meetings, you may find them less hateful, and far more productive. And your client may even thank you for it.
-- Bill Posted with XanaNews Version 1.15.8.4
Do you have any data to support this guestimate?
Correct me if I'm wrong but the original post this thread responds to is by a self-professed amateur. Besides, there are more than a few commercial products being used, like the Parallax family, in Basic. Again, I'd have to ask for some data to support this guestimate.
On most micros however there is no correlation between the number of developers using Forth and the number of embedded control projects in use.
-- -- Regards, Albert ---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts http://www.amresearch.com 916.780.7623 ----------------------------------------------------------------------
In article , Albert Lee Mitchell writes
Yes. Several studies dating from 1997. I could dig out the results but since Forth and basic don't appear in some of them I doubt you would accept them.
So? That is no reason to use it. There are plenty of C tools and support available from the free to the very expensive. The point is that there is a LOT of support for C for all levels. There is no need to tie one self down to a less appropreate language just because some ametures use it..
This is true. The amount of forth in use probably dwindles even more if you look ate the number of projects or indeed the number of installed devices.
I have nothing against forth but an ammeter will get fat more help and support (and tools) on a far wider variety of micros and application types that he could from forth.
This is probably more relevant.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org
I have no experience with the Hitech compiler nor with PICs, but Step 3 is not typical in any of the many development environments I have used. The compiler should be responsible for its own optimizations. Even in unoptimized mode there should be few if any truly "extra" lines. The worst part is that doing this seperates ones source code from the object code it represents. This makes development and maintenance far more difficult.
The only time I have done this kind of thing is when I used C as an algorithmic starting point for a function that I knew would have to be extremely optimized for speed. In this case, only the assembly source was used in the release build and the C source was included only as comments in the assembly source to document the technique.
--
========================================================================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
mkesti@gv.net | - The Who, Bargain
Hi, this is the problem with C on these small micros (1 of the problems anyway). Dump it and go back to using the free assembler.
or
I am under the impression that the basic compilers/interpreters are good tools for people who have an objective but don't want (or can't) get too deep into the understanding of controllers, etc. Builders of model robots and the like do pretty well with the parallax stamp. It is also a good product for mechanical engineers, scientists, etc., who want to accomplish tasks that are appropriate to those kinds of products without going overboard in terms of having to learn to program in C or asm. -- Mike
If you're trying to pass off compiler output as assembly-language homework, as I suspect the OP might be doing, there probably will be "extra lines" ;P
pete
-- pete@fenelon.com "There's no room for enigmas in built-up areas."
In article , Mike Turco writes
Several sets.
The one below shows C at 80% in 1997... the use of C in embedded work has not deminished. BAsIC and PL/M have declined. C++ increased.
I can dig out other surveys etc but most are in hard copy. this one was electronic.
From: Bill Giovino Subject: Re: Embedded Systems development languages? Date: Sat, 04 Sep 1999 Organization:
Re: Embedded Systems development languages?
That has a one-letter answer: C. I would guess 75% of small-to-medium- scale projects are done largely in C, occasionally with small hand-coded sections of assembler. Another 20% in assembler and Forth, and the rest in obscure languages for certain esoteric applications. Programmers often claim to write these programs in C++ but their coding style is generally just 'straight C'; they just happen to be using a C++ compiler. A bigger project, running on PC-like hardware, is a different animal and genuine object-oriented C++ Would probably be the language of choice. A very small project (less than about 1K of code) will more frequently be written in assembler, purely because the processor it's running on will be so small that hand-optimisation will be necessary.
This information is from 1997: Programming Languages used in Embedded Development: C 80% Assembly 75% C++ 49% BASIC 15% Fortran 8% ADA 6% Java 4% Forth 1% PL/M 1% Other 2%
This is from a representative survey of 233 software engineers over various markets. Note that this does not add up to 100%, as more than one language may be used on a project... Embedded C++ was not broken out from C++.
Many surveys ask engineers what language they would be using 2, 3 years out. In my opinion, those numbers are worthless - any engineer will tell you he hopes to be hopes to be using the latest programming language!
80% of you are using fuzzy logic, right?-Bill Giovino
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org
three
That wasn't my question and I doubt that you and I would have any disagreement regarding this matter. I don't doubt what you are saying about C being the prevalent language. It beats basic, hands down, when it comes to doing serious work with controllers. However, there are many instances where C is not required. Basic is a good general purpose tool that bridges the gap for people who aren't necessarily f/w or h/w folks, but need to accomplish specific tasks.
Plus you will learn a *LOT* more about microprocessors writing in Assembler
- of course you can also learn a lot of patience and humility trying to sort out compiled code in assembler ;)
You will find articles about real-time and embedded software design at:
Sandeep
--
---------snip------------
Yes, it is a reason unless you are pursuing your own agenda. The gentleman originating this tread asked specifically for "amateur" help. C is not for amateurs and arguably not for low-level embedded applications. At least not with optimization turned on.
Dogma again. Forth is a well-hidden trade secret by most of my clients. There is no way, again, that you can supply any meaningful statistics so please discriminate between your opinion and reality.
Huh? No tool is better than it's user. Again, the number of products has no correlation to it's quality. Hmmm, a pattern is emerging here. Instead of pushing your agenda why not give cites and evidence and let the reader and original poster decide?
-- Regards, Albert
---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts
----------------------------------------------------------------------
I think you miss his point. I suspect he means the number of *users* who can provide support via forums like this is greater.
Ian
In article , Albert Lee Mitchell writes
That is not true.... C is taught to 16 year olds at school. C can be used by anyone. In fact one "amateur" I know is on the ISO C working group.
Then you are disagreeing with a LOT of professionals who use it for all sorts of work including safety critical and medical from 8051's and Pics upwards.
Not that you have a hidden agenda for going against the majority of professionals and ammeters who use C.
I don't suppose you are commercially involved with Forth and Basic tools?
I can dig them out... (again) I think it was 80% using C and Forth and Basic around 10% about 5 years ago.
Basic usage has dropped (as have the number of supported tools) Forth? You would know about that better than I as it is YOUR agenda but I would bet it is not gaining in market share.
This is true.
Correct but in a large number of products there will be good ones and cheap ones and good cheap ones and probably several that are just right for you with a large users base you can cal on for help.
Where there is a choice of 2 or 3 with a small(er) user base the choices are far more limited. Also with fewer users the tools tend to get less usage and testing.
Please do. It appears you have an agenda of pushing a language you support commercially. Lets throw it open. How many forth tools and users are there out there?
I don't suppose you represent a company that is pushing forth and basic
?/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org
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.