鉴于我的综合背景，我能覆盖从模拟电子到编写简单与RDBMS后端交互的应用程序等领域。
我目前在一家开发解决特定行业问题硬件的公司工作。我们有一个经验丰富的程序员，他已经为PC编写了商业应用程序、视频游戏和其他很多东西。但是当我跟他谈论低级编程时，他同时表达了兴趣和疑虑/不确定加入这个项目。
即使是关于PC，他似乎更喜欢操作语言级别而不是更低级别的东西（指令集，ISR）。尽管如此，他是个聪明的人，我认为他一旦度过初始学习阶段就会喜欢这项工作。但也许那只是我自己对底层编程的热情在说话……如果他真的感兴趣，也许他已经开始朝着那个方向学习了呢？
您是否有在软件到硬件（或低级软件）转换方面的经验？或者，更好的是，您有将纯软件人员转型为低级别编程方面的经验吗？
编辑：
附言：我很想听听回答者的背景是什么-- EE，CS，还是两者兼备？
说到底，一切都是API。
需要在微控制器内部为SPI外设编写代码吗？获取数据表或硬件手册，并查看SPI外设。这是一个大而复杂的API。
问题在于，在理解API含义之前，您必须了解硬件和一些基本的EE基础知识。数据表不是由软件开发人员编写和编写的，而是为硬件工程师和可能的软件工程师编写的。
因此，这一切都是从硬件的角度来看的（承认吧-微控制器公司是一个充满硬件/ ASIC工程师的硬件公司）。
这意味着过渡绝不是简单明了的。
但并不困难-它只是略有不同的领域。如果您可以实施学习计划，请从 Rabbit Semiconductor 的套件开始。有足够的软件，以便SW人员可以轻松地深入挖掘，而HW易于处理，因为所有内容都包装在不错的库中。当他们想要做一些复杂的事情时，他们可以深入直接访问硬件并在较低级别上进行操作，但与此同时，他们也可以做一些相当酷的事情，例如构建小型 Web服务器 或 pan / tilt网络摄像机。还有其他公司提供类似的产品，但Rabbit确实专注于使硬件易于软件工程师使用。
或者，将其引导到Android平台。对他们来说，它看起来像Unix系统，直到他们想做一些有趣的事情，然后他们会有攻击这个小问题的愿望，他们会学习硬件知识。
如果你真的想深入了解，可以选择一个Arduino套件——价格便宜，有免费的编译器和库，很容易入门，但是你必须通过连接电线来完成一些有趣的事情，这对于一个不情愿从事软件工程师的人来说可能是一个太大的障碍。但只要给他们一点帮助和正确的指引，他们就会非常高兴拥有一个像夜行者灯光一样摇晃的LED显示屏......-Adam *是的，那是一个技术工程术语。我曾经合作过的最好的嵌入式程序员都接受过电气工程师的培训，在工作中学习软件编程技术。而最差的嵌入式开发人员则是最近才毕业的计算机科学专业学生，他们认为软件是解决问题的唯一途径。我认为嵌入式编程是软件金字塔底层，是一个稳定的抽象层/基础，使应用程序开发变得容易。
“难”是一个极其相对的术语。如果你习惯于为小型嵌入式代码（例如，你是驱动程序开发人员）进行紧密、有时复杂的思考方式，那么当然它不是“难”的。
并非要“抨击”（无意冒犯）shell脚本编写者，但如果你整天写perl和shell脚本，那么它可能会很“难”。
同样，如果你是Windows的UI设计师，那么这是一种不同的思维方式。
为什么嵌入式开发很“难”：
1）每个机器指令之间上下文可能会切换到中断。由于高级语言结构可能映射到多个汇编指令，这甚至可能在一行代码内发生，例如long var = 0xAAAA5555。如果在中断服务例程中访问，在16位处理器中，var可能只设置了一半。
2）对系统的可见性有限。除非自己编写输出，否则您甚至可能没有输出到Hyperterm。仿真器并不总是工作得那么好或一致（虽然它们比以前要好得多）。您将需要知道如何使用示波器和逻辑分析仪。
3）操作需要时间。例如，假设您的串行传输器使用中断来表示何时发送另一个字节。您可以将16个字节写入传输缓冲区，然后清除中断，并想知道为什么消息从未发送。总体而言，时间是嵌入式编程的棘手部分。
4）您会遇到微妙的竞争条件，这些条件很少发生且非常难以调试。
5）您必须阅读手册。很多。不能通过胡闹使其工作。有时必须正确设置20个东西才能得到您想要的结果。
6）硬件并不总是工作或易于损坏，并且需要一段时间才能弄清楚您是否损坏了它。
7）嵌入式系统中的软件维修通常非常昂贵。您不能只更新一个网页。召回可能会抹去您在设备上获得的任何利润。
可能还有更多，但我现在有一个竞争条件要解决...
从用户级应用程序开发（即通用PC或Web应用程序）到硬性截止日期、实时响应应用程序开发（即硬件/软件接口）的思维方式存在着非常真实的差异。
中断、指令集、上下文切换和硬资源约束对于普通开发人员来说相对不太熟悉。在这里我假设你所说的“普通开发者”并非受过电气/电子或其他工程师培训。
这位开发者的转型可能会远远超出他的舒适区。我们中有些人喜欢这样的挑战，而另一些人可能已经决定放弃。
同样，那些从事硬件领域的人（即工程师）往往难以理解软件开发的假设和语言。
当然，这些只是粗略的概括，但希望能提供一些见解。
我曾经在8048/51微处理器上做过低级位操作，也做过PIC和其他一些单片机变体，当然还有Rabbit Semiconductor。（如果你喜欢C语言，这很棒）。这是很棒（而且有趣）的东西；是的，有一种不同的看待事物的方式 - 不是更难，但其中一些信息可能会比软件问题更难以获取。（当然，这取决于你所交往的朋友圈）。
但是，说了这么多，我想提醒你一种技术，它开始为程序员进入硬件世界架起了桥梁，现在已经成为一个非常重要的角色，那就是.NET微框架。你可以在以下网址找到关于这项技术的信息。
http://msdn.microsoft.com/en-us/embedded/bb267253.aspx
