@rickw95 - Faster electronics can bite both ways. Faster hw may result in unutilized hw bandwidth because the sw is coded assuming slow electronics. Faster CPU will cause faster sw which might break when running on same-speed hw. (We had that problem once.) The best way is to make sure hw provides interrupts and/or done bits for all events and task completions, and then have sw use those bits to know when to move on to the next step.
@AlanJayWeiner - Keeping or dropping something that "might" be used in the future. Once something is in and unchanging, maintenance efforts are typically low. Taking it out will cause turmoil and needs to be tested. Putting it back in later will cause more turmoil and will need to be tested. Weight that against the likelihood that it will be used later.
@LevitonDave - Code compile switches can be complicated but it can be done it a way to simplify things. Because I had to support many printer models and ASICs, I developed simplified techniques and have presented classes at conferences on that subject.
@luizcosta - You sure ask some good, thought-provoking questions. One of the best ways for versioning the hw/sw interface is for hw to have a version regsiter. This allows sw to verify its knowledge of that version. This is especially necessary for FPGAs that change frequently. Also, each block should have its own version register. That's the highlights, if you want more details, send me an email.
I've not done Android development but I do have an Android phone so I've been following a few apps and have seen where some apps have problems with some phone models. I do agree it does sound messy to try to get an app to work across all past, current, and future models. And it's not just across hw models but also across Android OS versions.
Re: Feature creap and bloat if adding unnecessary stuff: In sw, you can wait to add it in until needed. If the hw part is there but sw is not, it is generally not a problem. In hw, if you don't add in the feature because it is not needed for this product, you will be forced to make a new ($$$$) chip to add that feature in later. If you add that feature in now, then, even though you can't thoroughly test it with this product, it is there and could be used on the next product without making a new chip. As will all things, good engineering judgement is needed when determining what to put in and what to leave out.
@flaredOne - "Feature creep" is generally referred to adding in new features. I'm more focused on implementing all exisitng features, not just a subset. And when adding new features, that it doesn't break existing components working with existing features.
side comment - I'm looking for a desoldering station for thru-holes (vacuum pump type - rather than hot-air for SMDs, although I could use that too). If anyone has one I can get "real cheap" please let me know. alan@ajw.com
Alex - please let me know if posting that is ok, and I apologize if it's not.
@Chuck Matthews - Adding unneeded functionality vs. Agile. Agile is fine with sw. You have the agility to add it easily. Agile does not work with ASICs and SoCs that take more than 3 months to make and cost more than $1,000,000. On the sw side, it is okay to not add until needed but if a feature is already in, don't take it out because it is not needed in the next product. Taking it out causes code turmoil and more problems when you have to add it back in for the product after that.
@luiscost - The fundamental communication between hw and sw is simply sw writes to a hw register when it needs to tell hw something, and hw generates an interrupt when it needs to tell sw something. In most cases, a sw driver totally owns its respective hw registers. No coordination needed. The only complication is that when hw generates an interrupt, it takes some decoding to determine which driver the interrupt is for. Then that driver services it as necessary. IPC is necessary because both processes can't be running at the same time. So IPC is needed to hold messages (and data) until the other process is allowed to run. That's not an issue between hw and sw.
@micholba - polling vs interrupt. My take on that is that if there is a question, hw should implement it as an interrupt and that allows sw to choose later on whether to poll or to wait for interrupt. It may be that that particular chip is needed two different models where polling is better in one and interrupt is better in the other.
a good matrix for compatibility winds up scrolling off into unexpected dimensions really quickly. Like a system response equation with tenth-power factors (i.e., ten often-unique individual values for some variable).
Using Windows CE for the software menu display interface, sometimes there was not enough memory for including all of the desired features and there was times when they had to decide on which ones to include in the next revision.
I had a problem when changing from one generation of Microcontrollers to the next. It has a Hardware Module to generate a PWM to control a Power Inverter. This hardware should have been the same in both Generation of chips. That was the statement of the Manufacturer.
In the Frequency Inverter in a Range from 1.5kW to 15kW the change ot the new processor worked fine.
In the next bigger one (22kW) every time you switched on Power the current and temperatdireure Measurement fails. It has been directly destroyed.
After a few weeks we found that if you configure the new µContoller like the old one, the default sates of the PWM outputs are inverted.
This causes to switch all IGBTs in the power inverter on to the same time.
In the smaller Units the hardware to drive the IGBTs prevents this, in the bigger one you could do it.
Have done the timer, and reset the power supply. Ugly as can be, but sure does work well. But it depends on the application, and design. Can the power be interupted safely...
@raghu - look at the idle state of the bus and the requirements to pull up/down. The one that pulls current in the idle state will consume more power. Transitions are going to typically be the same.
Pairing New with Old is very important point of yours.
I recommend maintaining an updated matrix that indicates what software and hardware is compatible with each other. Let's call it a Hardware vs. Software Compatibility Table.
Anyone really INTO interface design, check out the LEAP device reference at the bottom of this chat stack. And I won't mention it again.
@Gary, that ESL sounded like a good approximation of the language necessary for hardware and software to be ABLE to discuss a design before the design process even gets started. Something to look into.
Everybody is posting their place and weather. I'm in Boise, Idaho, and it is mostly sunny and a cool 55 degrees. It was 80 degrees during Monday's lecture.
@AlanJayWeiner, I remember one of those circuits -- put in a "missing pulse detector" (a 555 timer circuit) designed to detect when RS232 communications stopped from a device which regularly emitted an "I'm here" msg -- and the detector had a relay closure output used to "kick" the power supply on that monitored device enough to cause it to reboot... Lose!
I remember a story from many years ago - design was to control traffic lights. About once a week, it would lock up. They never found the problem, but added circutry to *detect* when the lockup occurred. That circuit then rebooted the board. Always found that an interesting solution, even if not a desirable one.
CUSTOMER ENGINEER. verify system operation, reporting back to research engineering as to errors noted in the field an possible causes and solutions. also install an test engineering changes in the field.
I had code that worked on a slow computer but when we got new computers in (they were faster). The code did not work anymore. I did finally fix the problem.
But is there a way one can prepare for faster electronics?
I had code that worked on a slow computer but when we got new computers in (they were faster). The code did not work anymore. I did finally fix the problem.
But is there a way one can prepare for faster electronics?
As you build up your toolkit, you start finding ALL these things you would LIKE to embed in ASICs, etc. But until then, you really can't design every possible "plug THIS hole" to add in. Just leave extra pins when possible!
@Gary - any suggestions for determining when to keep something for future use vs. maintaining something (at cost of maintaining and testing the unused stuff) that ends up never being used?
@ageppert - some of the ideas (e.g., UI in XML, using relative layout for objects) are a great idea, but there's too many cases where things don't work properly. Very frustrating.
Prod Support Eng. one time had to ask HW to provide interrupt rather than have sw poll. When they realized the difference for sw; they agreed, unused resources they could use to provide it.
I'm a Sr. Software apps engineer - helping customers integrate hardware and software we create for embeded systems. I've seen in some hardware have a ton of options, making one have to dig through the manual to get a basic setup.
lastest problem is with Android project - APIs don't work completely or predictibly (e.g., layout a UI in relative positioning; control X is sized in % of a container or other control, and positioned relative to other controls/containers) - works in some orientations, and/or on some devices (phones, tablets, etc) but not on all.
Simplifies your business model, too, since you can sell a functionality and easily "enable it" without having to add anything new to the original system.
CAN start to look like Microsoft-typical "bloat-ware"...
a long time ago a second source UART didn't delay the data ready flag from the error flag. both went out at same time and 10ns gate delay difference was enough for garbled text on the teletype.
@AlanJayWeiner - I can only hope how soon Comcast will exercise good management intelligence and move on to a new box with new programming. They'd better do it soon due to competition. HW+FW management are all needed to make a company successful.
@Gary - Nokia is famous for having the same piece of h/w packaged in slightly different cases and having slightly different s/w (all pretending to be different phone models)... cost efficiency
Worked on an application package which would successfully handle 96 channels of real-time processes -- we used a semaphore mechanism which was artfully derived from the IBM micro-channel hardware synchronization process. Worked amazingly well.
8051 uC serial interface - Tx IRQ before stop bit sent, therefore have to add delay before turning off driver for RS485 and add delay at other end before enabling driver so no driver contention
@Ran - I thoroughly agree about Comcast DVR; despise it. We switched to RCN, which uses Tivo. Have to say the Tivo interface is vastly superior. Very consistent and almost completely intuitive. (must be; my wife can even use it... :)
ALEX: I don't know if this CEC will continue, but here is a suggestion. A week module on a step by step interface design process involving software and hardware, a very simple case study of sorts.
@Gary – Although I was not involved in the design (I wish I had been), the Comcast DVR presently in use in our area (Motorola DCM-3400-M) is very, very unbalanced and is software heavy.It is extremely slow (and it's also very full of firmware bugs).To make certain the problems were not a hardware failure, the box has been changed out approximately 5 times, but the problems remain.Every time Comcast performs a hardware update, they correct a problem or two, but in the process they break something else.They are either not hiring competent programmers or they don't know how to find a competent company to which to outsource.
Haven't run into a balance issue in a long time due to better planning and system design. I'm not taking credit for this, because it was company efforts that resulted in good balance. Teamwork.
slight side comment - I remember a case where a signal needed to be inverted before transmitted (to panel light, if I remember correctly); it was easier to do that in software rather than rev the hardware
So yeah -- when you have an interrupt routine tickled every 60 milliseconds, and your interrupt servicing routine takes LONGER than 60 milliseconds, you have a problem!
(psst -- this is NOT spam, or a commercial announcement: any developers looking for new innovative "game changing" interface development opportunities, scroll down to the very bottom of the chat-stack -- look for reference to signing up for a developer SDK for LEAP interface device. I have absolutely no connection with LEAP, just enthusiasm for what appears to be "next gen" potential.)
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.
You guys are a bad influence. Right now, though, you're competing with the tutorial video for the Google "MOOG synthesizer" doodle on their search page today. There's a contest (prize $300) for "best composition" using the synthesizer... re http://www.moogfoundation.org/
@cnorton, sorry, didn't have the focus on this window.
Alex explained that "qualified attendees" are anyone logged in here, basically -- if you're interested enough to attend, you "qualify". So I'm suspecting that they're going to take the list of people who registered AND logged in, and do some form of essentially-random drawing from that list. In a perfect world, they might "weight" any one person's "entry" on the basis of "participation", not just lurking, but that's just me (and a very normal human self-interest) speaking...
Giving this a shot (following the "embed YouTube" directions below, except there ARE no checkboxes for "use old embed code" under the code box -- I see "HD link" and "Long link"). This should be the "Introducing the Leap" video from http://www.youtube.com/user/leapmotion?feature=watch
http://www.youtube.com/watch?v=_d6KuiuteIA is "long link" and
So "Design for test" would be a robust subset of what you're communicating to us.
Encountered any "game changers" in the design field recently?? Had any chance to look at the Leap Motion product, get any feel for how design tools might be about to make an evolutionary jump? While I ponder their claim to 0.01mm detection/resolution (watch for their "writing within a one centimeter square" in their YouTube video), I am struck by how their "cloud of link-interconnected websites" correlates so visually with our "cloud of design-specific particulars needing to be considered during the design process" -- and how gestural access into that cloud would appear to simplify USING that data.
If you go to the LEAP website, you can get your name on the list as a potential developer, which would give you a free spatial "recognizer space" device AND access to their SDK. Just don't crowd ME out, please!
Using almost 200 light-emitting diodes in the front and back of the new 2014 CTS, Cadillac designers are showing how LEDs can change the character of a vehicle.
We looked at a number of sources to determine this year's greenest cars, from KBB to automotive trade magazines to environmental organizations. These 14 cars emerged as being great at either stretching fuel or reducing carbon footprint.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 3
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 ...
A quick look into the merger of two powerhouse 3D printing OEMs and the new leader in rapid prototyping solutions, Stratasys. The industrial revolution is now led by 3D printing and engineers are given the opportunity to fully maximize their design capabilities, reduce their time-to-market and functionally test prototypes cheaper, faster and easier. Bruce Bradshaw, Director of Marketing in North America, will explore the large product offering and variety of materials that will help CAD designers articulate their product design with actual, physical prototypes. This broadcast will dive deep into technical information including application specific stories from real world customers and their experiences with 3D printing. 3D Printing is
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
1 
