I rarely ask questions on this forum, but since I couldn't [easily] find it in the help-files, or on-line, I'm asking you guys.
I usually (like never) don't use the 'reentrant' pragma, but I think I may have to do that with a particular routine.
BUT I can't find the key-word that declares a function as reentrant. Am I missing something? Is there one for Keil's IDE tools? If so, what is its form? Can I get a link to the 'official' use of it?
Thanks in advance, and I need it asap because I need to pass this class and I don't want to really learn how to do this 'embedded' stuff anyway but the teacher keeps hounding me.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
"I think it's the strange hobby projects that teaches us the most - there are no natural limits. No teacher who says: This is enough. No customer who say: Too big or expensive or too late delivery date or too weird."
My home has an office with a full elex lab in it. Over $100K in [legal] software, and plenty in hardware tools. I don't do "hobby" things there. ("PICs are for kids"). I do 'real' projects... when I have the time: I have kids.
Growing up, my summers were spent on my grandparent's ranch (10,000+ acres), and my grandfather taught me many things.
One of which was simple: "If you are going to do something, do it right."
From logging, to raising live-stock, to building fences to building barns, to building embedded systems, that rule always applies. If you half-ass it the first time, you'll--by far--spend more time and money getting it to work right later.
The luxury of time and money does allow you to do it right, so Per's comment is very apt. But most of these "hobbyists," don't take the time (money is always an issue), to do it right.
*IF* they do it right, they'll learn a lot the 'easy way' versus learning the 'hard-way' with band-aid patchworks, ad-hoc 'goto' statements, and ill-conceived pre-planning.
In the real world, time & money are always pressures you must achieve. Doing it right the first time might seem to take 'too long' so its best to have a work environment that knows this rule and knows just how much more time and money is spent if you don't take the time to do the up-front [real engineering] work.
I don't know the number of times I have had to fight quite hard to get a design passed, because it has been seen as too ambitios.
On the other hand, I don't know the number of times that extra layer of maturity (general transfer protocols instead of minimalistic ones, separation of business logic and peripherials, ...) in the product has proven extremely valuable down the road when a customer has suddenly wanted big additions very late in the development cycle, or maybe even in products already installed in significant quantities.
It's actually quite interesting to compare how some of the products are used, and relate back a couple of years to the originally planned uses. A couple of weeks ago, a customer managed a very quick and smooth certification of one of our products as a fire alarm system after very minor firmware updates. A fire routing equipment is of course not as sexy as some of the more advanced equipment in avionics, but I'm still quite happy to be able to take a product with a number of man-years invested in the software and do a couple of weeks of minor adjustments to fulfill a standard no one ever mentioned or talked about during the original design stage.
In the military world, I would expect the designers to have a quite good view of the intended use. There isn't a week when there isn't a phone call from a customer asking "Can I use it as a xxx" (insert weather station, corporate firewall, redundant oil rig communicator, burglar alarm, supervisor of cellular base stations, POS terminal, econometer, route planner, data collector, PLC, passenger comfort supervisor, crash recorder, vehicle PC, vehicle radar, replacement for fixed phone lines, bus schedule predictor, info-sign controller/driver, talking sign, customs seal processor, money/weapons/valuables tracker, blue-light emergency recorder, ...). And that is just some of the saner requests - most delivered or quite likely to be delivered - for one single base product.
It is quite funny to try to design hardware and software when the world is so full of people desperately willing to find new, and totally unplanned, uses for a product. In the end, every little innocent source line may be a potential show-stopper - or the deciding factor that convinces a customer to select the product.
Sorry for the previous rambling. What I wanted to say was probably not possiby to deduce from the text.
In school, it is possible to guestimate the minimum requirements needed to get passed. In real life, it can be very hard to know what the minimum requirements are. At the same time, there is the business aspect that money invested should pay off. It's tricky to know how much to invest when you don't know if you will get any interested customers - or what they will be interested in.
Yes, in the Aero/Mil industry things get well defined and 'new' features are rarely added without a big deal being made. Yet still those little features added still occur... and often.
As a boss of mine said (known as Miller's Law):
"Resist All Temptation to Increase Expectation"
Which meant not to imply to the customer that you can do this or that just because you know you can... they'll just expect it for free.
In the R&D missile business, we're doing stuff that we don't know for sure if it will work even deep into the design cycles. That "MRM" (XM1111) project was a killer because we (I) had to fit 10 pounds of circuitry into a 1 ounce PWA. It was 'theoretically possible' but there are real-world aspects that were high-risk. But the MRM worked and we (not just me) made it work PERFECTLY. Excalibur (XM982) was similarly hard.
Jobs that have ever-changing criteria are nightmares to deal with. So the more practical solution (in low-volume cases) is to over design it to be capable of expansion if needed. Then when that feedback comes in on how it is used, you can do a cost reduction and re design it for those high-volume jobs.
I just want you to know, that 'sexy' R&D missiles and what you do Per are really the same thing. The only differences could be the funding and the amount of paperwork and qualifications the widgets need to go through. (Assuming that you also do that real engineering work up front, which I think you do indeed do).
And don't worry about 'rambling' because I'm the worst offender of it.