@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.
@flaredOne - I would like to provide more comparisons, including screen shots, output, etc. among the tools. That is on my list of things to do, eventually.
@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.
Ah, flare4dOne, I used OpenOrifice and finally gave up on it - too incompatible,a nd my work is too important to introduce incompatibilities withmy customers.
@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.
Your "Register Design Tools comparison page" -- I found myself wishing for a stack of comparative examples, snapshots of definitive pages showing varying styles of results.
@flared0ne - Perhaps if you adjust the size of the window in which your slide is displayed (if you can), all of the slide will be shown and appear normal.
Speaking of Tablets, Alex are there any plans to have tablet friendly streaming audio so that future classes could be listened to on an Ipad? (and also the archived classes as well)? Thanks
@Henador - Thanks for your response, but I was posting a reply to the person with the problem - flared0ne. I too have Office 2010, and mine also displays just fine.
(Suggestion: please provide a PDF copy of the slides. Powerpoint docs. don't always format correctly for those of us running Linux. PDF is a better standard to encourage collaboration. :) )
Use of standards sounds like it is a must when working with a design team, but also a very good practice with smaller projects and working on your own.
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!
It's been awhile since the "cost of hardware" meant the same address had to be used to READ one chunk of data from somewhere and WRITE a different chunk to somewhere else.
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?
Observation: ANY kind of RTOS, become seriously familiar with all the semaphores and flags available, and be CLEAR on protocols for setting/clearing higher-level signal flags.
It is a good idea to have one or more individuals with the background of the "typical" end user to read the document for clarity, possible missing information, etc.
documentation has to explain the process, etc. I have seen so much documentation that does not say anything. it is there for documentation purposes/requirement. very frustrating.
docs are always fixable. I found mistakes on components datasheets and give feedback to those companies to fix their problems. internal, you need to check and re-check before your final release.
It depends on the source. Some companies have very good documentation, some have none, most are somewhere in between. Generally I find hardware documentation is better.
@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.
No - I generate/support the documentation to ensure that the requirements and expectations are correct and complete. Peole give me a hard time because I document things much more than others.
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.
The problem with writing documentation for something you have designed or coded is the inherent danger of assuming the reader has your level of knowledge and familiarity with the subject matter.
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.
I've sometimes wasted days because of incorrect documentation, especially on commercial software. I really hate when the docs specifically say "Don't do this" when they really mean "You must do this".
"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).
Note re. documentation: sometimes specifications (which then become documentation) are written by s/w engineers, and read by h/w enginerrs. So, this goes both ways.
@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?
A new battery design, which replaces lithium with abundant and low-cost elemental sulfur, is still in its nascent stages but shows real promise for giving batteries more energy potential.
PTC will offer a virtual desktop environment for its Creo product design applications, potentially freeing engineers to run them from remote desktops on a variety of operating systems and mobile devices.
The push to achieving more intelligent, integrated manufacturing is putting a strong focus on networking and connectivity as key enabling technologies.
Now that solar and wind harvesting technologies are a thriving market, researchers are seeking other environmentally related energy sources for which they can create harvesting devices.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 5
Early in my career, I worked as a draftsman and remember the days of drawing on vellum with numbered pencils and Mylar with plastic lead. This was a fun experience in the sense that I ...
I've been using workstations for more than 10 years and love finding ways to get more performance from my system. With demanding professional applications that require more power each ...
A lasting memory from my first job as an engineer in an auto assembly plant is standing on hard concrete at six in the morning, vending-machine coffee clutched in hand, listening to ...
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This radio show will show what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
7 
