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.

Audio link is broken or it has been not archied yet ?
Iron

Great presentation, be here tomorrow

Iron

No, only active section of the code

Platform based programming interface/module/API. RS232, WinDrive

ok thanks, lets see what tomorrow brings, see you later

 

Iron

If Jacob has not responded to your questions, he has been going back over the chats at a later time and tries to answer anyquestions he missed.

Iron

oh yeah i didnt see it, i expected something bold i suppose ;)

Iron

Looks like we lost Jacob very quickly today. oh well

Iron

Another good session Jacob. Thank You.
And Thanks to Ann, Design News and Digi-Key.

Iron

@Devmo - look for posts from Jacob Beningo.

Iron

so have to keep moving, see you tomorrow in class

Iron

@micgil2293: Object Oriented Programming.

Iron

@FrodoH - I believe a POSIX pthreads implementation must support mutexes to be POSIX compliant, but do all embedded system vendors implement? Unsure. (Your mileage may vary...) Do your homework to be sure the selected vendor's product supports your requirements.

Iron

@LtDan. What exactly is OOP

Iron

Just an aside about doing your own HAL. You could learn Atmel Studio and sold a few projects by the time you finish...

Just sayin'

Iron

Please disregard my message of searching for power point presentation, I found it under today's slide deck.  Thanks

Iron

by the way didnt they say our master is coming back for questions?

 

Iron

Look to the right of the authors picture.   ^

Iron

Where is the powerpoint for me to download I searched everywhere so I can watch the classroom presentation?  Thanks

Iron

Considering the price of Atmel Studio and the ASF ($0 i.e. free) of a rather cmprehenive suite for ARM development -- I felt it was a point I could deal with.

Iron

you'd need to tradeoff 'learning' the vendors framework againest rolling your own HAL. Rolling your own may be less painful and more flexible in the future.

Iron

i have always wanted some plug in to the IDE or even an external piece of application that draws all the dependencies into different types of graphs, but there seem to be little thats free to use out there, do any of you use such a tool?

Iron

thats what i meant benjamin, each driver iself is layered several times, i think thats where the hal turns more into pain than joy,

Iron

The subsequent generated code is no worse than TI or IAR -- so I don;t feel a need to worry about how many source headers are included.

Iron

@Devmo, have used Atmel SWF on some projects.  It does seem to have overly "segmented" abstraction.  (I seem to recall that there were "driver" components in a few different locations.)

but the hw abstraction mechanism couples to several header files for each module, making it on the contrary quite difficult to include only one module without all the SFW overhead into a project

Iron

I have used the Atmel Studio and the Software Framework. It can be frustrating at times. It takes perseverance -- that's for sure. It does work fine once you have the required understanding.

Iron

has anyone used the atmel SFW, almost overkill on hw abstraction

Iron

@micgil2293 - this is where OOP and modularity should benefit you. You may have to rewrite drivers, but possibly not the overall application.

Iron

micgil2293: Drivers are part of the code that is not reusable if the hardware changes.  However, the driver API's should be set up so that if the hardware changes, only the driver code has to be updated; the application code can remain relatively unchanged.

Iron

Does POSIX have mutex and do all embedded systems vendors implement?

 

Iron

Thanks Jacob, Ann, and Digi-Key

Iron

well if you gotta use globals (they have limited use, like system flags) one should make sure only one module has write privilege at a time, by use of a lock/mutex

 

Iron

thanks for the lecture

Iron

reusable code is great as long as the hardware stays the same. Every time a new arduino is released the hardware is drastically changed so the majority of the driver libraries have to be rewritten.

Iron

Including links to external reference documentation (e.g. system flowcharts, component spec sheets, etc.) within the program helps to make progrmas more decipherable later.

Iron

A big problem using global variables is a lack of control over assignment of values that are outside limits. If an out of bounds value is detected, it can be difficult to identify the culprit. Also multiple variables for one purpose can be written by multiple sections, with the result that the resulting operation is not correct for any.

Iron

it can be difficult to achieve reusable code especially under design cycle pressure.  But the up front cost and time greatly is worth it on the backend.

Blogger

it also allows teh structure of the code to decay, resulting in bugs, harder to debug software and a whole bunch of other problems

Blogger

As a developer, do you need to understand every single line of code in an application?  Why or why not?

you should so you can modify the code if you need to.

Iron

George Mallard:  Global variables are bad because they can make reading another person's code difficult and can make debugging hard; it can be hard to track down every location where a global variable is changed.  They also tend to lead to spaghetti code.

Iron

I like to understand every line of code but its not really necessary. The more your know about the program the easier it can be to debug, but in order to use the code properly it isnt necessary to know exactly what every line does.

 

Iron

Another major problem with (program scope) global variables is that ther is NO control over which software components can modify the value.

@George Mallard, my experience is that you might inadvertently access a variable that was set in another module or a library.  Also, it is hard to debug if you have to search many modules to figure out where a var got set.

Gold

global vars are poor practice because of the potential for unintended consequences since they're exposed to every method. this concept is codified in OOP languages such as C+

Iron

Agree with others - the goal of reusable code is admirable, but may be difficult to achieve, particularly as hardware advances outpace product development/product lifecycles. (ie. - Marketing: What's the newest "thingy" available? We want that in our product. Engineering: We'd have to start all over to use it!)

Iron

The bad thing about globals is not that they exist but what they are usually used for; as a replacement for a decent interface

 

Iron

We would slowly advance without abstraction and trust in prewritten code.

Iron

We always hear how bad Global Vars are, but I have not seen the reasoning. Could you share what you know?

Thanks for the lecture.

Iron

Thanks, Looking forward to tomorrow.

Iron

Could one extrapolate that you are a believer in the use of C+ for embedded systems?

Iron

On large projects it would be impossible to understand every line of code.  You just need to understand the API's of the modules you interact with and only learn the details of other code if wierd behaviour occurs.

Iron

Thanks Jacob, Ann and Digi-Key.

Iron

nice presentation, thanks!

Iron

can be easy to port sensor.c

Iron

Thanks Jacob and Ann.

Iron

Jacob's question was: Do you think it would be easy or hard to port sensor.c to another target?

 

I would think it could be relativly easy

Iron

Thank you Ann, Design News and Digi-key

Iron

hello and thanks for attending!

Blogger

you do want to have the ability to dive into unfamiliar code and follow it, if you need to debug a problem with it.

Thank you again, Jacob, Ann, and Digi-Key

Gold

Do not need to understand every line of code in an application, but do need to know interfaces to my code.

Iron

Thanks Jacob for your insight.

Iron

You don't need to understand EVERY line of code; that would take "forever" to be able to do anything.  You don't need to understand internal combustion to drive a car or change the oil.  You don't need to understand EVERY transistor in an I.C. to use it in a circuit.

You need to understand the major components and how they interface.  To work within a component, more detailed understanding is required.

Why are Global Varriables considered so bad.

Jacob, thank you for today's lecture

Iron

No lines of code to understand in in LabVIEW

Iron

you don't need to understand every single line of code.

Iron

No.  Understanding how to debug is needed.

Iron

Good to know but not necessarily.

Iron

whoops C+ 11 std assessment

not necessary, but recommended.

Iron

not every piece, but how the interface to the module(s) works

Iron

not need to know everything

Iron

Depends on size of development team. While don't need to understand library or legacy API source, the time to understand would be a luxury.

Iron

No you dont need to understand it all, unless "wierd" things are going on.

Iron

If we don't understand every line of code, we risk problems down the line in the furure. However, it depends of how well written the code is.

Iron

I only got 5 questions correct out of 30 on the C+ 11 standardized assessment :(

No, only your section.

Iron

No, I only need to understand the interface to my software.

Iron

there is a saying: "lots of documentation is a symptom of bad design"

Not every line as long as you can trust the interfaces and underlying API code.

Iron

No, just need to understand how to interface to the modules you don't own.

Iron

No, only need to understand interface and functionality

Iron

I should not have to understand every line but I get anxious when I do not.

Iron

Limited development time pushes towards not understanding all code, but later debugging will require it.

No way to understand every line of code, even as a developer

Iron

Sometimes it's helpful to know how things work to be used in the right way.  But it's not always necessary.

No, sometimes it might not be feasible given time constraints.

 

Iron

No, it's impossible. You need to focus on the functionality of the module

Iron

not understanding something, and not doing anything about it, is unprofessional.

Iron

No, but that would be most helpful.

Iron

I need to understand the APIs and the code I write.

Iron

No need to understand every single line of code.  If that is a requirement then you can't move as fast.  You can't hold everything in your head.

No, only the interfaces you use

Iron

Not every single line but the main idea behind the module

Iron

Depends on how well the code is black boxed

 

Iron

I just need to know the interface to the modules and the parameters expected.

 

Iron

preferably on the abstract level

Iron

not necessary, but recommended

Iron

You don't need to know all the code - you only need to know the code that doesn't work!

 

Iron

Porting Sensor.c would depend on how tightly coupled to other modules (Main.c, Filter.c, etc)

Iron

(In "Embedded" - and probably all product developmetn - NOTHING is "easy", ie: as easy as someone thought it SHOULD be.  There is only "difficult" and "less difficult"...)

Jacob's question was: As a developer, do you need to understand every single line of code in an application?  Why or why not?

Blogger

Depending on the interface to from the code

Iron

Not sure how difficult to port - but there seems to be quite a bit of dependent code.

Iron

if you have defined ICD between modules, then it would be eaiser. If not, then very hard

Iron

Shouldn't be hard to port sensor.c as it is in a mid layer.

Iron

easier than the EEPROM_App.c example discussed

Iron

Should be easy since only have to change SPI

Iron

Difficult since it depends on filter and spi.

Iron

Depends on the API of the Filter and SPI modules.

Iron

"Relatively" easy.  Only called by one component.

Depends on how tightly it is coupled to Main.c

Iron

Jacob's question was: Do you think it would be easy or hard to port sensor.c to another target?

Blogger

I have had to write driver libraries for different arduino microcontrollers and labview for that is interchangable between the nxt and new ev3 lego controllers

 

Iron

unfortunatly no, but will try to start.

Iron

@aceperry, I had to click the "play" button several times; it kept cutting out.  (Not sure why...)

I've never been able to re-use code 100% when moving into a different microprocessor vendor (change in platform). Too many differences make the code less efficient.

Iron

Modularity is always a good idea to use in programming

Iron

Yes - modularity is a primary design goal.

Iron

Trying to port a code from Atmel to Microchip rewriting only the hardware specific code.

Iron

hello?  anybody home?  Sound cut out.

Iron

Yes, this is generally referred to a harware abstraction layer or board specific code.

Iron

Yes, only in some circumstances.

Iron

Always organize code in this way

Iron

We used rings of SW in Simulink and those rings of code could be used in multiple vehicle applications by linking them to the different sensors etc

Iron

Try to modularize if there is time.

Iron

I design usng "generic" layer interfaces as much as possible

Iron

We are beginning the process of moving to this style of code (if sales lets us).

Iron

I make my code as modular as possible, and you really can move from processor to processor if you do it right.

Platinum

We usually have to migrate to newer products, so having modular APIs and drivers is a must

Iron

Yes, mainly with TI and Cypress designs.

Iron

Yes, this is a primary objetive

Iron

yes, that's the only way to do it - spaghetti should only be used for food.

Yes, for larger projects

 

Iron

LabVIEW has the Actor Framework which is the Application PRogramming Interface API : that can be defined with a set of messages that can be sent to an actor and the set of messages it can reply with.

Jacob's question was: Has anyone listening tried to write code that behaves this way?

Blogger

virtually every silicon vendor that has its own ecosystem (dev kits, BSP, etc) has its own API

Iron

Windows API (for those who do Windows programming...)

Iron

Serial Communications, Zigbee

Iron

Secure Digital Memory interface

Iron

Is Application "Programming" Interface the same thing as thte App Protocol Intefrace?

For ARM, CMSIS - Cortex Microcontroller Software Interface Standard

CIMSIS for ARM Cortex

Iron

Thank you I must leave the session .....

Iron

Jacob's question was: Can you think of any other API standards that would be useful to reference?

Blogger

The biggest problem has been moving requirements.

Iron

@Jacob  Exactly what percent of code would you expect to be reusable?  In my experience (outside of software that spans a specific product family which is actually a single code base) very little code is reusable due to changes in hardware and feature set requirements.

Iron

feature creep and budget.

Iron

upgrade the platform on the run, so need to migrate the current development to the newest one

Iron

feature creap, budgets, changing the requirments

Iron

Timing. My company's sensors' software is dependent on other companies controllers. If they make a change we have to make a change or if they are late we are late getting started

Iron

Feature creep and budget

Iron

Selling non existant features combined with unrealistic design times.  Huge amount of feature creep. Sales needs a feature for a sale that will be utilized by that one customer. 

Iron
Changing requirements, despite best effort at preventing; feature (or even debugging nicety-creep)
Iron
Changing requirements, despite best effort at preventing; feature (or even debugging nicety-creep)
Iron

Feature creep - absolutely.  And it is not just a technical problem but a "managing your manager" problem.   Management wants you to be agile but unless you manage them they will abuse that agility to ruin your life with feature creep and indecision.

As said many times already feature creep and scheduling

Iron

Times, budget, and feature creep.

Iron

All of the above and also having to implement SW to fix bad HW design - such as having inadequate transmission hardware and using the SW to smooth out how the shift feels 

Iron

You have to be sure that your chosen platform can support feature creep without making you scrap the board or operating system. Be sure your vendor can upgrade the chip without invalidating your development to date.

Gold

One problem is interruptions. Somethng else arises that takes me away for days, weeks, or months.

Iron

Budgets, shrinking development times and feature creep are ongoing issues.

changing requirements

Iron

turn around time and need for additional features

Iron

You hit the big ones - budgets, design cycle times/time to market, changing requirements (ie feature creep)

Iron

Concurrent changes by colleagues (source control)

Iron

feature creep coupled with diminishing scheduled time.

Iron

one problem: key capability of platform not tested w/experimental code early enough in the design cycle to prove that it works or can be made to work

scope creep, feature creep, deadlines

Iron

Mainly feature creep. I also encountered some bugs, surprisingly, in the vendor-provided libraries.

Iron

I havnt really designed any software yet.

Iron

Not enough peer reviews, hardly any

 

Iron

time. Delay is inevitable.

Iron

Problems with change of initial specification

Iron

Feature creep. Yep. Always.

Iron

budget and schedule

 

Iron

conflicting changing requierments

Iron

Changing requirements

Iron

Feature creep for sure!

Iron

Jacob's question was: What problems have you faced during the software design cycle?

Blogger

Hello from lake Simcoe Ontario.

Iron

Good afternnon from richmond va

 

Iron

Hi from Brighton,MI

 

Iron

Hello form Toronto, Ontario

Iron

greetings from Seattle

Iron

good afternoon, everyone

Iron

Good Morning. It is 71F in Laupahoehoe

Iron

Hi all -Audio is live! If you don't see the audio bar at the top of the screen, please refresh your browser. It may take a couple tries. When you see the audio bar, hit the play button. If you experience audio interruptions and are using IE, try using FF or Chrome as your browser. Many people experience issues with IE. Also, make sure your flash player is updated with the current version. Some companies block live audio streams, so if that is the case for your company, the class will be archived on this page immediately following the class and you can listen then. People don't experience any issues with the audio for the archived version.

Hello from Albuquerque, NM.

Iron

Hello from snowy Colorado!

Iron

Hello everybody from Coventry

Iron

Hi everyone, from Bremen, North -Germany

Iron

Hello from Hudsonville, MI

Iron

Freezing... Hello. Cold today!

Iron

@hammer11 - I usually like to clarify that VT is not Virginia Tech

Iron

Hello from Montana. 17 degrees but nice and sunny warm

Gold

greetings back from VT

 

Iron

Hi from south central PA

Greetings from Boston Metro West. A beautiful sunny 46 degF.

 

Iron

Greetings from Vermont

Iron

Hello from Jordan middle east

Iron

Hello from rainy Albuquerque.

Iron

Hello from Beaverton, Oregon.

Iron

Hello, from Ottawa, and really interested in these lectures on embedded programming. Thanks, Jacob.

Iron

Hello from snowy Edmonton, AB

Iron

Be sure to follow @designnews and @DigiKeyCEC on Twitter for the latest class information. We encourage you to tweet about today's class using the hashtag #CEC.

Blogger

Hello from rainy SoCal

Iron

No snow sticking in Dubuque Iowa yet....

Iron

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

Blogger

Hello from snowy Aurora Colorado. Brrr....

Iron

Reuse is a good goal, but so much of it depends on whether the hardware and mission are reused.

The streaming audio player will appear on this web page when the show starts at 2 PM Eastern time 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. If that doesn't work, try using Firefox or Google Chrome as your browser. Some users experience audio interruptions with IE. If that doesn't work, the class will be archived immediately following our live taping.

Blogger

Hello and greetings from Summerville, SC. How is everyone doing?

Iron

@JayPaxman: Thank you so much. I downloaded the file at last!

Watch the download progress ...  500 / 1402KB  ...   900 / 1402KB etc.  See if it counts all the way.

Iron

@JayPaxman: Oh, you already told me the file size, 1402KB. Thank you. I will try again.

Windows shows ppt is 1402KB today

Iron

Hello from El Paso, TX

Iron

@JayPaxman: Thank you for the tip. I downloaded it four times, but it doesn't work. The file size is 559KB. What is the actual size of it? I have had no problem with the slide until yesterday.

Hi. Interesting sessions

Iron

Hello from Hudsons Hope BC

Iron

Hello from Scottsdale, AZ

Iron

@Dennis Kong:  File is ok.  I ALWAYS have to download twice for some reason, overwriting the second time.  Check the size.  When I do it, the first time is always very small, and the second time much larger (1402KB today).

Iron

I downloaded today's slide, but cannot open it with MS PowerPoint. Ann, Can you check the file again, please?

Sunny, warm Houston - here ;)

Iron

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

Blogger

Good morning from San Ramon, CA

Good morning from SoCAL.  Enjoying the rain.

Iron

Aurora, Ontario say 'G'day.

Iron

Good morning from Mobile, AL

Good morning from Portland Oregon

Iron

Slides good.

See you tomorrow.

Iron

Hi from Beaverton, Oregon. Getting the slides.

Iron

Important concept. Looking forward to your approach.



Partner Zone
Latest Analysis
Robots came into their own in the 1970s. Gone were the low-budget black-and-white B movies. Now robots roamed in full-color feature films with A-list actors.
The rear window on Ford's Lightweight Concept vehicle, based on the Fusion model, is made with a material combination devised by SABIC that saves 35% of the weight. The car's overall weight is 25% lighter than a standard production 2013 Fusion.
Sherlock Ohms highlights stories told by engineers who have used their deductive reasoning and technical prowess to troubleshoot and solve the most perplexing engineering mysteries.
There is still time to get in your gadgets for the Design News and Allied Electronics second annual Gadget Freak of the Year contest. The top three gadgeteers will be awarded a total of $10,000.
Major global metropolitan areas are implementing a vast number of technology, energy, transportation, and Internet projects to make the metropolis a friendlier, greener, safer, and more sustainable place to be.
More:Blogs|News
Design News Webinar Series
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
5/13/2014 10:00 a.m. California / 1:00 p.m. New York / 6:00 p.m. London
5/8/2014 11:00 a.m. California / 2:00 p.m. New York / 7:00 p.m. London
Quick Poll
The Continuing Education Center offers engineers an entirely new way to get the education they need to formulate next-generation solutions.
Jul 21 - 25, Design Products With Bluetooth Low Energy
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: August 12 - 14
Sponsored by igus
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