HOME  |  NEWS  |  BLOGS  |  MESSAGES  |  FEATURES  |  VIDEOS  |  WEBINARS  |  INDUSTRIES  |  FOCUS ON FUNDAMENTALS
  |  REGISTER  |  LOGIN  |  HELP
Comments
You must login to participate in this chat. Please login.

Worked with teams only within the US

Iron

From Utah, catching up...

Iron

Worked with overseas team , different culture

Documentation is fixed on my projects if I have any say. It is pritty good on projects  I have worked.

Other side of world and next door. Lots of web conferences.

Seems kind of quite today, Friday before a holiday.

Day 2, systems/design engineer

Time wasted by lack of documentation is also a big time waster

I write documentation for myself but shy away from writing it for others. I prefer to communicate informally via bug/code management

I find some of the people I work with in india respond to emails at what is late in the night their time

@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.

Iron

Thanks Gary and Alex.

Iron

@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.

Iron

@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.

Iron

@RMRSS - Changing standards is required on occasions. And the transition plan may require supporting both for a while.

Iron

@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.

Iron

@kanjaamohammed - What do you mean by "consructor documentation" regarding knowing where to look for other docs?

Iron

@flaredOne - ed, hu, and ri on slide 19 are Wed, Thu, and Fri. Are you haveing troubles reading the powerpoint slides?

Iron

Thank you Gary, thanks to everyone.

Iron

@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.

Iron

@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.

Iron

@Gary - An outsider could also mean an unemployed single mom standing in the line at the unemployment office.  There are pros and cons.

Iron

@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.

Iron

@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.

Iron

@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.

Iron

Odd, every other attempted post (so far, w/ limited sample size) has failed. Okay, gotta bail. Manana, guys!

Platinum

@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.

Platinum

chat has failed??

Platinum

@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.

Iron

@GARY - we need to have a book "the things engineering school didn't teach us about working together"

@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.

Iron

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...

Platinum

@flared0ne - Got it!  Adjust your zoom level.  That should do it.

Iron

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...

Platinum

@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.

Iron

@GARY would Google Doc be suitable for documetn driven development collaboration?

Iron

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.

Platinum

@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.

Iron

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?

if the tablet selection considers "Ahh, gotcha" I think the DEAD (darkness-emitting arsenide diode) reference deserves some extra credit...

Platinum

@luizcosta - Yes, I did respond on yesterday's chat stream but sorry, I don't have good reference to book or tutorial about driver programming.

Iron

(the coffee was good :)

@Alex - will we know who wins the tablet?

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!

Platinum

Thank you for the lecture.

Iron

Look forward to tomorrow!

Gary,

Thanks for Today's Presentation...

 

Iron

@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.

Iron

@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.

Iron

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.

Iron

Again, the audio does not work for me until after the recorded version becomes available.

 

Iron

@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.

Platinum

Thanks, Gary.  Good session.

Iron

And my newsletter #53 has more info about register design tools, http://www.garystringham.com/newsletter.shtml

Iron

In case a documentation needs to be modified, is it worthy to contact and update the current customers using the product?

Iron

Okay, Ran, sorry for getting you mixed up with flared0ne.

Iron

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.

Platinum

@RMRSS switching standards is like switching processors or hardware. It becoms a porting project.

@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.

Iron

Gary, you've referred to Best Practices, Standards and Principles.  You haven't mentioned "Bag of Tricks" yet. :)

Iron

What happens when You find a better standard that means change or dropping old one?  i.e. to support but not encourage being dynamic?

Iron

Alex,

I'm a Systems Integration Test Engineer. Both HW & SW.

Iron

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

Iron

Thank you for the lecture

Iron

@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.

Iron

Here is the link to my Register Design Tools comparison page. http://www.garystringham.com/rdt.shtml

Iron

Ran, it must be your PPT tool that is cutting off Wed, Thu and Fri.  All three appear just fine here. I'm running MS Office 2010.

Iron

Over on "the other side". Is that the "DARK side" or the "LIGHT side"? What are you saying, Alex?

 

(@ran, that makes perfect sense! thanks.)

Platinum

Thanks Gary and Alex for a great session and a worthwhile way to spend my lunch time. See all tomorrrow.

Iron

Thank You For The Class

Iron

what are the challenges of having the same team do both firmware and hardware design/development?

Iron

Gary - any thoughts on how to get SW involved earlier in the specification process?

@flared0ne -

What does "ed", "hu" and "ri" mean on slide 19??

It appears you are missing the first character in these lines of text on the slide.  I think you these should be Wed, Thur and Fri.

Iron

@Alex - HW/SW/FW.

Iron

Hello today to Alex.

Iron

great presentation Gary. thanks a lot

Iron

(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. :)  )

Thanks for the lecture.

Iron

TaBLET, taBLET, taBLET!

 

(Thanks, Gary!)

Platinum

thanks Gary, great presentation. thanks again Alex, see you tomorrow

Iron

Thanks, looking forward to tomorrow!

Iron

Merci Gary, tres bien !

Iron

@GARY: Don't know if you share any reference for tutorial or cookbook on driver programming.

Iron

@Gary, isn t the consructor documentation enough,where to look for  further docs

Don't forget to clarify the "qualified attendees" issue re the tablet!!

 

Platinum

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.   

Iron

thank you Gary,

Iron

Thank you for the lecture, Gary!

Iron

In one case I actually designed read only registers, and they had a purpose!

Iron

@Gary - Surely no standards practices/documentation can encompass all these issues.

As each is solved, three others pop up.

Iron

What does "ed", "hu" and "ri" mean on slide 19??

Platinum

Of course, there is the DEAD (darkness-emitting arsenide diode), used to display contents of WOM (write-only memory)

Iron

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!

Iron

I despise write-only registers. Many time I've had to explain why to my HW counterparts.

Gold

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.

Platinum

r/w registers or local loop-back is a troubleshooting technique I learned a long time ago.

Iron

R/W uses more gates than WO.

Iron

Parts requiring a zero ACK I just stick in an inverter and write a one.

Iron

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

Iron

Interrupt ack is usually defined by the chips or cpu. 

Iron

chat is dropping messages...

Iron

Read the documentation?? Sometimes you have to read the ASSEMBLY CODE to see exactly what happens during an interrupt sequence...

Platinum

The Germans were notorious for not adhering to the standards of the rest of the world. Did they change their practive?

Iron

these cases make documentation really important, and inline comments even more important

Iron

the firmware I've had to modify, or figure out how it works has no standard for interrupts or error handling.

Iron

We are at the mercy of the microcontroller.

Iron

If I ever run into the problem I'll decide then

Iron

Typically distructive read or positive acknowledge (1) non-zero acknowledgement.

In my experience internal standards are much more important than external/national/industry standards

Iron

We have some internal guidelines for coding

most of the time, the standard is what the designer/programmer likes at the time.

Iron

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?

Iron

coding styles == religious wars :)

AdHoc seems to be the norm.

yea, dealt with internal guidelines for coding

Iron

"AdHoc" (driving by one personality) can be a business killer.

Platinum

ADHOC or rather the NORM?

Iron

Every where I worked

Iron

@Gary... never been on a cruise ship... doing standards (industry) for living...

Iron

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.

Platinum

A treasure in the deep ocean does not worth if nobody knows, so documentation is the way of engineering communication.

Iron

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.

Iron

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.

Iron

@Gary: What was the model of that printer? Just kidding!

Iron

So "Transparent to the customer" equals "What broken penguin??"

Platinum

what happened to my post? this is an attempt to flush it.

Iron

So, "Develop good habits". And give FEEDBACK about bad habits.

Platinum

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. 

Iron

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.

Iron

Is it a good idea to have the document of a yet-to-be-released product reviewed by an outsider for improvement?

Iron

@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.

Iron

It seems to be getting a little better from in house sources and I hope it will continue to improve because it helps speed up development time

 

Iron

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.

far from giving up on documentation, it's a continuing fight to get the time to improve how we communicate.

Iron

@Alex - missed your usual question today... I'm h/w, s/w and currently doing standards

Iron

No, don't see it as a serious impediment.

Iron

Our documentation is good.

Iron

@Alex: Not clear on your question.

Iron

So your email on the title page, substitute "http://www." for the "gary@" and that hits your website?

Platinum

How do you use tools like this for using standard MPUs and simple mapped I/O pins?

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.

Iron

Hello everyone...

Iron

@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.

Iron

We use a homebrew register design tool for our custom ASIC.  It's priceless -- we'd have an awful time without it.

Iron

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.

Platinum

documentation is very important,so

Iron

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.

Iron

another issue is outdated documents for updated products

Iron

HW & SW, Former HP Boise

Iron

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.

Iron

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".

Iron

"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).

Platinum

updating docs is very important too

Iron

When coding, I spend more time documenting than actually coding.

sw guys need to understand what the hw can do and what the hw limitations are

Iron

I personally disqualify products with poor documentaiton 

Iron

danlafleur, that is very true, you will catch problems when you are writing out the specifications and ensuring that they are correct.

Iron

Bad docs cause plenty of problems

Change reviews fix bad documentation.

Iron

have had major delays due to incorrect documentation

 

Iron

Occasional inaccuracies, but most HP ASIC documentation that I've used is pretty good.

Iron

Inaccurate/Incomplete causes ~20-30% increase in scheduled development time from my experience.

Inaccurate doc's happen more often than not. Takes a lot of time to correct!

Iron

sure, who hasn't; can waste a week or more

Gold

I like to write, but not documentation.

Iron

Incomplete or no documentation - lots of time spent trying to figure out what to do.

Iron

Bad docs have cost me over a month at times

inaccurate documentation has cost time, money and some good will from time to time.

Iron

Systems. Worldwide collaboration.  Recognize the importance of documentation and have created a few.

Iron

technical writters are a godsend. have used them extensively and love them. they do a great job.

Iron

Innacurate documentation costs a bundle.

Iron

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.

Iron

Having the doc's done before you implent HW/SW is ideal

Iron

As necessay as the documentation is the functional descriptions are the worse

If this is a collaboration, why is documentation written by harware and read by software?

Iron

Documentation is the deliverable from development engineering to manufacturing.  An undocumented design is worthless. 

Iron

writing good documentation is a great test of understanding the problem and solution.

Iron

you NEED to read the docs to know what to do or are able to do with it.

Iron

Documentation tends not to be done until the end.

Iron

Issues with Hw doing design is the false assumption that they know how SW will use the hardware.

@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?

Platinum

I do not do very much

Iron

I document the drawings and software. The technical writers are better at writing the deliverable documentation.

Iron

I deffinitely enjoy havinggood documentation.  Writing it may not be fun, but the importance is very high.

Iron

Don't "love" to write, but agree on importance of clear, well-written documents.

Iron

I've worked on projects with folks in France and also in Italy.

Iron

doc? yes, once I get started.

Gold

I'm ok writing documentation to make sure everyone agrees on what we are actually doing.

have written a lot of documentation, but never liked it.

Iron

embedded software worked with systems engineer and hardware engineer locally

 

 

Iron

Documentation is necessary

Iron

documentation is usually left until the end of a project.

Iron

hard and painful, but worth it

Iron

I do, but I'm a course developer and trainer

Hate documentation but necessary evil.

Iron

I love to write documentation.

Iron

Mostly same location, but increasingly remote team members.

Iron

Hardware, software, firmware

Iron

Yes frequently have to communicate at odd hours especially Germany

Iron

What do you think of electronic "white boards"? Wiki-style (multi-access, multi-editor) documents?

Platinum

all of the above, mostly internationally

Iron

Most of our international communication was done through weekly teleconferences with shared desktop andalso e-mails. 

Iron

@Alex - some of the rest of us have the same question about the Tablet.

Have collaborated nationally and internationally. Now local.

Iron

99% in building but some confrence calls and Long Distance customer input.

Iron

All of the above - primarily local teams but contracted world wide. previous life internal teams between Europe, Japan and US (PNW)

Did Gary provide a reference to a driver programming cookbook or tutorial?

Iron

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

Platinum

Lots of collaboration with design teams in India, but most meetings are early AM in US.

Iron

Have worked with international teams, but not for HW design.  HW/SW design has been with small groups at school.

Iron

hello from sunny MIAMI..

Worked with HP suppliers in Asia.

Iron

Local and International

Iron

hello everyone, sorry I am late, will try to catch up

Iron

Worked with teams spread across US, also with partner companies

Teams both within the company and with companies on the other side of the world (China).

Iron

Yes to all three questions.

Iron

have worked with teams in same office and in separate cities.

Iron

i've worked with teams literally on the other side of the world, india to be specific

Iron

We're both right here.

Iron

Technical trainer (FPGAs), looking to enhance my value to students who have to deal with interface and system-level design

Manager, moslty HW, some SW

Iron

Hardware and Firmware. 

Iron

Hardware design engineer

Iron

Embedded Systems Designer. HW and SW.

Iron

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.

Platinum

recently graduated and looking for a job, this seems like a good place to learn more about HW/FW/SW

Iron

My work is mostly electronics and embedded control hw, some firmware support with a lot of testing... or trying to break it before production.

Iron

Controls Integrator, applying controls to machinery.

hardware and software

Iron

Hardware Architect

Iron

@Alex - HW/SW/FW.

Iron

Firmware, consulting on h/w

Iron

Hardware and software.

Iron

Hardware and software.

Iron

Hardware and software

Iron

Yes K1200LT it started

Iron

firmware mostly but involved with a lot of hardware decisions

Iron

Hardware & Software Design

Iron

Electrical test, embedded design

Iron

Good morning, everyone

Iron

Good afternoon Gary.

Iron

Welcome back, Gary.

Iron

hardware design engineer,

Iron

Yes, still here. Hello, all!

Platinum

I don't know if the audio is being blocked at my work place.  Has it started?

Hello today to Alex.

Iron

Good Afternoon all.

Iron

@danlafleur - Rmember fire storm in Spokane so I appreciate the challenges you are faceing. Good luck.

Good afternoon Alex.

 

Iron

It's also raining in Vermont, at least we had two nice sunny days last weekend.

Iron

@GStringham - any ideas on how to get sw involved in system definition/requirements stage?

If you don't like wet, come join me in sunny CA.  It is one of the reasons I left Mich.

Iron

Good morning all from Coquitlam BC

Iron

@LevitonDave, spring showers when it's nearly summer. We had fire bans in place long before our May long weekend this year.

Iron

few things worse then cold wet feet and freezing rain dripping down the collar!

Iron

@danlafleur - You're having the same issues we have - summer in spring? :)

Good afternoon from cloudy Toronto

Iron

The form I prefer my moisture in is as snow, rain just soaks you entirely wet, at least you can have fun with snow

Ok he must have inhaled some of those tin whiskers then :)

Good morning all from cool and soggy Edmonton. We really needed the rain.

Iron

Good afternoon folks.

Iron

You assume that he did hardware. :-)

You must have snorted too much of those iron filings :)

 

I mean, greetings and salutations. :-)

Iron

Greetings and halucinations!

Iron

In anticipation of Alex's first question:

Firmware/Software engineer with system architect and integration responsibilities.

Howdy from the soggy Pacific Northwest. :)

Be sure to click 'Today's Slide Deck' under Special Educational Materials above right to download the PowerPoint for today's session.

Blogger

Please join our Digi-Key Continuing Education Center LinkedIn Group at http://linkd.in/yoNGeY

Blogger

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.

Blogger

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").

Platinum

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?

Platinum

The slide deck is wrong?



Partner Zone
Latest Analysis
Adam Berger hacked a computer keyboard into a mini key-tar to play with his band.
Altair has released an update of its HyperWorks computer-aided engineering simulation suite that includes new features focusing on four key areas of product design: performance optimization, lightweight design, lead-time reduction, and new technologies.
At IMTS last week, Stratasys introduced two new multi-materials PolyJet 3D printers, plus a new UV-resistant material for its FDM production 3D printers. They can be used in making jigs and fixtures, as well as prototypes and small runs of production parts.
In a line of ultra-futuristic projects, DARPA is developing a brain microchip that will help heal the bodies and minds of soldiers. A final product is far off, but preliminary chips are already being tested.
If you're planning to develop a product that uses a microcontroller, you'll want to take note of next week's Design News Continuing Education course, "MCU Software Development A Step-by-Step Guide."
More:Blogs|News
Design News Webinar Series
9/10/2014 11:00 a.m. California / 2:00 p.m. New York
7/23/2014 11:00 a.m. California / 2:00 p.m. New York
7/17/2014 11:00 a.m. California / 2:00 p.m. New York
6/25/2014 11:00 a.m. California / 2:00 p.m. New York
Quick Poll
The Continuing Education Center offers engineers an entirely new way to get the education they need to formulate next-generation solutions.
Sep 22 - 26, MCU Software Development A Step-by-Step Guide (Using a Real Eval Board)
SEMESTERS: 1  |  2  |  3  |  4  |  5  |  6


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.
Next Class: September 30 - October 2
Sponsored by Altera
Learn More   |   Login   |   Archived Classes
Twitter Feed
Design News Twitter Feed
Like Us on Facebook

Sponsored Content

Technology Marketplace

Copyright © 2014 UBM Canon, A UBM company, All rights reserved. Privacy Policy | Terms of Service