@flaredOne - If they try to pass off saying that this like the previous with these changes, then say, let me see the previous. If they give you something, then mark it up and reject it saying, insufficient. We won't approve your design.
@MazianLab - Our special debug team of about 10 engineers spent 2 months chasing down a nasty problem that the vendor knew about but decided not to tell us about it because they hadn't heard that we were having problems in that area. Well, duh! We didn't tell them because we didn't know the problem we were chasing down was from their stuff! So, yes, be proactive and notify customers of changes/new information.
@els_h - You can have hw and fw on the same team but that generally doesn't happen because of the signficant differences in tool sets, life cycles, and skill sets between the two. There's pros and cons both ways.
@GStringham, having an indexed/cross referenced list of registers for a MPU or embedded controller would have been wonderful. Digging through a MPU data sheet to find a register function interaction problem is painfull, even a PIC 16F88 has 158 pages of data sheets! A control register for the low voltage programming option pestered me for weeks in an intro progrmming class I taught until I found the note deep in the spec. MPUs and uCs the designer needs to be a good spec reader and researcher.
@jl - I like that one block has its own interrupt module with many interrupts. Each error condition gets its own interrupt bit. Then each block with their own interrupt module feeds into one bit each at a chip-level interrupt module.
@MazianLab - Having an outsider read the doc is a good idea because the outsider doesn't know what the writer meant. Now, what's an outsider? It may be someone on a different team but still within the company to keep the contents internal.
@flared0ne - Sorry the zoom level didn't do the trick for you. I'm wondering now if you might have accidently deleted some characters without knowing it. You could always download the file again to get a fresh start on it to see what you have. It still seems you should be able to zoom out on the slide and see it all. If you perform a zoom, you should probably NOT have an active cursor within the slide. I hope you can figure this out. You never know when you might lose something important.
@LevitonDave - The Register Design Tools are primarily for when hw is being developed. If you are buying off-the-shelf MPUs, then that doesn't apply. Although I have suggested that companies who design and make off-the-shelf chips use these tools to make the sw and documentation files to give to their customers.
@Ran, thought you had it, but no -- I click internal to the slide, I can arrow-key around -- and there are only missing characters, no invisible characters. In THIS case I can survive. Particularly since you DID explain what I was seeing. Thanks.
@GARY: I'm sorry to disagree with what we "have learned in school to first write the code". It happens that we as students want to see the finished product first and through analysis we learn to walk back through the process which is what should happend in real life problem solving. That is just a learning strategy. Hopefully the teacher explains that.
@EdB_Vt - Hw writes the docs and sw reads it. What makes it collaboration is when hw first discusses the design with sw before writing the doc, and for sw to give feedback to hw on how to make the design better. The doc is basically a contract that puts in writing what has already been agreed to by both parties.
I'd like to see a good dictionary defining the "best practice" words to use in discussing software before the programming begins. Defining things like "vectors" and "sequencers" and, of course, writing styles for documenting registers...
multi-editable docs CAN be surprisingly functional IF your underlying process is able to capture-and-display all changes in a (color-coded?) "cloud" -- but I agree, SOMEone has to have ultimate power to REFINE and DISTILL the conversation down into a game-plan...
@Tony H - We have learned in school to first write the code, then draw the flowchart. Given the fact that design can be an iterative process, it does seem a waste of time to do the documentation first. But in the area that we are talking about, where two different teams have to collaborate across an interface, doing the documentation is a must so that both sides agree before coding the design.
I keep seeing that we (people) are somewhat handicapped in writing/reading/creating software because we didn't have any multi-threaded events impacting our evolution until after we got down out of the trees. VISION, we're awesome at, and tracking trajectories and calculating probabilities, but device drivers require conscious thought without much backup from "gut feel". Which is one reason why learning good habits EARLY is so critical.
@flaredOne - Whether one uses electronic white boards, wiki-style docs, etc, is dependent on the people and organization involved. Those are good collaborative tools. I don't know that I would use a wiki-style, multi-editable document for hw specs. That needs tighter control.
Gary - how can we get around the "this is just like the previous product but with these additional featuers" syndrome when the previous product doesn't have/or has an incomplete a requirements document?
We're reaching the point where we CAN have big "clouds" of interlinked design details where we can zoom in and see all the details, precursor info, constraints, specs, commentary, etc -- AND have a reasonably visible change-record for updated details. Soon, please!
@LevitonDave - One of the best things that our LaserJet lab did to get sw involved early in hw/system design was to make it part of the checkpoint checklist. Having it on the checklist required buy-in by hw and sw management, which they then pushed down to their engineers to do the collaboration. One of the checklist items was that sw engineers had to read and aprove the hw specification before hw could leave that design phase.
@LevitonDave: It can be helpful to have the h/w and s/w groups "close together" on the org chart, with a common manager not far up the chain, to encourage early collaboration. That way management can coordinate schedules more easily, and can resolve techinical issues sooner. The h/w and s/w folks should also be on each other's email lists (or part of whatever electronic means each group uses for internal collaboration.) Even if they don't understand or closely follow everything the other group is doing, they can still understand the big picture. Occasional face-to-face meetings are helpful, too.
@Ran, I tried that, no change. I'm using OpenOffice.org, free software. Gripes me to have to buy in to Microsoft's business "planned obsolescence" business model... AND I get what I pay for, right? Survivable.
Some "standards" are so vast, that many parts of them are not often implemented, or implemented incorrectly. PCI "segments" are an example -- we've found many commercial OSes which don't correctly support segments. TCP options are another example. When deciding whether or not to support a standard, it's important to determine if the components/hardware you want to interpoerate with support the parts of the standard you are interested in!
this has always been a personal conflict for me. I prefer to post a 1, but then using a zero allows various error codes to be posted from the same interrupt. that is, the error codes are non-zero. any thoughts or a compromising technique
Documentation and FW/SW...I find it amazing how many engineers who have been formally taught and are degreed who will begin their project work with coding.Programming should be 70-80% documentation and the rest goes to coding/debugging.If this is done correctly, the documentation takes care of itself.Now that should shake up this forum and get everyone excited, argumentative and defensive, huh?
@Alex – Documentation inherited from a predecessor is routinely a nightmare.I always make time to leave behind good documentation for anyone following behind me, even if I have to do it on my own time and/or at home.
Surprised: Actually in many digital systems today, high level software definitions should occur closer to the top where requirement specification documents would occur, way before the hardware details are developed.
@Gary – Inaccurate documentation...Don't get me started!I've had to take up a project that my predecessor left nothing intelligible.I'll state one example.Department of the Army had a silver-oxide battery for the Hummer-mounted TOW missile.The project was to replace the battery with a Lithium-Ion battery.The new battery had to communicate with the launcher electronics.None of the engineers in our department could interpret the old battery's docs.So, you guessed it...Dump in on Ran.
And establishing a requirement for clear commentary embedded in software is key to capturing info about changes, etc -- comment stuff out so you can see what HAD been there, AND document what changes and WHY (to the extent you can). Intermediate revisions out in the field will thank you.
I've wasted hours do to inaccurate documentation. What is worse is telling the responsible person about the error, have them agree to the error and then have the same problem in the next two versions of the documentation.
"Communication" means obsessing about the exactly correct wording for stuff -- documentation is one of those places where establishing standards pays off BIG later. Format, protocol, explicit expectations about fonts, tabs, headers, etc.
BEST part is when you document hardware methodologies and register definitions -- IF you do it effectively, that documentation can be used almost DIRECTLY by the software developer(s).
@Alex, at some point you need to cross-reference across multiple days, to build a base of "job function and current activity", so SOME of us don't have to answer the SAME query every day. Carpal tunnel, okay?
My favorite technique, re "easy to work around" has been to take full advantage of extra pins, spare functionality -- if I have a programmable logic device with extra inputs and outputs, USE them by connecting additional signals which make sense as far as using spare OUTPUTS as trigger signals and INPUTS as conditioned-signal-injection points
Had two headhunters call today checking on my C+ skills -- said I HAVE to modify my resume to clarify -- my HARDWARE experience led to my having to create exercising software, testing and diagnosis software, etc.
The streaming audio player will appear on this web page when the show starts at 2pm eastern today. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser.
Hah -- self-referential. The entire concept of clarifying expectations kicks in BIG-time during both the design process ("The design goal requires" (ie, the customer wants) "us to do WHAT?") AND when weighing priorities and tradeoffs ("do I bulldoze out time slots for this ALL week or not").
Slide deck appears to be okay to me -- a continuation of the discussion yesterday in a larger sense. It DOES seem the title of this course could be "Principles of (interface, etc) Design".
What ~I~ would like to find out, more re infra-structure here -- what does Digi-Key and DesignNews mean when they say "qualified attendees"? Do they need to see a copy of my diploma? A current pay stub? A utility bill? My driver's license? "qualified" in what sense?
Among other things, I ask because I was an attendee of a previous series which promised a Starbucks gift card - and have not seen 'hide-nor-hair' of that. I wouldn't mind being "qualified" to perhaps win a tablet (is that JUST for attending TODAY's lecture, or attending this lecture all week?)
If "qualified" equates to "attends every lecture this week", well then tell me that. Then I will know and/or can weigh my relative priorities and tradeoffs.
Let's "collaborate" on this. Maybe "iterate" and "elucidate", too?
Engineers at Fuel Cell Energy have found a way to take advantage of a side reaction, unique to their carbonate fuel cell that has nothing to do with energy production, as a potential, cost-effective solution to capturing carbon from fossil fuel power plants.
To get to a trillion sensors in the IoT that we all look forward to, there are many challenges to commercialization that still remain, including interoperability, the lack of standards, and the issue of security, to name a few.
This is part one of an article discussing the University of Washington’s nationally ranked FSAE electric car (eCar) and combustible car (cCar). Stay tuned for part two, tomorrow, which will discuss the four unique PCBs used in both the eCar and cCars.
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.