标签: development

T2 Development Board V1.0.0的资料包括以下部分： 硬件设计手册：提供了开发板的详细硬件设计信息，包括MCU选型、外设和接口连接方式等。 软件开发手册：提供了开发板的软件开发信息，包括开发环境设置、外设驱动程序编写和应用程序开发等。 示例代码：提供了多个示例代码，包括基本的外设驱动程序、应用程序和中间件等。 硬件和软件工具链：提供了开发板所需的硬件和软件工具链，包括编译器、调试器、仿真器等。 社区支持：提供了社区的联系方式和支持信息，包括论坛、在线商城和文档等。 以上资料均为英文版，可以在官方网站上下载。如果需要中文版资料，可以在社区中寻求支持。 T2 Development Board V1.0.0是一款基于NXP i.MXRT1062 MCU的开发板，旨在帮助开发人员快速开发和测试嵌入式系统。该开发板具有丰富的外设和接口，包括CAN、I2C、SPI、UART等，适用于各种应用场景。为了方便用户使用，T2 Development Board V1.0.0配备了完整的硬件设计手册和软件开发手册，提供了详细的硬件设计和软件开发信息。此外，开发板还提供了多个示例代码和硬件和软件工具链，方便用户进行开发和调试。T2 Development Board V1.0.0的社区是一个非常活跃和有用的资源，用户可以在其中获取更多信息和支持。社区提供了论坛、文档、教程和代码示例等资源，方便用户学习和使用开发板。总之，T2 Development Board V1.0.0是一款功能强大且易于使用的开发板，其丰富的资料和社区支持可帮助开发人员快速开发和测试嵌入式系统。

T2 Development Board V1.0.0是一款基于NXP i.MXRT1062 MCU的开发板，旨在帮助开发人员快速开发和测试嵌入式系统。该开发板具有丰富的外设和接口，包括CAN、I2C、SPI、UART等，适用于各种应用场景。 T2 Development Board V1.0.0的社区是一个由开发板用户和贡献者组成的社区，他们分享经验、解决问题、提供支持并帮助彼此了解如何使用开发板进行开发。社区成员可以访问各种资源，包括论坛、文档、教程和代码示例，以获得有关开发板的更多信息和帮助。 此外，社区还提供了一个在线商城，其中包含开发板和相关组件的可用选项列表。用户可以在商城中购买所需的组件和配件，以支持他们的项目开发。 总之，T2 Development Board V1.0.0是一款功能强大的开发板，其社区为开发人员提供了丰富的资源和支持，帮助他们快速开发和测试嵌入式系统。

Amid a huge number of recent news stories about systems getting hacked I read several in the area of IoT about Zigbee getting hacked , Chrysler getting hacked , and Tesla getting both hacked and fixed . Granted, part of the rush came from the recent DEFCON conference in Las Vegas, but such stories still can be very depressing for engineers trying to build the next generation of devices. Are we really doing the world a favor by creating ever more complex systems that inevitably expose the users to hackers?   This got me thinking about the nature of system development. We have all seen descriptions of the various stages of maturity for any technology, but I realized that the ones I have seen are missing a step. Consider the one below.   A more realistic description of the stages of technology.   The first three stages are familiar, but consider the consequence of implementing a design to make it broadly useful. That wider audience is also what makes it interesting to hackers. There is really no point to hacking something that no one is using, and new technology is always the most fertile ground in terms of complexity and the availability of exploitable holes. It seems like these days a new technology barely has a chance to enjoy being in the ‘Useful’ stage before it gets pushed into the ‘Abuse-able’ stage.   Up until now I have carefully avoided characterizing the hacking involved as being “white hat” or “black hat” hacking. In fact, even those two characterizations are too limiting. The only difference between them is if the flaw is discovered by the good guys or the bad guys. What I have come to realize over the years is that the world is infinitely more complex than that.   Right now we have encryption technology that is good enough that the FBI is very publicly calling for the creation of back doors into it. Their rationale is that the bad guys are using it too effectively to do what they do that makes them bad. That is a very reasonable argument when the FBI is hunting pedophiles. Does the same argument hold when it is the Chinese government that is hunting underground discussion of the Tiananmen Square massacre? The definition of good guys and bad guys is very open to interpretation.   Garage mechanics have been hacking cars just about as long as there have been cars in an effort to make them faster or in some other way more interesting. This is considered abuse by the car manufacturers and the government regulators, but it is very different from finding ways to break into or take control of someone else’s car.   Whether any type of hacking of a new technology is good or bad is a judgement that largely depends on how the hack is used. As I said, the world is an infinitely complex place – this is what makes it interesting. Whether or not we are really making it better by making it even more complex is a question that we each have to answer for ourselves.   Larry Mittag is a consultant on connected embedded systems .

Twenty-five of Silego's GPAK4 mixed-signal FPGA development kits are currently winging their way to the folks who teased and tempted me the most with their imaginative project proposals.   One of these guys was Harjit Singh, who hails from the state of Washington. In his email to me, Harjit managed to press two of my hot buttons at the same time -- space and robots.   More specifically, in Harjit's message he said: "I'd like to be considered for a GPAK4 development kit because I want to see if I can use it to create a robust watchdog system for use in space. Also, I build robots and I would like to see if I can use a GPAK4 for sensor conditioning."   Now, when someone says "robot," I have to admit that my knee-jerk reaction is of a full-size humanoid creation like Ada in my Alex + Ada column. In this case, however, Harjit was actually referring to a micro-mouse incarnation as illustrated in this video (also, you can click here to see a bunch of videos staring Harjit as himself along with his performing mice).   Did you see how fast the mouse was? If that scampered across the floor in front of me when I wasn't expecting it, I think you'd hear me squealing like a schoolgirl while leaping onto the nearest table. These micro-mice are really rather impressive, especially when you compare them to this demonstration by Claude Shannon in the 1950s. My initial reaction when I first saw this was: "Good grief, how on earth could they make robot mice this small in the 1950s?"   It only took me a few seconds to realize what they must have done -- or at least, to decide the way in which I would have achieved this using the technology of the time -- and I was right. As you'll see if you watch the video, the "brain" of the mouse is a honking big relay computer that's hidden out of sight, while its "muscles" (motive force) are actually located in the table.   Returning to today's micro-mice, Harjit informs me that mouse competitions take place across the US, and that the next big one will occur in March at APEC 2016 .   All of this has set my mind buzzing. First, I wonder what Claude Shannon's reaction would have been if I were to hop into my trusty time machine and take one of Harjit's micro-mice back to the 1950s. Second, I want to build my own micro-mouse. I'm hoping to persuade Harjit and his fellow Mouseketeers (I'm sorry, I couldn’t help myself) to write a column telling us more about the physical specifications for the mice and the goals of the competition. Until then, if you'll excuse me, I'm going to watch some more mouse videos (and it's not often you'll hear me say that).

I had wanted to get away from the city, but when I got to a small mountain town to work on software development for a police, life-flight, and special mission communication system, I had no idea what I was getting myself into. My OJT (on-the-job training) had consisted pretty much of being told to buy parts to build a development PC, and also of being given a quick run-down on how the compiler and assembler were used to create code. Then I was given a list of bugs, along with a list of routines to be converted into assembly language to make room for the fixes. (Our first generation C compiler was about 5 to 7X less efficient than the assembler, and the project had run out of room without completing the firmware.) I would frantically fix bugs during the day, take routines home to convert into assembly into the wee hours of the morning, and return to work at 7:00 a.m. to start all over again. The idea was to keep on converting routines until we could obtain a better version of the compiler. In the meantime, we started re-designing the processor to add more memory. Eventually, we got enough features working (for the most part) and shipped a system to the FBI. They used the system with some success, but—like all of our other customers—bug reports kept coming in. Suspecting there had to be a better way, I visited the local aeronautical university library and began reading every book I could find on the subject of developing avionics software. There were things like creating the requirements first, such as code size and schedule estimates, and also using LINT applications and runtime memory checking. I started to apply some of these concepts to my own coding, resulting in much greater success on some of the later features. One day the phone rang and we were informed that a planeload of FBI agents were on their way to the plant. They needed their system to be working, but it had one bug they could not work around. The next day there was a special agent in the plant manager's office, another agent in my boss's office, and yet another agent assigned to be with me while I went to the aircraft and tried to duplicate their issues. First, we set up one of our lab systems to match the configuration they were using. Everything seemed to work fine until we took the system into the air and activated things in a different way. Pressing just one button introduced a totally different aspect of system operation. One-by-one we located bugs and fixed them. Finally, we identified the major culprit—a pointer in one area of the code that was impacting another section of the code. We got that bug fixed. Walter the mechanic got the plane put back together and working, at which point the agents set off on their way to track down America's most wanted. Later, the company I was working for was bought out by another company, at which time I finally managed to get formal training in DO-178B and software project management. If only I had been given this training earlier, my life would have been much easier and my code would have been much better. William Murray Electrical Engineer