Who should write embedded software? - Page 1
Forum section: electronics / general

author: Lukas
author_rank: Frequent Contributor
timestamp: June 10, 2014, 12:22:29 pm
content: Hi there,who should write embedded software? Software or hardware people? It seems as if both are ill-suited in their own way.The software folks tend to think in classes named AbstractObjectGeneratorXMLFactoryProxyDelegate and therefore produce bloated and overly generic code.On the other hand, the hardware guys may be able to produce efficient code, but it often leads to unmaintainable spaghetti code because they never heard of object orientation or even functional programming or general software engineering basic dos and donts. (See toyota unintended acceleration issuehttp://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf)What are your thoughts?Lukas

author: dannyf
author_rank: Super Contributor
timestamp: June 10, 2014, 12:24:52 pm
content: Both: embedded engineering is expensive because it has to be developed by people with hardware AND software experience.

author: ecat
author_rank: Frequent Contributor
timestamp: June 10, 2014, 12:32:20 pm
content: I've seen hardware people write good code and I've seen software people write horrible code. The correct answer I think, is those with sufficient understanding of the problem and sufficient knowledge of the tools.As for the AbstractObjectGeneratorXMLFactoryProxyDelegate folks. When software is pushed as an art in and of itself with scant regard for the actual, required solution, well, the occasional ego may be inflated but no one really wins.

author: f5r5e5d
author_rank: Frequent Contributor
timestamp: June 10, 2014, 12:42:01 pm
content: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=507885&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D507885

author: madires
author_rank: Super Contributor
timestamp: June 10, 2014, 01:00:17 pm
content: Quote from: Lukas on June 10, 2014, 12:22:29 pmSomeone with knowledge of both, of course. In Germany you can study EE with specialization in "Technische Informatik" (technical CS?) which covers both.

author: AlfBaz
author_rank: Super Contributor
timestamp: June 10, 2014, 01:03:57 pm
content: Quote from: Lukas on June 10, 2014, 12:22:29 pmMasochists

author: Lukas
author_rank: Frequent Contributor
timestamp: June 10, 2014, 01:19:57 pm
content: Quote from: f5r5e5d on June 10, 2014, 12:42:01 pmI'm not advocating OOP as the solutions to all problems we aren't in the 90s anymore. The web development crowd is raving about functional programming, there are countless blog articles out there on 'how functional programming changed my life' etc. Even if these are too euphoric, it shows that these people care about progress and are open to new thougts. The past months/years have brought them a multitude of interesting frameworks such as react.js, angular, metor.For me it seems as as if the embedded software people are falling back in terms of software technology. I haven't come across any embedded software developer who knew of functional programming.

author: madires
author_rank: Super Contributor
timestamp: June 10, 2014, 01:40:39 pm
content: This week's fashion is red stripes and next week's is green dots. All those programming methods with their fancy names aren't anything new, it's just maketing slang. A good programmer analyzes the problem, takes any constraints into account and chooses the best way to get the job done. How would functional programming help me if I have to implement a state-maschine driven protocol stack? There's no method which is able to fix all problems and to make everything simple. It's going to be a mix.

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: June 10, 2014, 01:43:24 pm
content: QuoteNice one. LOL

author: Jeroen3
author_rank: Super Contributor
timestamp: June 10, 2014, 02:00:23 pm
content: Define embedded software.

author: diyaudio
author_rank: Frequent Contributor
timestamp: June 10, 2014, 02:15:15 pm
content: Quote from: Jeroen3 on June 10, 2014, 02:00:23 pmYou asked for it. You got it.quote wikiEmbedded software is computer software, written to control machines or devices that are not typically thought of as computers. It is typically specialized for the particular hardware that it runs on and has time and memory constraints. This term is sometimes used interchangeably with firmware, although firmware can also be applied to ROM-based code on a computer, on top of which the OS runs, whereas embedded software is typically the only software on the device in question.

author: ecat
author_rank: Frequent Contributor
timestamp: June 10, 2014, 02:20:57 pm
content: Quote from: madires on June 10, 2014, 01:40:39 pmTo be fair the purity of several functional programming languages has been corrupted to allow for the storage of state information, Haskill for example has monads (a name entirely too similar to gonads for my liking), a change made so one could use the language for 'something useful (tm)' I assumeQuote from: Lukas on June 10, 2014, 01:19:57 pmForgive my ignorance on the subject but how does an embedded programmer make the best of a functional programming language when using only 128 bytes of ram? Sorry, that was a little facetious. More seriously, how does a pure, immutable functional programming language deal with interrupts?Quote from: Jeroen3 on June 10, 2014, 02:00:23 pmSupply your understanding, if there is any disagreement we can take the discussion to a new thread. No need to pull this thread too far off topic.

author: dannyf
author_rank: Super Contributor
timestamp: June 10, 2014, 02:25:04 pm
content: QuoteThe progress in embedded programming is constrained by a different (however slgihtly) set of parameters: the hardware is limited, the speed requirement is significant, ...However, it has made significant progress over the years. When I started, everyone coded in assembly, and there was no debugger and IDE and ...Now, most people code in C, the use of libraries and modules are everywhere - I would have never imagined the use of uCOS or emWin for example 10 years ago, ...With mcus being more and more powerful, it is simply a matter of time that we start to code more and more like those on a PC - some ARM chips today are being coded in .net framework for example.QuoteMaybe you should meet more people outside of your usual circles of friends,

author: Kjelt
author_rank: Super Contributor
timestamp: June 10, 2014, 02:26:38 pm
content: +1 embedded software is such a huge container definition I have seen businesses building wafersteppers who's software was running on multiple SUN servers in a rack and they call their software engineers, embedded software engineers.And what would you call software running on a raspberry pi with multiple GBs of Flash and a tiny Linux OS?If you define embedded software solely to a tiny microcontroller directly driving a piece of hardware then you need IMHO an engineer that exactly knows the impact the code has on that hardware, knowing the microcontroller with all its peripherals ins and outs but also the hardware that this microcontroller controls.You need an engineer that can read and understand datasheets of microcontrollers and has profound knowledge of digital electronics and a little bit of analogue electronics for the interfacing with the analogue world. And also in our country this is a specialization from the EE education not from the computer science education.Still if that hardware interfaces with for instance the internet through sockets, udp etc. i would choose a specialized computer science engineer to handle that part, or that same engineer must be a universal educated person with lots of different broad knowledge and interests

author: dannyf
author_rank: Super Contributor
timestamp: June 10, 2014, 02:29:50 pm
content: QuoteSome validity in what you are saying.However, I do think it is generally true that the trend in coding, including embedded programming, is to move the programmer further away from the hardware. It happened and will continue to happen with PCs.The same will also happen with embedded programming as well.

author: Jeroen3
author_rank: Super Contributor
timestamp: June 10, 2014, 02:38:18 pm
content: If an embedded system has windows ce, it suddenly falls of the scale of "embedded" for a lot of people.Then AbstractObjectGeneratorXMLFactoryProxyDelegate is a real thing again.I've heard of small payment devices with an 2 line lcd, which can be seen as embedded.Running linux for an C# application...On the other side are small energy efficient single function devices, which can be build up by abstracted object to reduce time to market using stuff from previous projects. Instead of cooking another pile of spaghetti.But, operating system drivers might also be somewhere in the embedded area.

author: dannyf
author_rank: Super Contributor
timestamp: June 10, 2014, 02:40:53 pm
content: QuoteBecause for some applications, the cost of software can be extraordinary, vs.the hardware cost.In those cases, it pays (handsomely) to encapsulate your code in a hardware - independent way, as much as possible.

author: Unknown
author_rank: Unknown
timestamp: June 10, 2014, 04:12:32 pm
content: Quote from: Lukas on June 10, 2014, 12:22:29 pmSomeone who has successfully completed a similar project in the manner / style that you deem satisfactory; but I guess like anything - you get what you pay for - unless of course you just get ripped off! ;-)

author: retrolefty
author_rank: Super Contributor
timestamp: June 10, 2014, 04:26:12 pm
content: Quote from: dannyf on June 10, 2014, 02:29:50 pmI think a lot of these new programming methods and styles are to try and bring order to chaos when 'teams' are producing the coding. It's a world of difference if a single person is writing all the code and performing all the testing, but when it's a 'team project' there are always problems no matter if it's a mainframe, PC, or embedded project.

author: AG6QR
author_rank: Frequent Contributor
timestamp: June 10, 2014, 06:26:39 pm
content: Writing ANY nontrivial software well demands not only a knowledge of software techniques, but at least some familiarity with the application area.Also, writing almost ANY nontrivial software well demands a knowledge of the environment in which the software runs. In embedded software, especially the stuff that runs on small chips without an operating system, one may need to know details of the hardware environment and work very close to the hardware, keeping track of pin assignments, interrupts, etc. That's a challenge, but it's a different challenge than application developers of non-embedded software who have the challenge of writing extremely portable software that runs on a huge variety of platforms with varying resources and operating systems.One of the problems discussing embedded software is that it's such a broad topic. My first exposure to it was seeing a presentation given by some guys who were writing software for the engine controllers that controlled large jet engines. Those guys had to know software development, their hardware environment, and they also had to have some understanding of how the engine itself worked. A mistake in the software could cause a plane to crash and/or damage a multimillion dollar engine, so they were encouraged to review and test their software before deploying it on an actual engine. Because their computing hardware had to operate in an extreme environment of temperature and vibration, they used rugged old slow chips that were very constrained in memory, and had just enough computing power to get the job done.The challenges there are a bit different than the task of writing embedded software for an infrared TV remote control. And I'm not minimizing the challenges of a TV remote, trying to optimize hardware cost, make the best and most intuitive user experience, etc.Even if you consider non-embedded software running on modern networked computers, most programmers need to know not only programming, but also something about their application area. Writing a good finite element modeling program to help mechanical engineers compute stress and strain using 3-d models of mechanical parts requires a different set of knowledge and skills than writing an efficient and fast large-scale e-commerce site, which is different from writing a good compiler, which is different from writing an engaging and popular action game for PlayStation, Xbox, and the like. And all of these are different from embedded software to run a microwave oven, or a pacemaker implanted in a person's chest, or a newspaper printing press, etc. Software isn't all the same.Who should write embedded software? The people who know the area well.

author: gocemk
author_rank: Regular Contributor
timestamp: June 10, 2014, 07:00:25 pm
content: Quote+1This is absolutely true, but i have to agree that the trend lately is to further away the programmer from the hardware as much as possible. But as MCU's are becoming more and more powerful maybe this is a good thing, at least for speeding up the development time.Also, where i come from, "Embedded Programming" is almost exclusively taught in Electronics or Automation/Robotic departments where most of the classes are for hardware. The situation is completely different in Computer Science departments where they completely avoid embedded, or even C for that matter.Quote from: diyaudio on June 10, 2014, 02:15:15 pmI recently saw an add for an "Embedded C Developer" and the requirements were: "Excellent knowledge of C and Linux Kernel Development".Can this be thought of as embedded software?Quote

author: dannyf
author_rank: Super Contributor
timestamp: June 10, 2014, 07:05:16 pm
content: QuoteBecause software (thus people) are becoming exceedingly and exponentially expensive.

author: AG6QR
author_rank: Frequent Contributor
timestamp: June 10, 2014, 07:22:12 pm
content: Quote from: gocemk on June 10, 2014, 07:00:25 pmBy many people's definition, yes. If the final product has no way to load application programs on it, it's probably embedded software. My TV runs Linux, though the Linux is pretty well hidden from view. I would say the firmware running on my TV is embedded software.But I'll concede that the definition of "embedded" can be a bit arbitrary. Even when you think everyone in the room agrees on the words for the definition, you might find that there are grey areas where people disagree on whether a particular example fits the definition.

author: zapta
author_rank: Super Contributor
timestamp: June 10, 2014, 07:23:54 pm
content: Quote from: Lukas on June 10, 2014, 12:22:29 pmI observed this tendency with large frameworks (typically Java based) but not in embedded code. Java and the refactoring tools of its IDE's make it very easy to add those layers of abstractions. It make sense when you write the code but more difficult for new comers to lean the code and understand the flow. This is typically the tension, between easy writing or easy reading of the code.One example is Juice, it's manages the dependency injection and simplifies the unit testing but almost impossible to follow.

author: dannyf
author_rank: Super Contributor
timestamp: June 10, 2014, 07:48:53 pm
content: QuoteEven if you could load software, it can still be considered embedded.Bootloader + self-programming for example is widely used on mcu's: Arduino is one;Many of today's mcus support IAP.Many flash-based players / navigation systems are embedded. Smartphones too.It used to be the case that embedded means naked / non-OS based but I don't think that's the case anymore. So the concept (of embedded) is evolving as well.

author: vvanders
author_rank: Regular Contributor
timestamp: June 11, 2014, 12:25:08 am
content: Quote from: zapta on June 10, 2014, 07:23:54 pmWe like to call the AbstractObjectGeneratorXMLFactoryProxyDelegate "enterprise quality software". Someone did an excellent FizzBuzz implemenation:https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEditionWRT the original question I don't think there's a clear distinction. I've seen hardware people learn the ins and outs of software. I've also seen software people be successful in moving down the stack closer to hardware. I will say that on the software side people who tend to care about performance and memory size(ususally real-time applications) tend to do better in the transition.

author: SirNick
author_rank: Frequent Contributor
timestamp: June 11, 2014, 01:15:06 am
content: Any discipline can be broken down into an arbitrary number of sub-classifications. And, at the same time, the line between historically distinct industries becomes far less defined as technology merges.See: IP telephony. You mean I have to understand the mechanics of call handling, TDM,andnetworking?Quite likely the IP phone runs Linux too.

author: Alexei.Polkhanov
author_rank: Frequent Contributor
timestamp: June 11, 2014, 01:15:28 am
content: I think many engineer see a difference between software as embedded and non-embedded from whenever it is intrinsic or hidden within system or if user interacts with software itself (through UI) rather than the system it is part of (like pushing break pedal).Over past 20 years I worked on many software projects - I find that difference between how software is designed and built depends little on wheather it is embedded or not . On other end there are huge differences between how HARD REAL TIME, time critical and fault tolerant systems are built and the rest. For example most programmers that work with real-time systems would be familiar with terms like Rate Monotonic Analysis, N-version programming, lock-step execution. Many engineers that work with general-purpose systems never even heard of terms like RMA. Same situation is in low-level graphics programming used in video games for example, or networking - lots of specialized knowledge required even to start.Clearly embedded software does not require any special skills or knowledge from developer just because it is embedded, but other aspects that I mentioned above do.

author: clarkzh
author_rank: Newbie
timestamp: June 11, 2014, 01:57:47 am
content: Quote from: AG6QR on June 10, 2014, 06:26:39 pmexcellent writing!!!also the people should have the skills suited for the job. I mean, programming skills, hardware skills.I am from china. here, most firmware is written not by PC software background people. most of them from hardware guys. you should be able to solder components. use oscilloscope. DMM. draw PCB. debug circuit.then, write the firmware.mostly, here we develop simple , using no OS embeded system. but if using OS, like WINCE,linux. That is cake for the PC software background guys.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 11, 2014, 02:36:27 am
content: I'm a hardware guy.I write software very well (if I do say so myself, but I'd like to think, good enough that I'd be willing to provide examples without feeling embarrassed about it).I don't want to have to do it.I'm very slow and methodical at writing. I can't just bang out a simple use case. I am unable to ignore all the side effects and edge cases that, well, makes all software such a notoriously vulnerable target to hacking.Not that hacking need be a particular concern, but it's the same to me as leaving ESD diodes off a loose input, or something like that: not part of the required spec, but something's going to get fucky if it goes outside that, so are you going to do something about it or not?Tim

author: calin
author_rank: Regular Contributor
timestamp: June 11, 2014, 05:31:22 am
content: Been reading the thread and there are indeed many colors to - embedded software - a short name for a long and wide area/domain.If it is to be sarcastic I can say "those who know" .. but that wold be an a$$ of a responseNow on a more serious note these "masochist" as you call them are probably the ones that are most likely to write low level embedded code - heck I am one of them- my diploma says "engineer in computers and systems science" pretty damn close to masochist definition. I know programming well and enough electronics to read a data sheet, understand how a bus protocol works, timing etc. , i know to use a scope and logic analyzer, so yeah ... masochist. So the masochists are the guys tat put life in the chips and ee engineers are pretty damn close to that definition but you need guys that know to model an OS kernel etc to bring things to the next level - write an RTOS , design a compiler etc. Everyone has its place in the mix.There are many types of masochists; the ones that write firmware-s and drivers (you think those BSL-s get born out of nothing) ; the ones that create the OS , write a compiler backend etc - each specialized in their area. For example I know low lever firmware and OS design inside out .. put me to write a compiler backend and I start looking like a moron. So you need a team .. always. Remember what Bhor said - "An expert is a person who has made all the mistakes that can be made in a very narrow field." .. You need few of these to get a full circle.The AbstractProxyFrameworkInstatiatingBuilderFactory type of progammers that use angular JS and backpackto post tweets , or PERL or whatever functional HasNotEverHell heard about language which uses "functional object oriented encapsulation" (that's made up) are so high in the food chain that they forget about what they are running on . All they know is that "is a quad core Snapdragon" chipand yes runs Android and is optimized for HTML5. But hey , surprise, you need this kind of programmers too ... a masochist is just too expensive to pay him to do HTML5. He will probably do it but on a pay rate that will turn the boss in a "masochist"I know this is not even near to a decent answer but if you look at today's environment and products is clear that the term "embedded" is very large ... and to bring to life a successful product you need a team of specialists working together.

author: dannyf
author_rank: Super Contributor
timestamp: June 11, 2014, 11:08:26 am
content: QuoteFrom an employment point of view, you cannot be making a lot of money as long as you are actually writing code. I would expand that further to say that you cannot be making a lot of money as long as you are actually doing engineering - that's just the sad state of our society now.Among the people who are indeed writing code, I would think that those working with OS-level applications (for example, smartphone apps, or internet applications / plumbing) are making far more money than people writing code for embedded applications.

author: Kjelt
author_rank: Super Contributor
timestamp: June 11, 2014, 11:42:07 am
content: Quote from: dannyf on June 11, 2014, 11:08:26 amBig companies have outsourced this kind of work mostly to IndiaThe western programmers still doing this are self employed or relatively small companies.

author: andyturk
author_rank: Frequent Contributor
timestamp: June 11, 2014, 03:35:32 pm
content: Quote from: dannyf on June 11, 2014, 11:08:26 amYou can make good money (over time) if you own stock in your employer, and the company is sold or goes public.

author: Bassman59
author_rank: Super Contributor
timestamp: June 12, 2014, 11:34:05 pm
content: Quote from: gocemk on June 10, 2014, 07:00:25 pmOh, yes, certainly. I used to work for a company that did VME and Compact PCI CPU boards, and these boards were of course installed into backplanes which were then embedded in a customer system (which could be a helicopter or whatever).The boards ran VxWorks or Linux, so knowledge of how to build kernals and make BSPs was absolutely a requirement.I suppose the distinction one might make is whether the computer is, from the intended customer application point of view, a multipurpose machine like our desktop PCs and Macs, or whether it's designed to go into a system and do one thing for its lifespan.

author: Kjelt
author_rank: Super Contributor
timestamp: June 13, 2014, 08:00:20 am
content: Personal adds set up by HR after interviewing 3 or more managers are silly they always ask for the sheep with 6 legs, 20 years of experience and not older then 30:If you would be an alien and fullfill 100% of all those requirements in those adds you could easily get >$200k a year because you are the only one on the planet but they then offer $50k.After a year those adds are still open and the company has no clue why they can't find this perfect candidate

author: gocemk
author_rank: Regular Contributor
timestamp: June 13, 2014, 08:27:08 am
content: Quote from: Kjelt on June 13, 2014, 08:00:20 amRight now i am experiencing exactly the same, looking through the adds while searching for a job in the embedded software industry. Many times i am asking myself the question whether i am lagging too far behind, or is there someone who really can fullfil all those requirements and is unemployed and searching for a job.P.S. Sorry for the off-topic.

author: dannyf
author_rank: Super Contributor
timestamp: June 13, 2014, 11:14:10 am
content: QuoteThat (more around $225 - 250K) has been the going rate for Cortex-M programmers for sometime now, and even at that rate, it can be hard to hire and retain them.Cortex-A programmers are slightly more expensive.Programmers for 8-bitters are dime a dozen, on the other hand.

author: dannyf
author_rank: Super Contributor
timestamp: June 13, 2014, 01:11:33 pm
content: QuoteThat probably is a better definition of embedded computing than OS vs. non-OS definitions some people use. More and more embedded work is on at OS levels.However, that distinction can be difficult to draw sometimes. Like smartphones: what "applications" there are embedded?

author: nctnico
author_rank: Super Contributor
timestamp: June 13, 2014, 01:15:56 pm
content: Quote from: dannyf on June 13, 2014, 11:14:10 amOn which planet? Definitely not on earth!

author: FrankBuss
author_rank: Unknown
timestamp: June 13, 2014, 01:32:20 pm
content: Quote from: Lukas on June 10, 2014, 01:19:57 pmThen you haven't met meI can program microcontrollers:http://www.frank-buss.de/joystickadapter/index.htmlLinux on embedded systems:http://www.frank-buss.de/io-expander/index.htmlbut I know functional languages like Haskell as well, and even tried the functional programming paradigm (higher order functions, clsoures etc.) in Common Lisp:http://www.frank-buss.de/lisp/texture.htmlAny good programmer can write embedded software after some learning of the constraints and special aspects of the target platform, which might need some weeks for the first embedded system, but is faster for the next embedded system. But in my experience hardware developers can't write good embedded software (maintainable, bug free), without first some years of learning good programming practices.

author: dannyf
author_rank: Super Contributor
timestamp: June 13, 2014, 04:54:47 pm
content: QuoteAgreed. Programming is programming. How hard can it be?

author: SeanB
author_rank: Super Contributor
timestamp: June 13, 2014, 06:16:02 pm
content: Programming is easy, writing good code is harder, and writing bug free is even harder.

author: nctnico
author_rank: Super Contributor
timestamp: June 13, 2014, 07:05:47 pm
content: Quote from: FrankBuss on June 13, 2014, 01:32:20 pmThe latter goes for eveybody. Learning to program well takes 10 years and a couple of good mentors. Regarding writing embedded firmware: In my experience software people tend to struggle when it comes to hardware because they lack the knowledge on using test equipment.

author: FrankBuss
author_rank: Unknown
timestamp: June 13, 2014, 10:05:50 pm
content: Right, an embedded systems developer needs at least some basic understanding of electronics so that he doesn't forget to connect GND and wonders why the I2C signal looks so very noisy on the scope. Best is a team with experienced hardware AND software people working together.

author: gocemk
author_rank: Regular Contributor
timestamp: June 14, 2014, 12:43:14 pm
content: Few months ago, a local software company organized a 2-day embedded seminar for the students who are in Computer Science and Electronics classes. The microcontroller we worked on was LPC1769 on the LPCXpresso board and the LPCXpresso IDE was used for development. The tasks were to build something using the UART and the I2C peripherals on the MCU. Then, "judges" (Senior Embedded Developers from the company) will review the code and give grades. The two main criteria were: 1.Is the code working as it should be; 2. Code style and consistency.The software guys Computer Science) overall were quicker than the hardware guys (Electronics), and overall they produced some more readable code. But, when they were asked the question "Does your UART/I2C driver uses the polling method or interrupts? ", their answer was "I don't know, we just used the examples provided by LPCXpresso". Also, i think i was the only one in the group that asked for an oscilloscope to debug the I2C bus, others just used "trial and error", and got the job done.This showed me that although the software guys weren't quite familiarized with the MCU used, and were lacking some basic embedded knowledge, like polling vs. interrupts, they got the job done quicker and maybe better (more readable code) than the hardware guys. Mainly i think this is because they have more experience writing various kinds of software, and now when embedded programming is becoming more and more high-level, i think that they have the edge.

author: WarSim
author_rank: Frequent Contributor
timestamp: June 14, 2014, 02:42:24 pm
content: As a person with experience and qualifications on both side. Both disciplines seem to have some strange assumptions about the other.For example there is a thread that seems to claim that an optimizer is required to create optimized code. Therefore the only way to create the best code is through an optimizer.Another example is software focused people don't seem to understand the importance of analog nor the importance of an efficient cct.Sent from my iPad using Tapatalk

author: WarSim
author_rank: Frequent Contributor
timestamp: June 14, 2014, 02:46:25 pm
content: IMHO both disciplines are required to do the best job. But there is no reward for producing excellent products, good enough products as fast as possible.Sent from my iPad using Tapatalk

author: nctnico
author_rank: Super Contributor
timestamp: June 14, 2014, 04:02:06 pm
content: Quote from: WarSim on June 14, 2014, 02:42:24 pmAs others and me pointed out: you clearly have a wrong view on what an optimiser does. Compiling code consists of several phases where the last phase is removing unnecessary (machine) code and re-ordering instructions to optimise the execution pipeline. How that job is done depends on whether the user wants the most compact code, the fastest code or code which still debuggable. However: an optimiser won't turn a dump algorithme into a smart algorithm. Coming up with a smart algorithme is up to the programmer.

author: WarSim
author_rank: Frequent Contributor
timestamp: June 14, 2014, 04:07:32 pm
content: I know exactly what an optimizer is. I am not going to discuss qualifications and experience. When you say someone who has experience creating the optimizers you use that he/she didn't understand what they are is just stilly. To help you out in this regard I will stop responding.Sent from my iPad using Tapatalk

author: dannyf
author_rank: Super Contributor
timestamp: June 14, 2014, 05:51:48 pm
content: QuoteThat's surprising. Probably due to the fact that they are students - not as experienced.QuoteWell, embedded programming is programming so the software guys do tend to have an advantage, naturally.

author: FrankBuss
author_rank: Unknown
timestamp: June 14, 2014, 06:08:09 pm
content: Quote from: gocemk on June 14, 2014, 12:43:14 pmAnd the hardware guys knew if it was polling or interrupts? LPCXpresso hides a lot of the low-level details, so unless you browse the library code, you don't know what is used.BTW: I tried LPCXpresso and didn't like it, because code quality was not so good, see these examples:https://groups.google.com/d/msg/fpgalink-users/rwHlnmUgtZY/dID7aDhq6W4JAnd it was cumbersome to use in Eclipse (I prefer Makefiles).Finally I found "mbed" for the LPC chips, which is a really nice object oriented framework. An example:https://groups.google.com/d/msg/fpgalink-users/rwHlnmUgtZY/RsC-1HFEPHMJCan be used online with their website IDE and offline, too.

author: dannyf
author_rank: Super Contributor
timestamp: June 14, 2014, 06:38:47 pm
content: QuoteNot sure how one could tell from that if "code quality" is good - what is "code quality" anyway?QuoteThat's subjective. An equally valid argument can be made the other way around.QuoteThat's the "cloud" based compiler, I think. Not sure how it works when you are offline. Plus any IP / security concerns one may have in a corporate environment.Any, not sure how it could have addressed your "code quality" concern.For my own, I use CoIDE (eclipse) and loved it for the project wizard. No problem whatsoever. Knock on wood.

author: FrankBuss
author_rank: Unknown
timestamp: June 14, 2014, 07:13:49 pm
content: Quote from: dannyf on June 14, 2014, 06:38:47 pmSorry, I thought it was obvious: Comments like "Current Fix for LPC17xx, havent checked for others" and "for (i = 0; i < (4 * 1000); i++);" for a fixed delay smells bad. And the USB implementation I was testing didn't work well. There were some buffer problems, too, like no error message when the buffer is full etc.QuoteI know Eclipse and I've seen better integrations. There were lots of duplicated code and complicated project dependencies, which made it cumbersome to use, especially if you are targeting more than one LPC chip type.QuoteYou don't have to use their cloud service (which I didn't even test, but looks good). The code is all open source and you can compile your code locally:https://github.com/mbedmicro/mbedCode quality looked better for me, because I added some missing features to the library, added another library for FPGALink and it was more clean for me than the LPCXpresso code. And the object oriented base made it easier to program for it. For example I derived my USB class from the framework class, so less code duplication than usually with C.

author: dannyf
author_rank: Super Contributor
timestamp: June 14, 2014, 07:34:29 pm
content: Software delays aren't that big of a deal to me: as long as you know their limitations.The (default) LPCxpresso set-up does require some dependencies (CMSIS for example). That's not inherent to Eclipse, and not even inherent to LPCxpresso - you can set up your projects without such dependency.The debugging is a little slow and buggy. But that's minor. The IDE is a little bit bloated and slower than CoIDE. Too fancy for my taste.I typically use Keil / IAR / CoIDE + jlink. Some LPCxpresso board comes with mlink and you can set them up natively in IAR.

author: FrankBuss
author_rank: Unknown
timestamp: June 14, 2014, 07:41:49 pm
content: Compile it with the wrong optimize setting, and any "for" delays will be removed by the compiler, or even from one compiler version to the next. Once I fixed an interesting problem in the board setup code for an Atmel CPU, which didn't work anymore with a newer compiler, because of such bad coding practice. Any modern microcontroller has timers, so these should be used if you need a guaranteed minimum delay.

author: diyaudio
author_rank: Frequent Contributor
timestamp: June 14, 2014, 07:55:36 pm
content: Quote from: gocemk on June 14, 2014, 12:43:14 pmRather surprising computer science students cover operating systems.. concepts like No block-able I/O, threads, and Event Queues should be familiar to them... maybe the question was phrased wrong..

author: dannyf
author_rank: Super Contributor
timestamp: June 14, 2014, 07:56:03 pm
content: QuoteIt is a bad coding practice because it is not fool-proof.And you cannot write fool-proof code no matter how hard you try.QuoteAnd you will find yourself in a situation where you have exhausted timers available.You will not find an approach, any approach, that is preferred over / superior to another under ALL circumstances. Software delays have its pros and cons, and the same with hardware delays. You just need to figure out which is better for your particular applications.As to "optimization"-resistant software delays, there are many easy approaches for that.

author: gocemk
author_rank: Regular Contributor
timestamp: June 15, 2014, 08:58:46 am
content: Quote from: diyaudio on June 14, 2014, 07:55:36 pmComputer Science classes DO cover subjects like "Operating Systems", "System Software" and "Microprocessor Systems" (this is almost exclusively taught in assembly language and mostly with Intel 8085/6 and 386). But in my experience, the majority of the Computer Science students are much more interested in topics like C#.NET, Java, PHP, Python, SQL, databases...and similar. AI classes are increasingly popular lately, too.I graduated in Automation, Robotics and System Engineering, where it was essential to learn the basics of embedded programming in order to do some useful work (motion/motor control, DSP, data logging, interfacing over UART, CAN....)We hardly ever did any application software programming. Mostly it was some C# UI programs for interfacing with the computer's COM port for data logging over UART or similar.And of course programming PLC's in ladder logic, but i was never a huge fan of that, i was always more into microcontrollers.

author: Jeroen3
author_rank: Super Contributor
timestamp: June 15, 2014, 12:47:36 pm
content: QuoteWhich is called Real Time, and there are Real Time Operating System you should use if you have those requirement. Do not confuse it with the literal meaning of realtime, "now".http://en.wikipedia.org/wiki/Real-time_computingCode quality is achieved by being consistent. Using delayCounter or delay_counter or sometimes even iDelayCounter (i as in integer).And please do never forget:/*** @brief Executes this* @note This has effect on that* @param object structure* @return result of this*/anddelayCounter; /// counter for delay used with @p function()Even if you do not generate doxygen pages at all. You must be able to read and use the code reading only the H (or sometime C) files. You do not want to jump to a pdf for each function description.

author: calin
author_rank: Regular Contributor
timestamp: June 16, 2014, 05:32:33 am
content: No no he is right .. it is on Earth .. You just have to jump the pond .. I mean the Atlantic. I am from Europe and I agree you will never get that "score" in Europe. Also depends by area where you are in US ... and other skill factors. But I can say is not that uncommon to get over 200K in US if you are good at this.One rule .... make sure you never ever talk with HR bozo-s that literally have no idea what they read in a resume .Quote from: nctnico on June 13, 2014, 05:15:56 AM

author: Alexei.Polkhanov
author_rank: Frequent Contributor
timestamp: June 16, 2014, 03:59:45 pm
content: Quote from: calin on June 16, 2014, 05:32:33 amPlanet called US Pacific Coast. You just have to pay this kind of money to compete with every other company in the area.After speaking with few companies and recruiters in Europe over last 4-5 years I have feeling there will be no good Software/ASIC/EE Engineers in Europe soon - they pay half of US/Canada and have double tax on top of that.

author: madires
author_rank: Super Contributor
timestamp: June 16, 2014, 04:56:59 pm
content: Quote from: Alexei.Polkhanov on June 16, 2014, 03:59:45 pmYes, it's a funny business over here. The industry is moaning about a lack of engineers while the salaries don't reflect that. It seems to be just a strategy to keep the salaries down.

author: nctnico
author_rank: Super Contributor
timestamp: June 16, 2014, 05:39:23 pm
content: Quote from: calin on June 16, 2014, 05:32:33 amInteresting but living in the US? HELL NO!I think I'll try and get some customers from the US. I quit my job and become self employed a few years ago due to low salary.

author: Kjelt
author_rank: Super Contributor
timestamp: June 16, 2014, 09:28:45 pm
content: Quote from: Alexei.Polkhanov on June 16, 2014, 03:59:45 pmWell probably the cost of living is there also three times as high as in europe and probably the working hours will be at least one and a half times that of europe?But still I think the salaries are too low if you follow the economic rule that demands raises prices, you can,t see any of that and companies keep on bitching that they can not find personell, well maybe if you paid higher salaries the status would increase and more students would choose a technical study.

author: dannyf
author_rank: Super Contributor
timestamp: June 16, 2014, 09:36:09 pm
content: -but living in the US? HELL NO!-do you have an invitation to live in the us?otherwise, it is hard to turn down an offer before it is offered to you.

author: dannyf
author_rank: Super Contributor
timestamp: June 16, 2014, 09:41:14 pm
content: -demands raises prices, you can,t see any of that and companies keep-for a few long years, I spent half of my time recruiting. Even at those numbers we had a hard time getting 32bit people interested in us.for a comparable 8bit programmer, 100-150k would be a very good figure.so yeah, I would say that supply demand are working their magic.

author: djacobow
author_rank: Super Contributor
timestamp: June 16, 2014, 10:59:46 pm
content: I'm an EE but spent most of my career as a computer engineer. I've never been as fond of writing software as I am of designing hardware, but I've certainly done plenty of the former.For a rather long period of my career, I provided pre- and post-sales support to a microprocessor IP company that sold soft cores to be embedded in systems on chips. The HW folks, of course, wanted to get the constraints right so that Synopsys would generate a reasonable netlist and so that simulations would run correctly and they could see the machine boot and make successful bus transactions that covered every corner case.The SW people just needed So Much More handholding. I easily spent time 10x more time with SWEs than HWEs as a result. A few trends were common:- there was a sizeable contingent of SWEs who did not know how computers work, and had no interest in it. Buses, caches, etc, were all things that did what they did and there was no reason for a SWE to concern himself with them. This is not a recipe for embedded success.- among those and probably among more, was a contingent who, in their life, had never once thought about what happens before main() or even were aware that anything happened before main()- many had never given a moment's thought about how a program gets onto a machine- few had experience with a non-OS environment, or even an unhosted environment- concurrency: so many just didn't, couldn't get it- on-chip peripherals were a mystery to most unless wrapped by someone else in friendly functions- our architecture had an unfortunate quirk in that ISRs attached to interrupts above a certain priority level could not be written in C; They had to be in assembler, and you had to save and restore the registers you intended to clobber. This in theory was no great hardship, because usually with high priority interrupts, you wanted to get in and get out quickly, doing something simple. But the howls, HOWLS from developers about this limitation were endless- SW folks did not like funky memory maps, disjoint memory spaces (like DSP "X/Y" memories) and other hardware tricks that segmented their view of the world.- SW folks had a really hard time wrapping their heads around the idea that the hardware they were targeting might be buggy. After all, it was new, back from fab, and who knew what would be lurking there. But that never stopped any from trying, right out of the gate, to download their full multi-megabyte app to the target and being surprised that it didn't run. After all, it worked in the hosted simulator!All that said, after all the moaning and groaning and a little bit of learning curve, they were able to produce working software, some of which did amazing things.I guess my point is that in order to do embedded systems, you don't need to be an EE, you don't have to be comfortable with an oscilloscope, but you do need an awareness of how a computer system is organized. Computer Science programs did not seem to be teaching this. In fact, the most elite CS programs preferred to teach CS as a mathematics discipline, divorced from greasy, dirty hardware entirely. If graduates from such programs could not get off that mental track, they could not successfully program embedded systems.Anyway, my $0.02.

author: vvanders
author_rank: Regular Contributor
timestamp: June 17, 2014, 12:46:07 am
content: Quote from: Kjelt on June 16, 2014, 09:28:45 pmDepends on the area, Austin and Seattle both have reasonable cost of living so you can make out quite well. Most of those figures match up with what I've seen in Seattle.There's also been a huge issue with this in the Game Development industry. People regularly talk about the "UK brain drain". A good amount of the work is centered around London which also has obscene cost of living, why stay there when salaries are 2x stateside in an industry that already pays fairly low(anywhere from 30-50% less than standard SDE salaries).

author: vvanders
author_rank: Regular Contributor
timestamp: June 17, 2014, 12:49:37 am
content: Quote from: djacobow on June 16, 2014, 10:59:46 pmThese 3 can be just as critical outside the embedded space and it's possible to get a CS degree without knowing any of it(or native code for that matter!). Caching is especially relevant if you want to get moderately reasonable performance out of modern CPU architectures.

author: FrankBuss
author_rank: Unknown
timestamp: June 17, 2014, 01:10:50 am
content: Quote from: djacobow on June 16, 2014, 10:59:46 pmThere are a wide range of computer science areas. In theoretical computer science e.g. you prove some abstract properties of Turing Machines. Can be interesting and you can answer general questions about if something is programmable at all. Of course, usually students who do this can't program.

author: djacobow
author_rank: Super Contributor
timestamp: June 17, 2014, 01:46:53 am
content: Quote from: FrankBuss on June 17, 2014, 01:10:50 amIndeed, and there's nothing wrong with it. But a person needs to have a sense of what they know and don't know. However, if you were attracted to the math and aren't all that interested in the machines, embedded development /may/ not be for you.

author: djacobow
author_rank: Super Contributor
timestamp: June 17, 2014, 02:02:51 am
content: Absolutely. People have defined embedded systems in a bunch of ways on this forum, but one somewhat humorous way I like to think of it is: if you are looking for the most computing power you can get for X dollars, you are probably not doing embedded and may not even be doing engineering. On the contrary, if you have minimum computing requirements and are looking for the minimum Y dollars that will satisfy them, you are probably doing embedded engineering.To that end, wringing the most from the machine is important, and you can't get even close to it unless you have a good idea how the machine works. This means understanding the cache structure and any special capabilities (to lock lines or change associativity, or to put cache into a simpler "local memory" mode) as well any limitations, like no critical word first, or penalty performance for unaligned accesses, etc.Regarding concurrency, it's a big problem, and your'e right, it's not just embedded. I'm starting to think concurrency education needs to start in preschool. along with shapes and colors. EEs are usually better than this because they intuitively get that everything is happening asynchronously and simultaneously all the time, anyway. It is only in the ordered world of the computer that one could even imagine life withOUT concurrency.Quote from: vvanders on June 17, 2014, 12:49:37 am

author: miguelvp
author_rank: Super Contributor
timestamp: June 17, 2014, 02:09:47 am
content: Once we have to deal with 256 cores you bet we all get a hold of concurrencyActually you probably have noticed a big jump in interest for functional languages over the past few years.

author: Jeroen3
author_rank: Super Contributor
timestamp: June 17, 2014, 05:44:11 am
content: Two cores is difficult enough. Or even an (RT)OS with two collaborating tasks.But try vhdl, everything happens in parallel. Then you won't complain anymore.Quote@djacobow, Visual Studio and php people are not supposed to do the low level embedded software.You must know how your C(++) compiles to machine code.Test is simple, if they think Java or Microsoft JavaC#are good candidates for low level embedded software, you find someone else.

author: dannyf
author_rank: Super Contributor
timestamp: June 17, 2014, 10:16:46 am
content: QuoteThat makes zero sense, as the machine has no way of knowing how the binary code it executes is generated from assembler, C, or some other languages.

author: Kjelt
author_rank: Super Contributor
timestamp: June 17, 2014, 10:33:48 am
content: Quote from: dannyf on June 17, 2014, 10:16:46 amDepends on the micro and the compiler I think. It can make sense, we had the same problem with ISR's that the c compiler created, the compiler would insert it's standard code (push) before the first line of c but due to a bug in the micro we needed to do something directly at the entrance of the ISR but the compiler wouldn't let us so in that case we also had to write the ISR's in assembly. The next version of the compiler solved this bug however so we could use it again.

author: dannyf
author_rank: Super Contributor
timestamp: June 17, 2014, 10:54:13 am
content: QuoteThat's the point, isn't it? The fact that you have to write in assembly because of a buggy compiler isn't a valid basis to say that your hardware requires coding in assembly.

author: Kjelt
author_rank: Super Contributor
timestamp: June 17, 2014, 11:17:59 am
content: Quote from: dannyf on June 17, 2014, 10:54:13 amYou have your point.BTW it was a hardware bug and when it was finally in the errata sheet of the micro it took the compiler vendor another half year to implement and release that version and you know as well as me that a product SW team will not switch instanteneously to the newest compiler version each and every time.

author: dannyf
author_rank: Super Contributor
timestamp: June 17, 2014, 12:53:02 pm
content: QuoteI do that all the time. It pays to have somebody else to try out new compilers or new libraries first.

author: djacobow
author_rank: Super Contributor
timestamp: June 17, 2014, 07:57:30 pm
content: No, it makes perfect sense, you just lack the breadth of experience with different processor architectures.This particular processor architecture used register windows and had an ABI tailored to them. Essentially the physical registers of the machine become the top of the stack and only a portion of them are visible to the code at any one time. When a function makes a call or a return, the window is adjusted appropriately. The window is usually adjusted so that some old and new registers overlap. This allows a place to pass parameters for free. After a series of successive calls or returns, it may be necessary to copy registers to/from the real stack in memory, because of register underflow or overflow (you have run out of registers to slide the window down or up). In this case, the processor raises a window exception and an exception handler (essentially, an ISR) makes the appropriate copying and adjustment.In this architecture, it was possible to set interrupt priorities higher than the window exception handlers, hence, there was no easy way for a higher priority interrupt handler to know the state of the stack/windows and adjust appropriately. Moreover, even if such an handler simply saved away all the state, it would still need to set up its own stack and that stack would have to follow a different calling convention, since the window exceptions will not fire inside the higher priority ISR.This scheme may sound pretty bad to you, but it represents an interesting tradeoff. Because of windowing and the fact that most programs show good "call stack locality," register windowing with overlap is a strong overall performance win, at the expense of somewhat unpredictable call/ret performance (which is why higher than window exception ISRs are allowed) and the unfortunate aspect of ISRs that can't respect the C ABI.It's a successful but "stealth" architecture, often used in processors that are deeply embedded and not typically exposed to system programmers. They have shipped billions of cores, most as DSPs for video and audio, and for higher end baseband processors.-- dave jQuote from: dannyf on June 17, 2014, 10:16:46 am

author: dannyf
author_rank: Super Contributor
timestamp: June 17, 2014, 08:07:14 pm
content: QuoteThat would be the first computer in human history that could tell if it is running code generated by C or assembly.

author: djacobow
author_rank: Super Contributor
timestamp: June 17, 2014, 08:18:23 pm
content: Quote from: dannyf on June 17, 2014, 08:07:14 pmSPARC, AMD 29k, and i960 all used windows. I don't know what their spill/fill exception systems were, but all started as microprocessors (not microcontrollers), so I'd wager they did not have sophisticated interrupt systems, at least in early implementations, thus obviating this issue. The architect of my company's processor was pushing some "main processor" kinds of idea for performance, but it needed to work in more traditional embedded systems with lots of high frequency interrupt activity, so this system sort of split the baby.

author: dannyf
author_rank: Super Contributor
timestamp: June 17, 2014, 08:23:03 pm
content: QuoteSo? None of that explains how the architecture made it impossible to run C code.Now matter how much history you invoke, you still haven't explained how a machine could tell if the binary code it is executing comes from a C compiler or assembly compiler.No amount of history or fancy words can alleviate that.

author: djacobow
author_rank: Super Contributor
timestamp: June 17, 2014, 08:33:39 pm
content: There are two problems:1. the ISR is starting out in an environment without a C stack. It could set one up itself, but it needs to take care that it is not nested in another ISR that has also done the same2. The call and return instructions are designed to be able to throw exceptions. Except when you are in a high priority interrupt, they can't.I don't know what you're talking about an architecture that can tell how a binary was generated. It doesn't matter how the binary was generated. It matters that state of the machine when the code executes. Is that not clear? In one state, the machine's hardware will support the ABI, in another state, it won't. The high-priority ISRs operate in the latter state.ABIs are arbitrary, and one could create an ABI for this architecture that made no use of register windowing at all. Then the C compiler or anything or anyone else could generate code for /that/ ABI. That would solve this problem, but would have a huge performance impact by forgoing the windowing mechanism.Quote from: dannyf on June 17, 2014, 08:23:03 pmNo amount of insults will make up for the fact that you seem incapable of realizing that other people know things you don't.

author: dannyf
author_rank: Super Contributor
timestamp: June 17, 2014, 08:39:30 pm
content: QuoteI think there is only one problem: How does any of that explain the following:QuoteI can understand that a poorly written C compiler couldn't generate code for a particular piece of hardware. But how you can go from there to conclude that no code written in C can run on that architecture?As to your personal attack, you can keep it to yourself.

author: djacobow
author_rank: Super Contributor
timestamp: June 17, 2014, 08:53:27 pm
content: Quote from: dannyf on June 17, 2014, 08:39:30 pmI said that ISRs could not be written in C, which for all practical purposes is true. I then explained why this is so: that native C linkage mechanism would not work inside high priority interrupts.Yes, uncle, I admit, you got me. It is possible that C code could run. Just NOT CODE FROM A COMPILER THAT USED THE PRIMARY CALL/RETURN CAPABILITIES PROVIDED BY THE PROCESSOR, a major performance feature of the architecture. Such code also could not call functions generated by a compiler that used such call/return facilities.So, you could either use a compilation system with a custom ABI that performed very badly, or you could use one compiler for non-interrupt code and another compiler for the interrupt code, as long as neither tries to call the other, or you could write the high priority ISRs in assembler -- and even then the ISR could not call back into the "normally generated" C code.It was not a matter of a "poorly written C compiler."

author: dannyf
author_rank: Super Contributor
timestamp: June 17, 2014, 09:08:43 pm
content: QuoteExcept that your explanation doesn't hold water: nothing you said suggests that a C compiler couldn't be written to generate code to run in the isr.It is entirely possible, and it sounds increasingly likely here, that the architecture is such that that particular C compiler cannot generate code to run on it. But that's quite different from saying that no C compiler can generate code to run on it.

author: Bassman59
author_rank: Super Contributor
timestamp: June 17, 2014, 09:36:20 pm
content: Quote from: dannyf on June 17, 2014, 09:08:43 pmHe actually said that "ISRs above a certain priority could not be written in C." Everything else could be written in C.

author: djacobow
author_rank: Super Contributor
timestamp: June 17, 2014, 10:17:05 pm
content: The explanation holds water because it is correct.I said a C compiler could be written to generate code to run in the ISR. I also said that performance of code from that compiler would NECESSARILY be awful, and would be incompatible with the C code written to run in the ABI the machine was designed to run.Here is exactly where I said this:"Yes, uncle, I admit, you got me. It is possible that C code could run. Just NOT CODE FROM A COMPILER THAT USED THE PRIMARY CALL/RETURN CAPABILITIES PROVIDED BY THE PROCESSOR, a major performance feature of the architecture. Such code also could not call functions generated by a compiler that used such call/return facilities."This is absolutely true. I'm sorry you don't believe it, but I can't do anything about that. Fortunately for me, hundreds of customers designing multi-million gate SoCs with our IP were able to do understand the tradeoffs and design around them.Quote from: dannyf on June 17, 2014, 09:08:43 pm

author: dannyf
author_rank: Super Contributor
timestamp: June 17, 2014, 10:36:45 pm
content: QuoteBefore you get too far, here is exactly what you said:QuoteThat's some "gymnastics" to reconcile the two.

author: nctnico
author_rank: Super Contributor
timestamp: June 17, 2014, 11:00:17 pm
content: Quote from: djacobow on June 17, 2014, 10:17:05 pmDon't feed the trolls

author: djacobow
author_rank: Super Contributor
timestamp: June 17, 2014, 11:00:35 pm
content: No, it was written by a normal person who is not accustomed to dealing with Internet trolls who live to nitpick the finest details.I should have said "it is entirely impractical, inefficient, and pointless to write ISRs above a certain priority level in C."There are lots of smart people on this board who know all sorts of interesting things. I don't know that much about boards, analog electronics, and a zillion other things, but it just so happens I am have designed major portions of several very common microprocessors and am an expert in microprocessor and computer architecture. You actually had an opportunity to have an interesting discussion about microprocessors, ISA design, microarchitecture, ABIs, "C" linkage, etc, and all the interesting trade-offs that can be made regarding design complexity, performance, code size, latency, "compiler friendliness," and a zillion other things.Instead, you chose to turn this thread into an inquisition for your own childish pleasure.Quote from: dannyf on June 17, 2014, 10:36:45 pm

author: dannyf
author_rank: Super Contributor
timestamp: June 17, 2014, 11:05:17 pm
content: QuoteI shouldn't have wasted my time here,Quote"I am have"?I am have designed the universe,QuoteYeah, right.

author: dannyf
author_rank: Super Contributor
timestamp: June 17, 2014, 11:34:16 pm
content: QuoteI don't know why priority has anything to do with doing it in a particular language. I can understand that above certain performance requirement, doing it in C could potentially be an issue - even that is compiler / programmer dependent.But the same can be said about any language (including assembly) or any way of doing things. ie. there does not exist one approach that will always be practical, efficient or "un-pointless" above certain performance threshold.

author: WarSim
author_rank: Frequent Contributor
timestamp: June 18, 2014, 12:41:50 am
content: Good grief two pages later and the personal attacks continue. Will the thread returning to the topic anytime soon?Sent from my iPad using Tapatalk

author: djacobow
author_rank: Super Contributor
timestamp: June 18, 2014, 01:08:09 am
content: I'm sorry, guys. My original comment was that, from experience guiding a lot of people through a certain kind of embedded project (writing software to run in new custom ASICs incorporating one or more microprocessors) was that SW folks did not typically come "ready" to do good embedded work, and that a lot of details and problems of embedded systems were new to them. However, I can't remember running into a software person who could not become productive in such work after a period of introduction.So, in essence, my answer to "who should write embedded software" is basically anybody interested in it enough to deal with learning curve, willing to deal with targets with limited observability, tools that are not quite up to the level they're used to, etc. EEs may have some advantages, particularly bringing up unknown and unstable hardware, and SWEs have maybe an advantage managing the complexity of a large app, but overall success seemed to be about building up a toolbox of how to deal with what is often a very "raw" software environment, which anyone clever can do.Quote from: WarSim on June 18, 2014, 12:41:50 am

author: WarSim
author_rank: Frequent Contributor
timestamp: June 18, 2014, 01:13:23 am
content: Quote from: djacobow on June 18, 2014, 01:08:09 amNow that is a good answer I can agree with.Sent from my iPad using Tapatalk

author: vvanders
author_rank: Regular Contributor
timestamp: June 18, 2014, 01:49:59 am
content: Quote from: Jeroen3 on June 17, 2014, 05:44:11 amDon't mistake the tool for the engineer, as mentioned Ateml is using the Visual Studio shell. It's also very straightforward to use VS with makefiles to do embedded work. At the risk of starting another religious war I find it to be one of the best IDEs on the market.Also, while I agree that Java and C# have no place in performance critical code they are still extremely valuable languages. I challenge anyone to find a language that's more productive for building UI than C# and with C++/CLI you have an extremely seamless access to native code interop. There's many support parts of building embedded systems where tools like these can be extremely valuable.

author: nctnico
author_rank: Super Contributor
timestamp: June 18, 2014, 09:34:24 am
content: Quote from: vvanders on June 18, 2014, 01:49:59 amHave you tried Eclipse? The last time I used VS (a couple of years ago) it was a huge step backwards compared to Eclipse.QuoteI guess it depends on the framework you are using. C++/MFC is one of the least productive ways to write a GUI. However frameworks like WxWidgets or Qt make it much easier to write (portable!) GUI programs using almost any programming language. C# is just limited to Windows.One of my backburner projects is getting embedded Lua to work on an LPC1768. One of the problems I see with using C/C++ is that it is easy to shoot yourself in the foot. It makes sense to use a language which protects the programmer from making mistakes with pointers and buffer sizes. Another language I wanted to try on a microcontroller is Ada. According to some people Ada is excellent for mission critical software. The last time I looked there was no useable ARM port.

author: neslekkim
author_rank: Super Contributor
timestamp: June 18, 2014, 10:07:59 am
content: Quote from: nctnico on June 18, 2014, 09:34:24 ameLua and Gnat seems to be there?

author: Jeroen3
author_rank: Super Contributor
timestamp: June 18, 2014, 12:29:28 pm
content: I'm not really seeing use for a program running a program/script, especially embedded. As lua requires.It's like trying to script php or javascript for microcontrollers. Seems like a waste of resources. But Moore's law is not done yet in the mcu realm, so there is room for abstraction. As was available in desktop computing.Ada looks like a great example ofhttp://xkcd.com/927/http://en.wikipedia.org/wiki/Ada_(programming_language)

author: dannyf
author_rank: Super Contributor
timestamp: June 18, 2014, 12:40:56 pm
content: QuoteAgreed. However, a compiled version could be helpful.

author: nctnico
author_rank: Super Contributor
timestamp: June 18, 2014, 01:14:33 pm
content: Quote from: Jeroen3 on June 18, 2014, 12:29:28 pmNot quite. Modern scripting languages are compiled into 'bytecode' which is then executed. This bytecode in turn basically calls chunks of C (or assembly) code. The end result isn't much slower than using C directly (*). When I write software in C I add all kinds of sanity checks to prevent buffer overruns etc. It would be nice if all that is stowed under the hood. The only problem with executing bytecode is that you need a relatively large runtime binary.(*) In theory bytecode could be faster because the effort put in optimising the blocks of code can be smeared over a large number of projects. Powerbasic is such an example. Back in the old days Powerbasic produced faster code than most C compilers.

author: miguelvp
author_rank: Super Contributor
timestamp: June 18, 2014, 01:27:12 pm
content: Quote from: nctnico on June 18, 2014, 09:34:24 amI have used VS for the last 20 years, Eclipse is in my opinion more cumbersome but I guess if I was using Eclipse at work I would get used to it as well. Add Visual Assist to VS and nothing can touch it as far as an IDE goes.

author: vvanders
author_rank: Regular Contributor
timestamp: June 19, 2014, 02:01:58 am
content: Quote from: nctnico on June 18, 2014, 09:34:24 amYes, spend every day in it and it drives me mad. Even for Java development is leaves a lot to be desired. It doesn't handle external changes to files easily making it trivial to erase work if you don't manually refresh the project every time you make a change with external source control. The debugging UI is pretty non-intuitive(no way to consistently launch the same project if multiple projects are loaded) and doesn't have good watch support or many of other modern things you'd expect.There's a bit of a learning curve when adjusting to any IDE but I'd recommend you give VS another try, I've used both extensively and very much prefer it.Quote from: nctnico on June 18, 2014, 09:34:24 amNot true, checkout the Mono project(http://www.mono-project.com/WinForms) they've got a fully compliant WinForms implementation for OSX, Windows, Linux that's binary compatible with VS(http://www.mono-project.com/Guidelines:Application_Portability) or MonoDevelop, although VS's form builder is top-notch. I've spend a ton of time with wxWidgets and while it's a good crossplatform framework I'm easily 2-3x more productive in C#.In fact Mono has been making large strides in the mobile market along with game development with Unity using it as their primary language.Quote from: nctnico on June 18, 2014, 09:34:24 amLua is really nice, I've worked with it quite a bit and it shines on systems with relatively low memory requirements(outside of the uC space). I've seen it used on the PSP(24MB system memory) in a ~800KB preallocated block to handle all the game logic of quite a few shipped titles.

author: nctnico
author_rank: Super Contributor
timestamp: June 19, 2014, 11:34:52 am
content: Quote from: vvanders on June 19, 2014, 02:01:58 amI was expecting this reply. AFAIK Mono development is not supported by Microsoft so you always have to watch out for using things which are not (yet) supported or buggy. It says so on the page you linked to

author: vvanders
author_rank: Regular Contributor
timestamp: June 20, 2014, 01:06:17 am
content: If you were expecting that reply you should have qualified things a bit more than saying C# is limited to windows. Sure you can't use WPF or some of the fancier things but there's full WinForms and .net framework support which is plenty enough to be effective.I know for a fact that Mono is very well maintained and ships software on many, many other platforms than windows in large volume.Also what you were talking about with scripting based bytecode being faster that C only applies to a very small subset of architectures. If you're looking at raw instruction count then they can be fairly close. However the true limiter for performance on most modern computing architectures(including some of the mid-high end ARM chips) is memory accesses and cache misses. If you've got DRAM and a L1 cache then memory layout and access patterns matter more than an order of magnitude than how optimized the code is. This is why radix sort tends to destroy all other sorting algorithms on small key(2-3x word size), < ~2000 items.Thistalk from Herb Sutter(@24 mins) andthispaper both do a good job of explaining why memory layout matters more. To my knowledge very few scripting or interpreted languages allow explicit layout of memory structures(C# is one of them).