标签: platform

题记：   虽有嘉肴，弗食，不知其旨也；虽有至道，弗学，不知其善也。是故学然后知不足，教然后知困。知不足，然后能自反也；知困，然后能自强也。故曰：教学想长也。《兑命》曰：“学学半。”其次之谓乎。   我们的文化真是博大精深，短短的几句话，精准地描述了教与学之间的关系。学学半——教人也是学习的一半。 读研的时候，带本科生的实验课，面对千奇百怪的提问，可以深刻的感受到自己的不足——不能够讲解地让别人理解，就说明自己的理解不够透彻，做不到庖丁解牛。 在写博文的时候，也有这种感觉，想要负责任地写出一篇文章，不仅仅要在技术上说服自己，还要思考用什么样的方式才能让读者更快更好地明白自己要说的东西，文章难写啊……   闲话休提，书归正传。   1 在 Vivado 中添加 axi-gpio IP 核，并挂载到 axi-lite 总线上 添加 IP 核后，可以利用指令自动完成 axi-lite 接口的连接。这里我把自动生成的时钟和复位信号发生模块删除了，保留着应该也没有影响。 在关闭 Vivado 之前，记得查看一下 IP 的物理地址，或者在 SDK 中查看。后面修改 dts 文件的时候会用到。 2 制作 BOOT.bin 文件 这里也不用多说，网上教程也很多。 3 编写驱动并编译生成 *.ko 文件 这里给出代码，编译方法参考上一篇博文 4 修改 dts 文件，将设备信息添加至设备树 reg = 0x41200000 0x1000; 里面的两个参数分别对应 axi_gpio 的物理地址和寄存器空间大小 还有一个坑： 两个 compatible 属性的内容，是设备和驱动注册的关键，匹配时利用该字段进行对比。具体如何进行匹配，后续再深入剖析。 5 生成 dtb 文件 6 启动系统，加载驱动 以上两步，可以参考之前的博文，这里不再重复。 7 输入指令，操作 led 实际上这是 Digilent 提供的教程，做完之后，是一头雾水，根本不明白到底怎么回事，稀里糊涂地就可以操作 led 了。 当时想的问题有： i) 在学习最简单的 Linux 驱动时，有 module_init() 和 module_exit() 函数，在加载和卸载驱动时会被调用，为什么这里没有？ ii) 这个好像和一般的设备驱动不太一样，什么是 platform driver ？ iii) 搜索了一下 platform driver ，更加迷糊了，不过 platform driver 和普通的设备驱动是有区别的，既然开始了，就先研究 platform driver 吧。

Balloons, they seem like a simple product. I can't imagine anything being difficult about sealing a couple of layers of plastic film together. Well, that's what I use to think before I was asked to build a machine to make foil balloons. Over the last 17 years, I have been involved with the design, manufacture, and installation of these machines. They weigh in at about 10,000 pound and are 30 feet long. A large percentage has gone to customers outside the United States. Each installation comes with its own challenges. When they are international, those challenges can be significant. A few years ago on an installation in Central Mexico, I ran into a problem I'd never encountered before and at the time struggled with what could be causing it. This was the first sale to this customer and my first visit to their facility. Things weren't going as planned, the machine wasn't running. The customer was asking why, and I couldn't explain why or what I was going to do about it. These machines have a servomotor to index product underneath a number of seal heads. Each index has a controlled stop using optical registration of the film to position the pre-printed images under the seal heads. I specified the components, wrote the software and had done this many times before. I thought I knew the equipment inside and out and yet randomly the machine had a hiccup with the motion. Sometimes, the index speed would be off, going too fast or too slow. Other times the index length was wrong. Every hiccup seemed to be different without pattern. Every time this would happen, the very next index seemed to be fine. It might happen every 5 minutes or only once an hour. I spent a day monitoring the in-coming power, looking for power anomalies to explain the malfunction. I went through every electrical connection of the machine thinking somewhere I would find a loose wire that could account for the random nature of this problem. I contacted the drive manufacturer, hoping they would tell me about some firmware revision that I wasn't aware of and point me in a direction. I found nothing and at this point I had a machine that didn't work, limited resources and the customer breathing down my neck. It was getting towards the end of the third day and still no real clue with what could be wrong. I had the display (Operator Interface) disconnected from the servo to use the serial port for my laptop and had been monitoring the drive most of the day. It was then that it dawned on me that the machine had run without incident all day with the display unplugged. I plugged the display back in and sure enough about 5 or 10 minutes of running, and there it was. I left the display unplugged for the next shift as a test and the machine preformed perfectly without exception. Ok, so now I had a clue where to look. Like most I instantly thought; I have a noise problem. This particular display has two serial ports. The second port was talking to a PLC, and that didn't seem to have any problems, but that is far from a definitive conclusion. I didn't have equipment with me to monitor the data stream. So I really couldn't prove or disprove that noise was there or a problem. My experience with industrially hardened components is that if you follow some basic "best practices," noise is seldom the issue. I ultimately decided I would have to dig deeper, and got the customer to agree to run the machine as is (display disconnected) until I could find a solution to the problem. After returning home, I made a number of calls to both the display and servo drive manufacturers. In conversation with one of the drive firmware engineers, I was asked the interval between data transfers from the display to the drive. I had to check and according to the data sheet, every 500ms. After discussing the amount of data I was transmitting, he told me that was probably too often. It was concluded I was overflowing the serial buffer. I had used this display / drive combination before, but previously it was just for data display. In hindsight, earlier installations probably had the same problem, but they were easy to overlook when the machine performance wasn't affected. After thinking about it further, it all made sense. The machine checks every cycle for motion parameter changes and recalculates the motion profile based on those values. When an overflow occurred, data was lost and the register being written to only received part of the data. Then the program would use that corrupted data to calculate the next move. There's little wonder why the problem manifested itself in such a random manor. The fix ended up simple; reduce the polling frequency of the display. I have used 10 or 15 different brands of servos over the years. I have used even more brands of PLCs and operator interface units. For the most part, I have had little problems integrating various brands of components, but when you run into compatibility problems seldom will you find the answer in the supplied manuals, you'll most likely have to dig deeper. - Mike Frazier Mike Frazier is vice president of Axis Automation in Hartland, Wisonsin, United States. For most of the last 30 years, Mike has been designing and building automation equipment for numerous industries. In the beginning of his automation career, he worked as a machinist, serving an Apprenticeship at Centerline Industries in Waterloo, Wisonsin. In those early years, Mike took an interest in the control side of his projects. Since that time, he has developed controls systems based on PLCs, Motion controllers, PCs, and embedded controllers as well as combinations of those platforms.

            SPARTAN-6开发板还在绘制PCB当中，因为做了很多修改，所以一直到现在还没有送出去加工。这款SPARTAN-6开发板的名字暂定为“神州九号” ，以方便与其它开发区别开来。         修改之一是针对SPARTNA-6的配置的。原来打算用XILINX的专用配置芯片来配置SPARTAN-6，芯片为Platform Flash 的 SPI 的串行存储器，虽然配置方案比较成熟，可靠，但唯一的缺点就是配置芯片价格太高，6M位的芯片价格需要6多元，如果需要12M的容量，价格就更高了。所以更换了一下配置芯片。       先说一下官方推荐的上面的配置方案，尽管我更换了其它芯片去配置我的“神州九号”开发板，但原理上的东西都是一样的，都是串行的SPI存储器（当然还有其它的并行的配置方案）。SPI一般都是4线制的，这里也不例外，串行时钟由SPARTAN-6发出，因此这种配置方式也可以叫主要串行配置方式（这一点ALTERA的FPGA配置方式差不多）。配置原理图如下，        除了配置芯片价格比较高以外，这种配置方式速度也较慢，因为一个时钟周期只能传输一位配置数据，各下面的方案一个时钟传输4位相比，肯定是慢了。      “神州九号”开发板采用了如下的配置方案，和上面的差不多，只是SPI的速度换成了X4的，配置原理图如下：      除了上面的串行配置方案，SPARTAN-6还可以采用并行的配置方式，可以显著提高配置速度，这就是主动并行BPI模式。       “神州九号”开发板用的SPI存储器型号为W25Q64BV，电路图如下，       完整的原理图待开发板调试成功之后，会一并放在这里。 近期文章：  LINK在线调试LZ3014 USB3.0开发板（REV2）， SPARTAN-6开发板简单介绍（暂定名：神州九号）   我的博客： http://bbs.ednchina.com/BLOG_liangziusb_440752.HTM 我的淘宝店铺： http://shop64171919.taobao.com 我的实体店铺：北京新中发电子市场2557号 良子.2012年    承接USB开发工程 代写USB毕设 QQ：2687652834    392425239