張法憲表示，這部機器人造價新台幣 200多萬元，比軍方、警方自國外購置移除爆裂物機器人約新台幣700 萬元低廉。
這款機器人採用了多個村田自有的元件，包括用以在電路儲存電力的電容器、控制運動的感測器，以及跟外接交換資訊的通訊模組。該公司表示，由於有感於日本兒童對於科學的興趣日漸低落，該公司過去曾推出過一款騎著腳踏車的「村田頑童(Murata Boy)」機器人，並主動聯繫各學校提供教育機會，藉由展示該機器人讓學童們知道科學有多麼好玩。
新誕生的「村田小妹」外觀與個性是由一個女性成員組成的團隊負責設計，得克服機器人騎著獨輪車維持平衡與移動的挑戰，並讓它利用一顆超音波感測器來與週遭物體保持距離，同時透過一具實況攝影機來傳送移動的影像。
嬌小的「村田小妹」高50公分、體重5公斤，使用兩個陀螺儀感測器發出的訊號來偵測機器人的傾斜角度，以協助控制獨輪車該前進或後退；在其軀幹部並裝置了一個飛輪(fly wheel)，用以監測機器人的兩側，好維持左右平衡。
「村田小妹」身上的一對收/發超音波感測器，能透過訊號發出與彈回的時間，來偵測自己與障礙物間的距離。外界指令以及各種資料的接收/發送，則是透過行動終端設備與PC，使用2.45GHz無線頻段來傳遞。它還配備多款村田自家的通用電子元件，包括晶片陶瓷電容、Ceralock陶瓷振盪器、測溫度用的NTC電熱感測器、電位計，以及雜訊抑制濾波器等。
村田製造並提供了“非常多”有關「村田小妹」的詳細資料，說她是「村田頑童」的小堂妹，生日是9月23日，出生於日本滋賀縣，目前唸幼稚園中班，而個性是「天生好動又怕羞」。
在本期文章我們將深入介紹由日本東京大學石川正俊教授所領導的研究團隊，針對目前廣泛應用在服務用以及產業用機器人之高速視覺技術的研究成果與由HarmonicDrive所發展的輕量型高速三指機械手，以及兩者結合之應用實例。
何謂高速視覺？
日本科學未來館當中展示了一組智慧型的機械手，該手臂搭配一雙眼睛就可以快速抓住任何丟向它的球或其他形狀之物體（如圖1）。普榮獲2007年機器人大獎賽冠軍的裝箱抓取機械手臂（如圖2），透過三支機械手臂可以快速的抓取於輸送帶中移動的任何商品，並精準地放置於包裝箱中。
此外，Fanuc以及Denson等傳統機械手臂生產大廠不約而同的在2007年日本機器人展當中推出可以附加於機械手臂上之高速視覺模組，使傳統機械手臂的應用因為加入的視覺技術而更有智慧，未來的機械手臂將可自行判斷物體形狀、大小以及外觀，然後自動的抓取物品，搬移到目標位置。
圖1 結合高速視覺模組之機械手（展示於日本科學未來館中）
圖2 抓取裝箱機械手臂
高速視覺技術（High Speed Vision Technology）就是這一隻手（手臂）的眼睛，透過每一秒鐘高達1000張圖片的抓取與高速的運算分析，就可以快速的掌握到移動或者靜止的分散物體，分析它的移動路徑、形狀以及大小，進而判斷其立體空間座標而驅動運動機構去作抓取與搬運動作。
高速視覺介紹
影像處理技術必須透過感光、影像傳輸、成像、合成等過程，並經由後端處理器進行影像壓縮與檔案後處理作業，除了資料的傳輸量大之外，還需要大量的處理器運算資源做影像處理。高速影像技術乃是利用FPGA（Field Programmable Gate Array）做為核心控制處理架構並結合高速傳輸介面，以及FPGA的高速運算能力，可重複規劃等數位訊號處理之優越性，配合動態影像的取得以及同步動態隨機存取記憶體（Synchronous Dynamic Ram，SDRAM）所發展而成。
日本東京大學石川正俊教授針對機器人的環境感測技術進行許多研究，其中最重要的研究成果便是發展「高速視覺晶片」（High Speed Vision Chip），將影像感測模組與數位處理元件整合於一片積體電路當中，同時利用第二級FPGA處理器架構（Secondary FPGA）強化了原本單一晶片的運算限制，並提供平行計算演算法，使得多的處理器得以同時運算大幅提昇運算技術能力，也因此得以每一秒鐘擷取超過1000張影像之能力。
|
圖3 高速視覺晶片 |
圖4 高速視覺晶片架構 |
傳統的影像處理速度一般都只有到30~100 frames/sec，處理速度雖不夠快，但用在一般3C產品上已經足夠；然而若要將視覺技術應用於機器人的感測上，若影像擷取速度不夠快的話，對於快速 移動的物體並無法及時偵測到，也無法瞭解到其移動路徑，會因而降低機器人對外在環境之反應力。石川教授的高速視覺晶片，因可以在每一秒鐘擷取高達1000 張影像（這樣的速度已經超越人類眼睛），因此透過影像與影像之間的分析與比對之後，便可即時掌握物體的移動、空間的辨識等。
機械手介紹
本次所參觀之東京大學石川實驗室當中，在結合高速視覺技術部分應用到了許多由HarmonicDrive所開發的三指擬人機械手（如圖5）。該機械手每一手指具有兩個自由度，可以作兩個關節的彎曲，並且在手指與手指之間還有一個自由度可以作兩個手指的開合動作。
圖5 HarmonicDrive三指機械手
HarmonicDrive在手指部分主要以兩種制動器做為關節驅動部分，包含RSF-38-100以及RSF-5A-50等，兩者分別使用1/100以及1/50的減速比提升其輸出扭力，末端最大出力為0.3Nm（牛頓米）。
圖6 Harmonic Drive手指模組機構示意圖
HarmonicDrive三指機械手機構不論在轉速或扭力的表現上，已經超越目前業界水準，且整隻手的應用涵蓋範圍也很廣，包括物品夾持、簡易工具操作等，在正式的實驗當中，使用HarmonicDrive機構手已經可以做出以下動作：
目前大部分的擬人機器人多採用人工肌肉來完成手部動作，其壽命有一定限制，且在速度以及扭力表現上均還無法達到與人相同之地步；因此，如HarmonicDrive所開發三指擬人機械手已經可以將傳統機械手的速度跟扭力拉升至與人相同，但在關節自由度的表現上，許多地方仍以同動方式為主，此外在指節末端關節處也無實現。因此，嚴格來說HarmonicDrive之三指機械手，仍無法與人類的手掌相比，因其對於更靈活之動作要求，目前是無法達到的。
目前日本已有多所大學投入研發機械手計畫，包含本次在日本展覽當中看到由東京大學以線驅動方式開發之五指機械手；以及由產總研（AIST）所研發應用於HRP-3P之四指17個自由度之機械手，已經可以將機械手縮小到180mm，並達到15Nm之出力。
|
圖7 線驅動機械手 |
圖8 AIST全馬達驅動機械手 |
除了日本外，各國在機械手的研發工作上一直都有成果，以下列出具代表性之研發成果：
| | DLR（德國宇航中心） II研發出四指擬人靈巧抓取的作業系統，每手指結構相同，各有4個關節和3自由度，另外在手掌內有一自由度，讓機器手能穩定的抓取和操作調整。DLR II機器手具有開關抽屜、操作設備以及使用工具等動作。 |
| | 英國Shadow研發出24自由度五指的機器手，採用人工肌肉方式驅動，重量大約3.Kg，Shadow機器手在指尖上裝有觸碰感測，允許在柔軟或脆弱的物體上使用。 |
| | 日本Squse公司設計的機器手用21條人工肌肉牽動關節，能像人手一樣抓取物品及與人握手，它甚至能勝任包裝生雞蛋這樣的細緻工作。 |
高速視覺應用實例
石川教授除了發展高速視覺技術之外，並利用此技術發展了相關應用技術，包含高速物體追蹤系統（High Speed Catching System）、目標物統計（Target Counting）、即時多目標物判斷（High Speed Based Moment Analysis of Numerous Object）、轉速測量（Rotation Measurement）、微細世界之視覺回饋系統（Microscopic Visual Feedback）等。
| | 高速追蹤系統可以透過高速視覺技術來追蹤移動中之物體，並利用機械手將物體抓取到位。此外，利用機械手臂做棒球打擊等應用也屬於相同原理。 |
| | 利用特徵分析與移動追蹤技術，可以在一個影像上分辨出多個目標物，並且同時偵測這些目標物之狀態改變。 |
| | 利用高速視覺技術可以對移動中之物體做數量統計。譬如一盤流沙，以瀑布方式傾瀉而下經由高速視覺之判斷可以精準無誤地統計出該流沙有多少沙粒。 |
| | 利用高速視覺技術針對一轉動之球面物品進行特徵分析，並藉由此特徵進一步分析出其轉速。 |
| | 結合顯微鏡技術以及高速視覺技術，可以觀察到微細世界之狀態。 |
石川教授所研發之高速影像處?系統的IC晶片，未?希望朝?快速及?有智慧性的方向研發，在應用上未來可朝向高速檢測儀器、生技醫?手術輔助、道?影像攝影、賽?終點判定、視覺介面、追蹤辨識系統等。
此外，在產業應用上也已經有多款服務型與產業用機器人結合視覺技術，在2007日本機器人展當中已經有許多產業應用實例出現，包含有：
| | 日本機械手臂大廠Fanuc於2007年正式推出結合視覺辨識模組之機械手臂，透過視覺技術，機械手臂可以在特定區域抓取散落之物品，而無須預先排定物品位置。並且可以透過視覺技術偵測物體形狀與大小以決定抓取方式，提供機械手臂更有彈性之應用。 |
| | Denson機械手臂結合三組CCD，可以呈現出多個目標物體之3D立體圖像，並回饋給機械手臂進行搬移。 |
| | 日本生產技術株式會社利用視覺技術賦予機器人玩魔術方塊之技巧，該機器人可以透過視覺技術判斷目前方塊狀況，並進行推演然後透過兩隻機械手完成魔術方塊遊戲。 |
| | 乒乓球機器人可以跟人一起打乒乓球。該款機器人利用視覺技術來追蹤乒乓球之移動路徑，然後在落點後將球回擊。 |
高速視覺之未來發展
在本次的參訪當中，石川教授的高速視覺技術已經證明可以提供機器人或應用載具基本的環境感測功能，達到物體識別、移動追蹤、立體視覺等，且高速視覺技術在成本與速度上已經超越傳統的雷射掃描器，因此在近幾年吸引許多廠商投入研發。
然而，視覺在感測的同時容易受到燈光之影響，而影響到判斷的精確度，進而造成誤判等嚴重疏失，而會有安全上之疑慮，未來必須倚賴更精密與更高速之變焦技術來解決此問題。
再 者，是否未來機器人僅需使用視覺技術即可取代目前所使用的所有感測技術，仍有許多爭議。一方面視覺技術在感測精度上會隨著距離而遞減，再者對於許多障礙物 的偵測，單靠視覺技術仍無法做出最正確的判斷，因此短時間內雖可見到視覺技術應用於機器人上，但仍須要結合其他感測技術如超音波、雷射等。
此外，透過視覺技術來模擬生物的眼睛，亦為視覺技術發展的主軸，但在實際的產品上，仍無法達到非常理想的跨距，以Point Gray目前所推出的3D視覺模組系統（Stereo Vision），跨距至少要12cm才能夠做出3D立體成像，對於小型化的機器人商品因無法使用過寬的跨距，有關於跨距問題在未來仍必須在技術上突破。
圖9 Point Gray立體視覺模組
結語
本期我們為各位介紹關於東京大學石川正俊教授所主持之高速視覺技術，並利用高速視覺技術所發展之相關應用。在近兩年當中，已經有愈來愈多的廠商結合視覺技術來強化本身原有產品之應用，尤以產業用機器人為大宗。隨著IC處理器製程技術更加進步之際，也將會推動視覺技術更往前邁進，並可將視覺技術結合其他感測技術後提供機器人產品更加敏銳之環境感測能力。
在下一期文章當中，將介紹日本產業技術總合研究所（AIST）的共通性雙足機器人開發平台HRP-3P與相關機器人之研發成果。
http://www.robotworld.org.tw/index.htm?pid=10&News_ID=1557
In the near future, embedded systems designers will be able to use hardware and software interchangeably depending on which best solves a specific design problem. Up until now, the barriers were so high for software engineers who wanted to learn hardware design that few explored the space. The barrier is crumbling because of the similarity between hardware description languages and programming languages. Also, several reasonably low-cost demonstration boards are available that include a field-programmable gate array (FPGA), a microprocessor, and tools that even a software developer can use to learn hardware design.
This article offers an example of this new design process using an FPGA. We'll look at how to implement pulse width modulation (PWM) in software and then turn the design into a logic block that can run from an FPGA and be controlled via software using a memory-mapped I/O interface. You can do everything in this article with the FPGA development kits that are available today from major FPGA manufacturers.
Hardware-software divide Several things have changed that make it easier for software engineers to participate in hardware design. Both hardware and software modules are now designed using programming languages. As you know, C is the lingua franca of embedded software design. On the hardware side, Verilog is often the popular choice (though both VHDL and Verilog are popular). The syntax and structure of Verilog is similar to that of the C programming language, as the examples in this article will illustrate.
At the same time, hardware is getting easier to update and change. It used to be that software could be changed simply by downloading a new executable image while hardware could not. That's no longer entirely true. Just as a software developer can make a quick edit, recompile, and then download the new code into memory, hardware designers using programmable logic have a similar capability. Programmable logic changes the method for designing embedded systems by enabling you to change the hardware as easily as the software. In other words, it affords you the flexibility during design and debugging to choose the best way to handle these tasks—either in software or hardware.
Tools are available from FPGA vendors that enable a designer with a little knowledge of hardware to develop an embedded system for programmable logic, such as an FPGA. For example, the SOPC Builder from Altera (my employer) enables system designers to select and configure peripherals from an existing library as well as add user logic to create and tie peripherals together. With programmable logic and some hardware knowledge, software engineers can take advantage of the benefits of hardware to improve their systems.
PWM software A PWM controller produces a stream of pulses like those shown in Figure 1. Usually the period and pulse width are specified. The duty cycle, or on time, is defined as the ratio of the pulse width to the period. Figure 1 shows a PWM waveform of about 33% duty cycle.
PWM is used in many applications, most frequently to control analog circuitry. Because the digital signal varies continuously at a relatively fast rate (depending on the period, of course), the resulting signal will have an average voltage value, which can be used to control an analog device. For example, if a stream of PWM pulses is sent to a motor, it will turn at a rate proportional to the duty cycle (from 0% to 100%). If the duty cycle is increased, the motor will turn faster; likewise, if the duty cycle is decreased the motor will slow.
For more information about PWM, consult Michael Barr's Beginner's Corner article "Introduction to Pulse Width Modulation" (September 2001, p. 103).
Generally speaking, PWM is implemented in hardware because the output signal must be continuously updated—going high from the start of each period for the proper time, then low for the remainder of the period. Software usually just handles the selection of the period and duty cycle and perhaps occasionally making changes to the duty cycle, to effect a behavioral change in whatever is attached to the PWM output.
There's no reason, however, that software couldn't be used to implement PWM, say by bit-banging a spare output pin. Writing such a PWM controller in software is a relatively trivial task and helps illustrate what we will do in Verilog shortly. Listing 1 shows the C code for PWM.
Listing 1: A bit-banging PWM controller implemented entirely in software
void pwmTask(uint32_t pulse_width, uint32_t period) { uint32_t time_on = pulse_width; uint32_t time_off = period - pulse_width;while (1) { pwm_output = 1; sleep(time_on); pwm_output = 0; sleep(time_off); } }
Based on the pulse_width and period arguments to this function, the PWM calculates the amount of time the output will be high and low. The infinite loop then sets the output pin high, waits for time_on time units to elapse, sets the output low, waits for time_off, and then repeats the cycle for the next period.
Verilog Listing 2 shows a simple Verilog module implementing an 8-bit wide register with an asynchronous reset. The input of the register, in, is assigned to the output, out, upon the rising edge of the clock, unless the falling edge of the clr_n reset signal occurs (in which case the output is assigned a value of 0).
Listing 2: Verilog module for a register with asynchronous reset
module simple_register(in, out, clr_n, clk, a);
| // port declarations | ||
| input input input [7:0] input output [7:0] | clr_n; clk; in; a; out; | |
| // signal declarations | ||
| reg [7:0] wire | out; a; | |
| // implement a register with asynchronous clear always @(posedge clk or negedge clr_n) begin | |||
| if (clr_n == 0) // could also be written if (!clr_n) | |||
| out <= 0; | |||
| else | |||
| out <= in; | |||
| end
// continuous assignment assign a = !out[0]; | |||
Glancing at the Verilog listing, you should notice several similarities to the C programming language. A semicolon is used to end each statement and the comment delimiters are the same (both /* */ and // are recognized). An == operator is also used to test equality. Verilog's if..then..else is similar to that of C, except that the keywords begin and end are used instead of curly braces. In fact, the begin and end keywords are optional for single-statement blocks, just like C's curly braces. Both Verilog and C are case sensitive as well.
Of course, one key difference between hardware and software is how they "run." A hardware design consists of many elements all running in parallel. Once the device is powered on, every element of the hardware is always executing. Depending on the control logic and the data input, of course, some elements of the device may not change their outputs. However, they're always "running."
In contrast, only one small portion of an entire software design (even one with multiple software tasks defined) is being executed at any one time. If there's just one processor, only one instruction is actually being executed at a time. The rest of the software can be considered dormant, unlike the rest of the hardware. Variables may exist with a valid value, but most of the time they're not involved in any processing.
This difference in behavior translates to differences in the way we program hardware and software code. Software is executed serially, so that each line of code is executed only after the line before it is complete (except for nonlinearities on interrupts or at the behest of an operating system).
A Verilog module starts with the module keyword followed by the name of the module and the port list, which is a list of the names of all the inputs and outputs of the module. The next section contains the port declarations. Note that all of the input and outputs appear in both the port list in the first line of the module and in the port declarations section.
In Verilog, two types of internal signals are widely used: reg and wire. These types differ in function. All parts have a signal by the same name implicitly declared as a wire. Therefore, the line declaring a as a wire is not necessary. A reg will hold the last assigned value so it doesn't need to be driven at all times. Signals of type wire are used for asynchronous logic and sometimes to connect signals. Because a reg holds the last value driven, inputs cannot be declared as a reg. An input can change at any time asynchronous to any event in the Verilog module. The main difference, however, is that signals of type reg can only be assigned a value in procedural blocks (discussed later) while signals of type wire can only be assigned a value outside of procedural blocks. Both signal types can appear on the right-hand side of the assignment operator inside or outside of any procedural block.
It's important to understand that using the reg keyword doesn't necessarily mean the compiler will create a register. The code in Listing 2 has one internal signal of type reg that's 8 bits wide and called out. This module infers a register because of the way the always block (a type of procedural block) is written. Notice that the signal a is a wire and thus is assigned a value only in the continuous assignment statement while out, a reg, is assigned a value only in the always block.
An always block is a type of procedural block used to update signals only when something changes. The group of expressions inside the parentheses of the always statement is called the sensitivity list; it's of the form:
(expression or expression ...)
The code inside the always block is executed whenever any expression in its sensitivity list is true. The Verilog keywords for rising edge and falling edge are posedge and negedge, respectively. These are often used in sensitivity lists. In the example shown, if the rising edge of the clk signal or the falling edge of the clr_n signal occurs, the statements inside the always block will be executed.
To infer a register, the output should be updated on the rising edge of the clock (falling edge would work too, but the rising edge is more common). Adding negedge clr_n makes the register reset upon the falling edge of the clr_n signal. Not all sensitivity lists will contain the keywords posedge or negedge, though, so there won't always be an actual register in the resulting hardware.
Inside the always block, the first statement asks if the falling edge of the clr_n signal occurred. If it did, then the next line of code sets out to 0. These lines of code implement the asynchronous reset portion of the register. If the conditional statement were:
if (negedge clr_n and clk == 1)
then it would be a synchronous reset that depends on the clock.
You may have noticed that the assignment operators inside the always block are different from the one used in the continuous assignment statement that begins with the assign keyword. The <= operator is used for nonblocking assignments while the = operator is used for blocking assignments.
In a group of blocking assignments, the first assignment is evaluated and assigned before the next blocking assignment is executed. This process is just like C's serial execution of statements. With nonblocking assignments, though, the right hand side of all assignments are evaluated and assigned simultaneously. Continuous assignment statements must use the blocking assignment (the compiler will give an error otherwise).
To make the code less prone to errors, it's recommended that you use nonblocking assignments for all assignments in an always block with sequential logic (for example, logic that you want implemented as registers). Most always blocks should use nonblocking assignment statements. If the always block has all combinatorial logic, then you'll want to use blocking assignments.
PWM hardware One of the first tasks when writing a memory-mapped hardware module is to decide what the register map will look like from the software perspective. In the case of PWM, you want to be able to set the period and pulse width in software. In hardware, making a counter that counts system clock cycles is easy. Therefore, there will be two registers, the pulse_width and the period, both measured in clock cycles. Table 1 shows the register map for the PWM.
Table 1: Register map for PWM
| Address | Name | Width | Description |
| 0 | period | 32 bits | Number of clock cycles for one period |
| 1 | pulse_width | 32 bits | Number of clock cycles the output will be high |
Next, choose the ports for the PWM, most of which are already determined based on the bus architecture. Table 2 has a brief description of the signals for a generic memory-mapped PWM. Note that a popular naming convention for active low signals is to add an "_n" to the signal name, which are fairly common for control signals. The signals write_n, and clr_n in Table 2 are active low (falling-edge triggered) signals.
Table 2: Ports for PWM
| Signal Name | Direction | Description |
| clk | Input | System clock |
| write_data[31:0] | Input | Write data (for registers in register map) |
| cs | Input | Chip select |
| write_n | Input | Write enable, active low |
| addr | Input | Address (to access registers in register map) |
| clr_n | Input | Clear, active low |
| read_data[31:0] | Output | Read data output |
| pwm_out | Output | PWM output |
Now that we have defined the interface of the hardware module, we can start writing the Verilog code. An example implementation is shown in Listing 3.
Listing 3: PWM hardware implementation in Verilog
| module pwm (clk, write_data, cs, write_n, addr, clr_n, read_data, pwm_out); | ||||||
| // port declarations | ||||||
| input input [31:0] input input input input output [31:0] output | clk; write_data; cs; write_n; addr; clr_n; read_data; pwm_out; | |||||
| // signal declarations | ||||||
| reg [31:0] reg [31:0] reg [31:0] reg reg [31:0] wire | period; pulse_width; counter; off; read_data; period_en, pulse_width_en; // write enables | |||||
| // Define contents of period and pulse_width registers // including write access for these registers always @(posedge clk or negedge clr_n) begin | ||||||
| if (clr_n == 0) | ||||||
| begin | ||||||
| period <= 32'h 00000000; pulse_width <= 32'h 00000000; | ||||||
| end | ||||||
| else | ||||||
| begin | ||||||
| if (period_en) | ||||||
| period <= write_data[31:0]; | ||||||
| else | ||||||
| period <= period; | ||||||
| if (pulse_width_en) | ||||||
| pulse_width <= write_data[31:0]; | ||||||
| else | ||||||
| pulse_width <= pulse_width; | ||||||
| end | ||||||
| end | ||||||
| // read access for period and pulse_width registers always @(addr or period or pulse_width) | ||||||
| if (addr == 0) | ||||||
| read_data = period; | ||||||
| else | ||||||
| read_data = pulse_width; | ||||||
| // counter which continually counts up to period always @(posedge clk or negedge clr_n) begin | ||||||
| if (clr_n == 0) | ||||||
| counter <= 0; | ||||||
| else if (counter >= period - 1) // count from 0 to (period-1) | ||||||
| counter <= 0; | ||||||
| else | ||||||
| counter <= counter + 1; | ||||||
| end // Turns output on while counter is less than pulse_width; otherwise // turns output off. // !off is connected to PWM output always @(posedge clk or negedge clr_n) begin | ||||||
| if (clr_n == 0) | ||||||
| off <= 0; | ||||||
| else | ||||||
| if (counter >= pulse_width) | ||||||
| off <= 1; | ||||||
| else | ||||||
| if (counter == 0) | ||||||
| off <= 0; | ||||||
| else | ||||||
| off <= off; | ||||||
| end | ||||||
| // write enable signals for writing to period and pulse_width registers
assign period_en = cs & !write_n & !addr;
assign pulse_width_en = cs & !write_n & addr;
// PWM output assign pwm_out = !off; | ||||||
| endmodule | ||||||
The first signals are the port declarations, which were described in Table 2. After the port declarations come the internal signal declarations. The memory-mapped registers that make up the software interface to control the PWM are declared reg. The code allows for only 32-bit accesses to these memory-mapped registers. If you need 8-bit or 16-bit access, then you would split the registers into four 8-bit registers and add logic for byte enable signals. The Verilog code to implement this is straightforward. All the signals with assigned values in the always blocks are also declared reg. The signals declared wire are the write enables for the registers period and pulse_width. These signals are assigned values using continuous assignment statements.
The rest of the listing contains the actual code. There are four always blocks and several assignment statements at the end. Each always block describes the behavior for one signal or a group of signals that have the same basic behavior (in other words, use the same control logic). This is a clean way of writing Verilog code that keeps the code readable and less prone to errors. All of the always blocks have reset logic that sets the signal(s) to 0 when the clr_n signal is asserted (set to 0). While not strictly necessary, this is a good design practice so that every signal has a known value upon reset.
The first always block describes the behavior of the registers in the register map. The value of the write_data register is written into the period or pulse_width register if the appropriate enable signal is asserted. That is the only way to change the values of either register. The write enable signals are defined in the continuous assignment statements at the bottom of the file. The write enables for the period and pulse_width registers are asserted when the main write enable signal and the chip select signal are asserted; the addr bit should be set to 0 for period and 1 for pulse_width.
The second always block defines reading the registers in the register map. The period register will be at the base address of the peripheral, and the pulse_width register will be at the next 32-bit word.
The third and fourth always blocks work together to determine the output of the PWM. The third always block implements a counter that continually counts up to the value in the period register, resets to 0, and begins counting again. The fourth always block compares this counter value to the pulse_width register. While the counter value is less than the pulse_width, the PWM output is kept high; otherwise it's set low.
One thing to keep in mind is that every signal must have a defined value under all conditions. This goes back to one of the fundamental behaviors of hardware—it's always running. For example, in the last always block (the one that describes the off signal) the last line of code assigns off to itself. This may seem strange at first, but without this line, the value of off would be undefined for that case. An easy way to keep track of this is to make sure that every time a signal is assigned a value in an if statement, it is assigned a value in the corresponding else statement as well.
Software access Now that the hardware is complete, the PWM can be controlled via software using the registers in the register map. You can use a simple data structure along with a pointer to connect to the registers in the PWM.
typedef volatile struct { uint32_t period; uint32_t pulse_width;} PWM;
For example, the PWM could be hooked to an LED. A variable called pLED of type PWM * could be initialized to point to the PWM base address. This abstracts the hardware into a data structure. Writing to pLED->period will set or change the period. Writing to pLED->pulse_width will change the duty cycle and cause the brightness of the LED to increase or decrease. If a blinking LED is desired, the period need only be lengthened, so that the human eye perceives the on and off periods as distinct.
The Verilog PWM implementation shown in Listing 3 was tested as a peripheral for Altera's Nios processor system and accessed via software using a C struct like the one I previously described. Altera's SOPC Builder creates macros that facilitate performing co-simulation in ModelSim, a hardware simulator from Mentor Graphics. Using the ModelSim simulator, the behavior of the PWM signals, along with the rest of the system's signals, can be observed while the system is executing C code.
Listing 4 shows the C code that was used to generate the waveform in Figure 2. The waveform shows the behavior of the pertinent PWM signals. The C code writes to the PWM registers to create a PWM output with a period of five cycles and a pulse width of four. Notice that at the beginning of the waveform, the cs and wr_n signals are asserted twice since we're writing to both the period and pulse_width registers. (The address signal is low when writing to the period register and high when writing to the pulse_width register.)
Listing 4 Test software used to produce waveforms in Figure 2
void main(void) { PWM * const pLED = ...pLED->period = 5; pLED->pulse_width = 4;
asm("nop"); asm("nop"); asm("nop");
pLED->pulse_width = 2; }
After the new values have been written to the registers, the pwm_output signal begins to reflect the change. Then, just to add some delay so we can see the output, some NOP instructions are executed by the C code. Finally, the pulse width is changed to two cycles, and the PWM waveform changes accordingly while still having a period of five cycles.
Best of both worlds Part of architecting an embedded system is partitioning the system into hardware and software modules to take advantage of the benefits of each. As development tools evolve, interchanging software and hardware modules is becoming more transparent to the designer.
Once you understand the concepts discussed in this article, you'll have the knowledge to develop hardware on an FPGA that can be hooked up as a memory-mapped peripheral in a microprocessor system and interfaced by simply writing software. Because certain algorithms run much faster in hardware, converting an algorithm from software to hardware may greatly increase system performance. Known as hardware acceleration, the ability to do this is key to using configurable processors implemented effectively in programmable logic. At long last, even a software engineer has the power to improve system performance and efficiency through hardware acceleration.
Lara Simsic is an applications engineer at Altera. She has developed embedded hardware and software for five years and has an EE degree from the University of Dayton. Contact her at lsimsic@altera.com.
最近日本街頭流行一款新型娃娃機，玻璃窗內不是懸吊手臂，而是一隻小小機器人。只要投入硬幣，它就會為您將娃娃扔到洞口。不過機器人偶爾也會跌倒，可別以為這樣就結束了，機器人會自動爬起來，繼續為您服務。
夾娃娃一定得用夾的嗎？那可不一定，日本街頭就出現一種抱娃娃機，只要投入硬幣，玻璃窗內的小機器人就會站起來為您服務。按前進鈕，機器人就會小碎步往目標物移動，再按抓取鍵，機器人就會把娃娃抱起來，只是操縱還是得靠技巧，兩手空空抓不到是常有的事。
小機器人不小心也會跌倒，這時候就GAMEOVER了嗎？可沒這麼快，只要在限定時間內，機器人就會撐著地面爬起來，繼續為您服務。
這款名為ROBOCATCHER的娃娃機，不只受到男生青睞，就連年輕女性也為之瘋狂，即使造價是一般夾娃娃機的3倍，仍然供不應求，天馬行空的創意概念，也為業者開發無限商機。
機器人在前進：機器人平台與開發工具 |
| ( 3 月 1 日 2008 年) |
| Robert Cravotta，技術編輯 |
機 器人終於讓人有了想像的空間。隨著低成本開發平台變得越來越容易取得，人們將機器人用於教育與最終應用的機會也在不斷增加。不過，“機器人”此一用語是一 個要限定範圍的猛獸，因為人們通常會把這些裝置擬人化，把它們看作佣人或寵物。大多數人能在看到機器人時，就把它認出來，但你也會發現，很難找到一種能夠 適用於所有或大多數機器人的說明。例如，iRobot 把自己的Roomba 稱為吸塵機器人（vacuuming robot），但很多人毫無疑問地會稱它是一種機器人（robot）。另一方面，多數人很難把自動式的汽車（autonomous automobile）稱為機器人，例如像是在美國國防部高等研究計畫局（he Defense Advanced Research Projects Agency，DARPA）的Urban Challenge中所跑的那些車子。這些功能近似的系統之間究竟有什麼差異？更重要的是，身為一名設計者，在建立這些類型系統時，他所使用的設計方案與 開發資源有何差異？一個嵌入式自動或半自動子系統的設計（如高檔汽車中的刹車與牽引控制系統），與多數人所認為的機器人設計之間有何差異？ |
