You are right in that anyone with enough knowledge not to feel completely lost in an area (over the hump?) will enjoy the challenges of learning something new.
I myself would feel quite nervous being moving to the level of instruction sets etc as there is a huge amount of background knowledge needed to feel comfortable in the environment.
It may make a difference if you are able to support the developer in learning how to do this. Having someone there you can ask and talk through issue with is a huge help in that sort of domain change.
It may be worth having the developer assigned to a smaller project with others as a first step and see how that goes. If he expresses enthusiasm to try another project, things should flow on from there.
话虽如此，我见过更多成功从事 PC 开发的嵌入式程序员，而不是相反的人。 （当然我可能没有看到公平的横截面）
I think that it depends on the way that they program in their chosen environment, and the type of embedded work that you're talking about.
Working on an embedded linux platform, say, is a far smaller jump than trying to write code on an 8 bit platform with no operating system at all.
If they are the type of person that has an understanding of what is going on underneath the api and environment that they are used to, then it won't be too much of a stretch to move into embedded development.
However, if their world view stops at the high level api that they've been using, and they have no concept of anything beneath that, they are going to have a really hard time.
As a (very) general statement if they are comfortable working on multithreaded applications they will probably be ok, as that shares some of the same issues of data volatility that you have when working on embedded projects.
With all of that said, I've seen more embedded programmers successfully working in PC development than I have the reverse. (of course I might not have seen a fair cross section)
"But when I talk to him about doing low-level programming, he simultaneously express interest and also doubt/uncertainty about joining the project." -- That means you let him try and you prepare to hire someone else in case he doesn't pass the learning curve.
如果您真的想深入了解，请使用 arduino 套件 - 便宜、免费的编译器和库，开始很容易，但是你必须连接电线才能做一些有趣的事情，这对于一个不情愿的软件工程师来说可能是一个太大的障碍。 但如果有一点帮助，并在正确的方向上稍加推动，他们就会非常兴奋地拥有一个像夜行者灯一样摆动*的小 LED 显示屏……
-Adam
*是的，这是一个技术工程术语。
At the end of the day, everything is an API.
Need to write code for an SPI peripheral inside a microcontroller? Well, get the datasheet or hardware manual, and look at the SPI peripheral. It's one, big, complex API.
The problem is that you have to understand the hardware and some basic EE fundamentals in order to comprehend what the API means. The datasheet isn't written by and for SW developers, it was written for hardware engineers, and maybe software engineers.
So it's all from the perspective of the hardware (face it - the microcontroller company is a hardware company filled with hardware/asic engineers).
Which means the transition is by no means simple and straightforward.
But it's not difficult - it's just a slightly different domain. If you can implement a study program, start off with Rabbit Semiconductor's kits. There's enough software there so a SW guy can really dig in with little effort, and the HW is easy to deal with because everything is wrapped in nice little libraries. When they want to do something complex they can dig into the direct hardware access and fiddle at the lower level, but at the same time they can do some pretty cool things such as build little webservers or pan/tilt network cameras. There are other companies with similar offerings, but Rabbit is really focused on making hardware easy for software engineers.
Alternately, get them into the Android platform. It looks like a unix system to them, until they want to do something interesting, and then they'll have the desire to attack that little issue and they'll learn about the hardware.
If you really want to jump in the deep end, go with an arduino kit - cheap, free compilers and libraries, pretty easy to start off with, but you have to hook wires up to do something interesting, which might be too big of a hurdle for a reluctant software engineer. But a little help and a few nudges in the right direction and they will be absolutely thrilled to have a little LED display that wibbles* like the nightrider lights...
我合作过的最好的嵌入式程序员都接受过 EE 培训，并在工作中学习了 SW。 最糟糕的嵌入式开发人员是最近的计算机科学毕业生，他们认为软件是解决问题的唯一方法。 我喜欢将嵌入式编程视为软件金字塔的底部。 它是一个稳定的抽象层/基础，使应用程序开发人员的生活变得轻松。
The best embedded programmers I've worked with are EE trained and learned SW on the job. The worst embedded developers are recent CS graduates who think SW is the only way to solve a problem. I like to think of embedded programming as the bottom of the SW pyramid. It's a stable abstraction layer/foundation that makes life easy for the app developers.
"Hard" is an extremely relative term. If you're used to thinking in the tight, sometimes convoluted way you need to for small embedded code (for example, you're a driver developer), then certainly it's not "hard".
Not to "bash" (no pun intended) shell scripters, but if you write perl and shell scripts all day, then it might very well be "hard".
Likewise if you're a UI guy for Windows. It's a different kind of thinking.
1) The context may switch to an interrupt between each machine instruction. Since high level language constructs may map to multiple assembly instructins, this might even be within a line of code, e.g. long var = 0xAAAA5555. If accessed in an interrupt service routine, in a 16 bit processore var might only be half set.
2) Visibility into the system is limited. You may not even have output to Hyperterm unless you write it yourself. Emulators don't always work that well or consistently (though they are way better than they used to be). You will have to know how to use oscilloscopes and logic analyzers.
3) Operations take time. For example, say your serial transmitter uses an interrupt to signal when it is time to send another byte. You could write 16 bytes to a transmit buffer, then clear interrupts and wonder why your message is never sent. Timing in general is a tricky part of embedded programming.
4) You are subject to subtle race conditions that occur only rarely and are very difficult to debug.
5) You have to read the manual. A lot. You can't make it work by fooling around. Sometimes 20 things have to be set up correctly to get what you are after.
6) The hardware doesn't always work or is easy to damage, and it takes a while to figure out that you broke it.
7) Software repairs in embedded systems are usually very expensive. You can't just update a web page. A recall can erase any profit you made on the device.
There are probably more but I've got this race condition to solve...
我喜欢回到 Windows 桌面环境，用精心设计的类来扇动我的翅膀，额外伸展我的腿几个时钟周期，使用不必要的内存量进行诊断等。
在过去的某些嵌入式设备上，我几乎不支持 fseek() （ANSI C 标准文件函数）。 如果幸运的话，“看门狗”可以提供有关崩溃位置的线索。 更不用说在单线程抢占式沼泽中与用户通信的痛苦了。
嗯，你知道我的意思。 在我看来，这并不一定很难，但这是一个很大的飞跃，可能很少会重用您当前的经验。
问候
罗伯特
This is very subjective I guess, his reasons could be many. But if he's like me, I know where he's coming from. Let me explain.
In my career I've dedicated 6 years to the telecom industry, working a lot with embedding SDK middleware into low-end mobile phones etc.
Most embedded environments I've experienced are like harsh weather for a programmer, you constantly have to overcome limitations in resources etc. Some might find this a challenge and enjoy it for the challenge itself, some might feel close to "the real stuff" - the hardware, some might feel it limits their creativity.
I'm the kind who feels it limits my creativity.
I enjoy being back in Windows desktop environment and flap my wings with elaborate class designs, stretch my legs a few clockcycles extra, use unnecessary amounts of memory for diagnostics etc.
On certain embedded units in the past, I hardly had support for fseek() (an ANSI C standard file function). If lucky, a "watchdog" could give clues to where something crashed. Not to mention the pain of communicating with the user in single-threaded preemptive swamps.
Well, you know what I'm getting at. In my opinion it's not necessarily hard, but it's quite a leap, with potentially little reuse of your current experience.
There is a very real difference in mindset from user-level application development (ie, general purpose PC or Web applications) to hard deadline, real-time response application development (ie, the hardware/software interface).
Interrupts, instruction sets, context switching and hard resource constraints are relatively unknown to your average developer. I'm assuming here that your 'average developer' is not an Electrical/Electronic or other Engineer by training.
The transition for this developer you mention may be well outside his comfort zone. Some of us like stretching like that. Others of us may have decided the view isn't worth the climb.
Likewise, folks who've been in the hardware area (ie, Engineers) often have difficulty with the assumptions and language of software development.
These are gross generalities, of course, but hopefully give some insight.
He needs to be comfortable with the low-level stuff, but mostly for debugging and field issues. There is a serious learning curve depending on the architecture, but not impossible. On the other hand, the low-level code takes (in general) more time and debugging than higher-level code. So if you need to be going back to low-level all the time, then perhaps something isn't right in the design. Even for the embedded controls I've built, I spend the vast majority of time in high-level code. Although when you have issues, it is extremely advantageous to have a very good low-level knowledge.
我是一名 EE 转型的软件工程师。 我更喜欢低级编程。 据我所知，大多数接受过经典培训的软件开发人员都不想在他们希望 api 调用的级别上进行操作。 所以对我来说这是双赢，我创建了低级驱动程序和 API 供他们使用。 有一个“新”学位，至少是我上大学以来的新学位，叫做计算机工程师。 嗯，它可能是电气工程学位而不是计算机科学，但它是软件和数字硬件基础知识的完美结合。 与我在这个领域共事过的人对低水平更加适应。
I am an EE turned Software Engineer. I prefer programming low level. Most software developers classically trained that I know do not want to operate at this level they want apis to call. So for me it is a win win, I create the low level driver and api for them to use. There is a "new" degree, at least new since I went to college, called Computer Engineer. Hmm, it might be an electrical engineering degree not computer science, but it is a nice mix of software and digital hardware basics. The individuals that I have worked with from this field are much more comfortable with low level.
If the individual is not comfortable or willing then place them somewhere where they are comfortable. Let them do documentation or work on the user interface. If all of the work at the company requires low level work then this individual needs to do it or find another job. Dont sugar coat it.
I also think they will enjoy it once they get over the hump, the freedom you have at that level, not hindered by operating systems, etc. Recently I witnessed a few co-workers experience for the first time seeing their software run under simulation. Every net within the processor and other on chip peripherals. No you dont have a table on a gui (debugger) showing the current state of the memory, you have to look at the memory bus, look for the address you are interested in, look for a read or write signal and the data bus. I worry about the day that silicon arrives and they no longer have this level of visibility. Will be like an addict in detox.
Well, I cut my teeth on hardware when I started reading Popular Electronics at age 14 – this was BEFORE personal computers, in case you were wondering and if you weren’t well, you know anyway. lol
I’ve done the low level bit-bang stuff on the 8048/51 microprocessor, done PIC’s and some other single chip variations and of course Rabbit Semiconductor. (great if you're into C). That’s great (and fun) stuff; Yes, there is a different way of looking at things – not harder, but some of that information is a bit harder to come by as it isn’t as discussed as the software issues. (Of course, this depends on the circle of friends with which you associate, eh).
But, having said all of this, I want to remind you of a technology that started to bridge the gap for programmers into the world of hardware and has since become a very MAJOR player and that is the .NET micro framework. You can find information on this technology at the following;
It addresses some of the same issues that .NET web development addressed in that you can use some (quite a bit, actually) of your existing PC based knowledge in the new environments – Some caution, of course, as your target machine doesn’t have 4 GIG of RAM – it may only have 64K (or less)
Starting in version 2.5 of the .NET micro framework, you have access to networking and web services – way kewl, eh? It doesn’t stop there … Want to control the lights in your house? How about a temp recording station? All with the skills you already have. Well, mostly -- Check out the link.
The SDK plugs into your VisualStudio IDE. There are a number of “Development Kits” available for a very reasonable amount of cash – Now, what would normally take a big learning curve in components, building a circuit board and wiring up “stuff” can be done reasonably easy with a dev kit and some pretty simple code – Of course, you may need to do the occasional bit bang operation, but more and more sensor folks are providing .NET micro framework drivers – so, the hardware development may be closer than you think…
I like both. Embedded challenges me and really gets me going in a visceral way. Making something that affects the macro physical world is very satisfactory. But I've had to do a lot of catch up on the electrical/electronics end, since my bachelor's is in computer science. I've a pretty generalist background, where I studied ai, graphics, compilers, natural language, etc. Now I'm doing graduate work in embedded systems. The really tough part is adjusting to the lack of runtime facilities like an operating system.
Low-level embedded programming also tends to include low-level debugging. Which (in my experience) usually involves (at least) the use of an oscilloscope. Unless your colleague is going to be happy spending at least some of the time in physical contact with the hardware and thinking in terms of microseconds and volts, I'd be tempted to leave them be.
I would say different, as you would need to employ different development patterns that you won't use in other kind of environment. The time constraint for instance could requires a learning curve. However being curious, would be a quality for a developer, wouldn't be?
发布评论
评论（17）
你是对的，任何拥有足够知识而不会在某个领域完全迷失（越过驼峰？）的人都会享受学习新东西的挑战。
我自己在进入指令集等级别时会感到非常紧张，因为需要大量的背景知识才能在环境中感到舒适。
如果您能够支持开发人员学习如何执行此操作，情况可能会有所不同。 有一个人可以向您询问并讨论问题，这对于此类领域的变更有很大帮助。
作为第一步，可能值得将开发人员与其他人一起分配到一个较小的项目，然后看看进展如何。 如果他表达了尝试另一个项目的热情，事情应该从那里开始。
You are right in that anyone with enough knowledge not to feel completely lost in an area (over the hump?) will enjoy the challenges of learning something new.
I myself would feel quite nervous being moving to the level of instruction sets etc as there is a huge amount of background knowledge needed to feel comfortable in the environment.
It may make a difference if you are able to support the developer in learning how to do this. Having someone there you can ask and talk through issue with is a huge help in that sort of domain change.
It may be worth having the developer assigned to a smaller project with others as a first step and see how that goes. If he expresses enthusiasm to try another project, things should flow on from there.
我认为这取决于他们在所选环境中编程的方式以及您所讨论的嵌入式工作的类型。
例如，在嵌入式 Linux 平台上工作比在根本没有操作系统的 8 位平台上编写代码要小得多。
如果他们是那种了解自己习惯的 api 和环境下发生的事情的人，那么进入嵌入式开发不会太困难。
然而，如果他们的世界观停留在他们一直在使用的高级 API 上，并且他们对下面的任何东西都没有概念，那么他们将度过一段非常困难的时期。
作为（非常）一般性的陈述，如果他们能够轻松地处理多线程应用程序，那么他们可能会没问题，因为这与您在处理嵌入式项目时遇到的数据波动性问题相同。
话虽如此，我见过更多成功从事 PC 开发的嵌入式程序员，而不是相反的人。 （当然我可能没有看到公平的横截面）
I think that it depends on the way that they program in their chosen environment, and the type of embedded work that you're talking about.
Working on an embedded linux platform, say, is a far smaller jump than trying to write code on an 8 bit platform with no operating system at all.
If they are the type of person that has an understanding of what is going on underneath the api and environment that they are used to, then it won't be too much of a stretch to move into embedded development.
However, if their world view stops at the high level api that they've been using, and they have no concept of anything beneath that, they are going to have a really hard time.
As a (very) general statement if they are comfortable working on multithreaded applications they will probably be ok, as that shares some of the same issues of data volatility that you have when working on embedded projects.
With all of that said, I've seen more embedded programmers successfully working in PC development than I have the reverse. (of course I might not have seen a fair cross section)
“但是当我和他谈论进行低级编程时，他同时表达了兴趣，同时也对加入该项目表示怀疑/不确定。” ——这意味着你让他尝试，并准备雇用其他人，以防他无法通过学习曲线。
"But when I talk to him about doing low-level programming, he simultaneously express interest and also doubt/uncertainty about joining the project." -- That means you let him try and you prepare to hire someone else in case he doesn't pass the learning curve.
我一开始是一名软件工程师，现在是硬件工程师！
重要的是要了解它是如何运作的并受到激励！
i began as a SW engineer i'm now HW one !
the important is to understand how it works and to be motivated !
归根结底，一切都是 API。
需要为微控制器内的 SPI 外设编写代码吗？ 好吧，获取数据表或硬件手册，然后查看 SPI 外设。 这是一个庞大而复杂的 API。
问题是您必须了解硬件和一些基本的 EE 基础知识才能理解 API 的含义。 该数据表不是由软件开发人员编写的，也不是为软件开发人员编写的，它是为硬件工程师（也许还有软件工程师）编写的。
所以这都是从硬件的角度来看的（面对现实 - 微控制器公司是一家充满硬件/asic 工程师的硬件公司）。
这意味着过渡绝非简单明了。
但这并不困难——只是领域略有不同。 如果您可以实施学习计划，请从 Rabbit Semiconductor 的套件开始。 那里有足够的软件，因此软件人员可以毫不费力地深入研究，并且硬件很容易处理，因为所有内容都包含在漂亮的小库中。 当他们想做一些复杂的事情时，他们可以深入研究直接硬件访问并在较低级别进行调整，但同时他们可以做一些非常酷的事情，例如构建小 网络服务器 或 pan /倾斜网络摄像机。 还有其他公司也提供类似的产品，但 Rabbit 真正专注于让软件工程师轻松使用硬件。
或者，让它们进入 Android 平台。 对他们来说，它看起来像是一个unix系统，直到他们想做一些有趣的事情，然后他们就会有解决这个小问题的愿望，他们就会了解硬件。
如果您真的想深入了解，请使用 arduino 套件 - 便宜、免费的编译器和库，开始很容易，但是你必须连接电线才能做一些有趣的事情，这对于一个不情愿的软件工程师来说可能是一个太大的障碍。 但如果有一点帮助，并在正确的方向上稍加推动，他们就会非常兴奋地拥有一个像夜行者灯一样摆动*的小 LED 显示屏……
-Adam
*是的，这是一个技术工程术语。
At the end of the day, everything is an API.
Need to write code for an SPI peripheral inside a microcontroller? Well, get the datasheet or hardware manual, and look at the SPI peripheral. It's one, big, complex API.
The problem is that you have to understand the hardware and some basic EE fundamentals in order to comprehend what the API means. The datasheet isn't written by and for SW developers, it was written for hardware engineers, and maybe software engineers.
So it's all from the perspective of the hardware (face it - the microcontroller company is a hardware company filled with hardware/asic engineers).
Which means the transition is by no means simple and straightforward.
But it's not difficult - it's just a slightly different domain. If you can implement a study program, start off with Rabbit Semiconductor's kits. There's enough software there so a SW guy can really dig in with little effort, and the HW is easy to deal with because everything is wrapped in nice little libraries. When they want to do something complex they can dig into the direct hardware access and fiddle at the lower level, but at the same time they can do some pretty cool things such as build little webservers or pan/tilt network cameras. There are other companies with similar offerings, but Rabbit is really focused on making hardware easy for software engineers.
Alternately, get them into the Android platform. It looks like a unix system to them, until they want to do something interesting, and then they'll have the desire to attack that little issue and they'll learn about the hardware.
If you really want to jump in the deep end, go with an arduino kit - cheap, free compilers and libraries, pretty easy to start off with, but you have to hook wires up to do something interesting, which might be too big of a hurdle for a reluctant software engineer. But a little help and a few nudges in the right direction and they will be absolutely thrilled to have a little LED display that wibbles* like the nightrider lights...
-Adam
*Yes, that's a technical engineering term.
我合作过的最好的嵌入式程序员都接受过 EE 培训，并在工作中学习了 SW。 最糟糕的嵌入式开发人员是最近的计算机科学毕业生，他们认为软件是解决问题的唯一方法。 我喜欢将嵌入式编程视为软件金字塔的底部。 它是一个稳定的抽象层/基础，使应用程序开发人员的生活变得轻松。
The best embedded programmers I've worked with are EE trained and learned SW on the job. The worst embedded developers are recent CS graduates who think SW is the only way to solve a problem. I like to think of embedded programming as the bottom of the SW pyramid. It's a stable abstraction layer/foundation that makes life easy for the app developers.
“硬”是一个极其相对的术语。 如果您习惯于以紧凑的、有时令人费解的方式思考小型嵌入式代码（例如，您是驱动程序开发人员），那么这当然不“难”。
不是针对“bash”（无双关语）shell 脚本编写者，但如果您整天编写 perl 和 shell 脚本，那么它很可能会“很难”。
如果您是 Windows 用户界面人员，同样如此。 这是一种不同的思维方式。
"Hard" is an extremely relative term. If you're used to thinking in the tight, sometimes convoluted way you need to for small embedded code (for example, you're a driver developer), then certainly it's not "hard".
Not to "bash" (no pun intended) shell scripters, but if you write perl and shell scripts all day, then it might very well be "hard".
Likewise if you're a UI guy for Windows. It's a different kind of thinking.
为什么嵌入式开发“难”：
1）上下文可能会切换到每个机器指令之间的中断。 由于高级语言构造可以映射到多个汇编指令，因此这甚至可能在一行代码内，例如long var = 0xAAAA5555。 如果在中断服务例程中访问，则在 16 位处理器中 var 可能仅设置一半。
2) 系统的可见性有限。 除非您自己编写，否则您甚至可能没有超级术语的输出。 模拟器并不总是工作得那么好或一致（尽管它们比以前好得多）。 您必须知道如何使用示波器和逻辑分析仪。
3）操作需要时间。 例如，假设您的串行发送器在需要发送另一个字节时使用中断来发出信号。 您可以将 16 个字节写入传输缓冲区，然后清除中断并想知道为什么您的消息从未发送。 一般来说，计时是嵌入式编程中一个棘手的部分。
4) 您会受到微妙的竞争条件的影响，这种竞争条件很少发生并且非常难以调试。
5）你必须阅读手册。 很多。 你不能通过胡闹来让它发挥作用。 有时需要正确设置 20 件事情才能得到您想要的东西。
6) 硬件并不总是能工作或者很容易损坏，并且需要一段时间才能发现你损坏了它。
7) 嵌入式系统中的软件修复通常非常昂贵。 您不能只更新网页。 召回可能会抹去您在该设备上赚取的任何利润。
可能还有更多，但我有这个竞争条件需要解决......
Why embedded development is "hard":
1) The context may switch to an interrupt between each machine instruction. Since high level language constructs may map to multiple assembly instructins, this might even be within a line of code, e.g. long var = 0xAAAA5555. If accessed in an interrupt service routine, in a 16 bit processore var might only be half set.
2) Visibility into the system is limited. You may not even have output to Hyperterm unless you write it yourself. Emulators don't always work that well or consistently (though they are way better than they used to be). You will have to know how to use oscilloscopes and logic analyzers.
3) Operations take time. For example, say your serial transmitter uses an interrupt to signal when it is time to send another byte. You could write 16 bytes to a transmit buffer, then clear interrupts and wonder why your message is never sent. Timing in general is a tricky part of embedded programming.
4) You are subject to subtle race conditions that occur only rarely and are very difficult to debug.
5) You have to read the manual. A lot. You can't make it work by fooling around. Sometimes 20 things have to be set up correctly to get what you are after.
6) The hardware doesn't always work or is easy to damage, and it takes a while to figure out that you broke it.
7) Software repairs in embedded systems are usually very expensive. You can't just update a web page. A recall can erase any profit you made on the device.
There are probably more but I've got this race condition to solve...
我想这是非常主观的，他的原因可能有很多。 但如果他像我一样，我就知道他来自哪里。 让我解释。
在我的职业生涯中，我在电信行业工作了 6 年，在低端手机等中嵌入 SDK 中间件方面做了很多工作。
我经历过的大多数嵌入式环境对于程序员来说就像恶劣的天气，你必须不断克服限制有些人可能会觉得这是一个挑战，并喜欢挑战本身，有些人可能觉得接近“真正的东西”——硬件，有些人可能觉得这限制了他们的创造力。
我是那种觉得它限制了我的创造力的人。
我喜欢回到 Windows 桌面环境，用精心设计的类来扇动我的翅膀，额外伸展我的腿几个时钟周期，使用不必要的内存量进行诊断等。
在过去的某些嵌入式设备上，我几乎不支持 fseek() （ANSI C 标准文件函数）。 如果幸运的话，“看门狗”可以提供有关崩溃位置的线索。 更不用说在单线程抢占式沼泽中与用户通信的痛苦了。
嗯，你知道我的意思。 在我看来，这并不一定很难，但这是一个很大的飞跃，可能很少会重用您当前的经验。
问候
罗伯特
This is very subjective I guess, his reasons could be many. But if he's like me, I know where he's coming from. Let me explain.
In my career I've dedicated 6 years to the telecom industry, working a lot with embedding SDK middleware into low-end mobile phones etc.
Most embedded environments I've experienced are like harsh weather for a programmer, you constantly have to overcome limitations in resources etc. Some might find this a challenge and enjoy it for the challenge itself, some might feel close to "the real stuff" - the hardware, some might feel it limits their creativity.
I'm the kind who feels it limits my creativity.
I enjoy being back in Windows desktop environment and flap my wings with elaborate class designs, stretch my legs a few clockcycles extra, use unnecessary amounts of memory for diagnostics etc.
On certain embedded units in the past, I hardly had support for fseek() (an ANSI C standard file function). If lucky, a "watchdog" could give clues to where something crashed. Not to mention the pain of communicating with the user in single-threaded preemptive swamps.
Well, you know what I'm getting at. In my opinion it's not necessarily hard, but it's quite a leap, with potentially little reuse of your current experience.
Regards
Robert
从用户级应用程序开发（即通用 PC 或 Web 应用程序）到严格期限、实时响应应用程序开发（即硬件/软件接口），思维方式存在着非常明显的差异。
对于普通开发人员来说，中断、指令集、上下文切换和硬资源限制相对陌生。 我在这里假设您的“普通开发人员”不是经过培训的电气/电子或其他工程师。
您提到的这位开发人员的转变可能远远超出了他的舒适区。 我们中的一些人喜欢这样伸展身体。 我们中的其他人可能认为这样的景色不值得攀登。
同样，从事硬件领域工作的人员（即工程师）常常难以理解软件开发的假设和语言。
当然，这些都是笼统的概括，但希望能提供一些见解。
There is a very real difference in mindset from user-level application development (ie, general purpose PC or Web applications) to hard deadline, real-time response application development (ie, the hardware/software interface).
Interrupts, instruction sets, context switching and hard resource constraints are relatively unknown to your average developer. I'm assuming here that your 'average developer' is not an Electrical/Electronic or other Engineer by training.
The transition for this developer you mention may be well outside his comfort zone. Some of us like stretching like that. Others of us may have decided the view isn't worth the climb.
Likewise, folks who've been in the hardware area (ie, Engineers) often have difficulty with the assumptions and language of software development.
These are gross generalities, of course, but hopefully give some insight.
他需要熟悉底层的东西，但主要是调试和现场问题。 根据架构的不同，有一个严重的学习曲线，但并非不可能。 另一方面，低级代码（通常）比高级代码需要更多的时间和调试。 因此，如果您需要一直返回到低级别，那么设计中可能存在某些问题。 即使对于我构建的嵌入式控件，我也将绝大多数时间花在高级代码上。 尽管当您遇到问题时，拥有非常好的低级知识是非常有利的。
He needs to be comfortable with the low-level stuff, but mostly for debugging and field issues. There is a serious learning curve depending on the architecture, but not impossible. On the other hand, the low-level code takes (in general) more time and debugging than higher-level code. So if you need to be going back to low-level all the time, then perhaps something isn't right in the design. Even for the embedded controls I've built, I spend the vast majority of time in high-level code. Although when you have issues, it is extremely advantageous to have a very good low-level knowledge.
我是一名 EE 转型的软件工程师。 我更喜欢低级编程。 据我所知，大多数接受过经典培训的软件开发人员都不想在他们希望 api 调用的级别上进行操作。 所以对我来说这是双赢，我创建了低级驱动程序和 API 供他们使用。 有一个“新”学位，至少是我上大学以来的新学位，叫做计算机工程师。 嗯，它可能是电气工程学位而不是计算机科学，但它是软件和数字硬件基础知识的完美结合。 与我在这个领域共事过的人对低水平更加适应。
如果个人不舒服或不愿意，那么就把他们放在他们舒服的地方。 让他们做文档或在用户界面上工作。 如果公司的所有工作都需要低水平的工作，那么这个人就需要做它或找到另一份工作。 不要糖衣它。
我还认为，一旦克服了困难，他们就会享受这种自由，不受操作系统的阻碍等。最近，我目睹了一些同事第一次看到他们的软件在模拟下运行。 处理器和其他片上外设内的每个网络。 不，你没有 GUI（调试器）上的表格显示内存的当前状态，你必须查看内存总线，查找你感兴趣的地址，查找读或写信号和数据总线。 我担心有一天硅到达时，他们将不再具有这种水平的可见性。 会像戒毒的瘾君子一样。
I am an EE turned Software Engineer. I prefer programming low level. Most software developers classically trained that I know do not want to operate at this level they want apis to call. So for me it is a win win, I create the low level driver and api for them to use. There is a "new" degree, at least new since I went to college, called Computer Engineer. Hmm, it might be an electrical engineering degree not computer science, but it is a nice mix of software and digital hardware basics. The individuals that I have worked with from this field are much more comfortable with low level.
If the individual is not comfortable or willing then place them somewhere where they are comfortable. Let them do documentation or work on the user interface. If all of the work at the company requires low level work then this individual needs to do it or find another job. Dont sugar coat it.
I also think they will enjoy it once they get over the hump, the freedom you have at that level, not hindered by operating systems, etc. Recently I witnessed a few co-workers experience for the first time seeing their software run under simulation. Every net within the processor and other on chip peripherals. No you dont have a table on a gui (debugger) showing the current state of the memory, you have to look at the memory bus, look for the address you are interested in, look for a read or write signal and the data bus. I worry about the day that silicon arrives and they no longer have this level of visibility. Will be like an addict in detox.
嗯，当我 14 岁时开始阅读《大众电子》时，我就开始接触硬件了——那是在个人电脑出现之前，如果你想知道，如果你身体不好，无论如何你都知道。 哈哈
我已经在 8048/51 微处理器上完成了低级位爆炸的工作，完成了 PIC 和其他一些单芯片变体，当然还有 Rabbit Semiconductor。 （如果你喜欢 C 那就太好了）。 这是很棒的（而且很有趣）的东西； 是的，有一种不同的看待事物的方式——并不难，但其中一些信息有点难以获得，因为它不像软件问题那样被讨论。 （当然，这取决于你交往的朋友圈，呃）。
但是，说了这么多，我想提醒您一项技术，它开始弥合程序员与硬件世界的差距，并从此成为一个非常重要的参与者，这就是 .NET 微框架。 您可以在以下位置找到有关该技术的信息；
http://msdn.microsoft.com/en-us/embedded/bb267253。 ASPX
它解决了 .NET Web 开发所解决的一些相同问题，您可以在新环境中使用一些（实际上是相当多的）现有的基于 PC 的知识 – 当然，作为您的目标机器，需要注意一些没有 4 GIG 的 RAM – 它可能只有 64K（或更少）
从 .NET 微框架 2.5 版本开始，您可以访问网络和 Web 服务 – 方式 kewl，是吗？ 它并不止于此......想控制你家里的灯光吗？ 临时录音站怎么样？ 全部具备您已有的技能。 嗯，主要是——查看链接。
SDK 插入您的 VisualStudio IDE。 有许多价格非常合理的“开发套件”可供选择 - 现在，通常需要大量学习组件、构建电路板和连接“东西”的事情可以通过开发套件相当轻松地完成和一些非常简单的代码 - 当然，您可能需要偶尔进行位爆炸操作，但是越来越多的传感器人员正在提供.NET微框架驱动程序 - 因此，硬件开发可能比您想象的更接近……
希望它有所帮助。 ..
Well, I cut my teeth on hardware when I started reading Popular Electronics at age 14 – this was BEFORE personal computers, in case you were wondering and if you weren’t well, you know anyway. lol
I’ve done the low level bit-bang stuff on the 8048/51 microprocessor, done PIC’s and some other single chip variations and of course Rabbit Semiconductor. (great if you're into C). That’s great (and fun) stuff; Yes, there is a different way of looking at things – not harder, but some of that information is a bit harder to come by as it isn’t as discussed as the software issues. (Of course, this depends on the circle of friends with which you associate, eh).
But, having said all of this, I want to remind you of a technology that started to bridge the gap for programmers into the world of hardware and has since become a very MAJOR player and that is the .NET micro framework. You can find information on this technology at the following;
http://msdn.microsoft.com/en-us/embedded/bb267253.aspx
It addresses some of the same issues that .NET web development addressed in that you can use some (quite a bit, actually) of your existing PC based knowledge in the new environments – Some caution, of course, as your target machine doesn’t have 4 GIG of RAM – it may only have 64K (or less)
Starting in version 2.5 of the .NET micro framework, you have access to networking and web services – way kewl, eh? It doesn’t stop there … Want to control the lights in your house? How about a temp recording station? All with the skills you already have. Well, mostly -- Check out the link.
The SDK plugs into your VisualStudio IDE. There are a number of “Development Kits” available for a very reasonable amount of cash – Now, what would normally take a big learning curve in components, building a circuit board and wiring up “stuff” can be done reasonably easy with a dev kit and some pretty simple code – Of course, you may need to do the occasional bit bang operation, but more and more sensor folks are providing .NET micro framework drivers – so, the hardware development may be closer than you think…
Hope it helps...
我想说这并不难，只是需要不同的知识、不同的考虑。
I would say it is not any harder, it just requires a different knowledge set, different considerations.
我两个都喜欢。 嵌入式对我提出了挑战，并真正让我发自内心地前进。 制作一些影响宏观物理世界的东西非常令人满意。 但由于我的学士学位是计算机科学，因此我必须在电气/电子方面做很多努力。 我有一个相当通才的背景，我研究了人工智能、图形、编译器、自然语言等。现在我正在嵌入式系统方面进行研究生工作。 真正困难的部分是适应操作系统等运行时设施的缺乏。
I like both. Embedded challenges me and really gets me going in a visceral way. Making something that affects the macro physical world is very satisfactory. But I've had to do a lot of catch up on the electrical/electronics end, since my bachelor's is in computer science. I've a pretty generalist background, where I studied ai, graphics, compilers, natural language, etc. Now I'm doing graduate work in embedded systems. The really tough part is adjusting to the lack of runtime facilities like an operating system.
低级嵌入式编程还往往包括低级调试。 （根据我的经验）通常涉及（至少）示波器的使用。 除非你的同事愿意至少花一些时间与硬件进行物理接触并以微秒和伏特的方式进行思考，否则我会很想不去管他们。
Low-level embedded programming also tends to include low-level debugging. Which (in my experience) usually involves (at least) the use of an oscilloscope. Unless your colleague is going to be happy spending at least some of the time in physical contact with the hardware and thinking in terms of microseconds and volts, I'd be tempted to leave them be.
对“硬”一词的同意是相对的。
我会说不同，因为您需要采用在其他类型的环境中不会使用的不同开发模式。
例如，时间限制可能需要学习曲线。
然而，好奇心是开发人员的一种品质，不是吗？
Agreed on the "hard" term is quite relative.
I would say different, as you would need to employ different development patterns that you won't use in other kind of environment.
The time constraint for instance could requires a learning curve.
However being curious, would be a quality for a developer, wouldn't be?