@Gary - Yes that is the typical demeanor of engineers and managers. But here is the lesson I learned at my first job out of college many years ago... I had to write project specifications, which were packaged for contractor fixed-price closed bidding. After selecting the lowest-bid contractor, and after the work had started, somebody in our company would want a specification modified or something new added to the effort. When I approached the contractor about it, it was always the same – "Here's how much time we'll need to extend the contract and here's your new bid for the contract modifications. Send me the contract addendum when you're ready."
Well, now it's not a contractor doing the work – it's my engineering team and me. So, it's like you said, I have to give management the same spiel as the contractors those many years ago. When I put it in those terms, suddenly it's more than just a memo from a manager telling me to add this or modify that.
@edeanda - I can't tell if you are asking about aids for following these methodologies or aids to maintain registers. So I'll answer both questions. For following these methodologies, my book has all these principles and best practices listed in them and the book includes an excel spreadsheet of the best practices so that you can track them. For maintaining registers, use a Register Design Tool that I talked about in Tuesday's lecture.
Because of the way the engineering culture is, it is often very difficult for engineers to say "no" to feature creep. Engineers tend to be introverts and managers tend to be more extroverts. Engineers need to tie the new feature requests to time and cost. What are they willing to give on? Push out the schedule or drop other features?
I'm a Systems Integration Test Enginner: I've tested both new and old versions of hardware for compatibility with New Firmware and Software prior to final release for field testing. Having to please my manager and all other team members was a fine-line in the sand. The feature creep is one that is very problematic with older hardware which we would have keep the old rev in operation for specific customers until they were able to certify tand upgrade all of the systems to the latest and greatest one. I finally had to dig through all of the system firmware and software level changes in the past to find out where it got broken and then recommend to not use that version of hardware with any newer released software versions. The cutoff point was always a difficult point with the management and sales peaople who wanted to pleease the customers by keeping the older hardware in operaition.
Thank you Gary for the Great presentation. I don't have any questions. I am already a believer of the points you made in this lecture for all my designs. I always make sure my hardware works before giving it to the SW engineers.
@GARY: Your advice on how team members can influence decision makes to INVEST in best practices. More often than not, employers are harsh on their expectations and don't want your to "waste any time" on "untangibles". Their only principle is: Just do it, and quick.
Awhile back encountered a commercial video interface device which had a completely-free-form ASIC which was essentially "booted up" and configured on-the-fly as the DSP/processor/etc -- ever encounter one of these which allows a secondary "diagnostic" bootup option?? Seems obvious, but...
New tools: we plan to upgrade our source control system, but that's it. We could use an improved methodology for h/w-s/w group interaction, but that's more a group organization thing, than a tools issue.
Feature creep: Yep. Seems like there are often good things to add, that should be added. Some things - no way. Maybe more careful thought up front would capture those things. But there is always an urge to just get started and add as you go.
@Alex – Feature creep...This is more the rule than the exception.Managers, sales people, marketing people, etc. love to change things after the fact.They think nothing of it.They usually wait until something in the design is done, which acts as the design's steering mechanism.To change this foundation causes a major re-design effort.But to the marketing/sales people, it means nothing but a memo.Isn't afterthought just wonderful?
Using in-memory semaphores to communicate between different processors is SIMILAR to what you're describing re multiple processors/drivers accessing the same space. Opens up HUGE problems if you don't enforce a disciplined approach...
@Gary – Concerning shared purpose registers...Yes, I have encountered.I'd rather avoid it.However, speaking only for myself, it's no big deal.For me, it's routine to use AND and OR masking anyway for accessing specific bits in registers.
With the increasing availability (and therefore reduced cost) of DSP chips, and of GPUs, at some point seems like the "balance" kinda tips toward "Do as much as you can in software, but the hardware will 'deal' with whatever is left over"...
Golf?? No. Golf is for people who don't have a gut feel for statistics (or sales people).
Good afternoon to all. Let's see -- predominantly hardware: project, proto, product; with more than enough software to make the hardware walk, talk, sing, see, hear, communicate, be testable with embedded diagnostics -- AND to (generally) be profitable. Currently seeking gainful employment AND contemplating/researching a wide range of possibly lucrative projects. Last time I checked, it's in the mid 80s outside, on its way to the mid 90s. Anyone here into "designer materials", like aerogels, graphene, etc? Anyone check out that LEAP product re input device with 0.01mm precision in 3D space? Any more recent signs of the Singularity? Pure synchronicity says the Mayan calendar just might have THAT pegged. Could be. Time for lunch, my blood sugar is obviously a bit low. See you guys shortly.
Festo's BionicKangaroo combines pneumatic and electrical drive technology, plus very precise controls and condition monitoring. Like a real kangaroo, the BionicKangaroo robot harvests the kinetic energy of each takeoff and immediately uses it to power the next jump.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.