Giải mã cầu phương


7

Tôi có 6 bộ mã hóa độ phân giải cao (10k dòng) mà tôi muốn giao diện với bộ điều khiển vi mô. Tôi đã viết mã để thực hiện giải mã bậc hai cho tất cả các bộ mã hóa nhưng không có cách nào mà một Arduino nghèo có thể xử lý nhiều bộ mã hóa đó ở bất kỳ tốc độ hợp lý nào, chứ đừng nói gì đến việc theo dõi các bộ mã hóa.

Tôi nên làm gì trong tình huống như vậy?

Thật không may, tôi không có nhiều nền tảng về điện tử, chỉ về lập trình (chỉ một chút thôi).


2
Nó nhanh như thế nào, tức là bạn nhận được bao nhiêu đếm mỗi giây?
starblue

Câu trả lời:


14

Thú cưng của tôi là khi giải mã cầu phương được thực hiện trong phần mềm. Khi được thực hiện trong phần mềm, bộ giải mã thường không thể theo kịp, đặc biệt là khi tốc độ xung nhanh hoặc MCU đang làm nhiều việc khác. Tôi đã thấy nhiều thiết bị sử dụng bộ mã hóa cầu phương trên núm nhập dữ liệu và hầu hết thời gian nó hoạt động tốt. Nhưng bộ giải mã sẽ bỏ qua các xung bất cứ khi nào MCU phải làm gì đó, như làm mới màn hình hoặc nói chuyện qua RS-232.

Tôi thực hiện giải mã cầu phương trong một đồ họa. Một cổng Xilinx Spartan-3A 50K có giá dưới 10 đô la và có thể giải mã nhiều kênh hơn so với chân. Và nó sẽ làm điều đó với tốc độ xung cầu phương trên 1 MHz. Không có MCU cho chi phí tương tự hoặc rẻ hơn có thể làm điều đó.

Chỉnh sửa: Những gì sau đây là một bản tóm tắt của rất nhiều ý kiến, và một số chi tiết thêm về phần của tôi. Thưởng thức!

Đúng là bạn có thể thực hiện một cách tiếp cận phần mềm nếu tốc độ xung đủ chậm. Nhưng khi điều này được thực hiện, bạn phải chắc chắn rằng "các trường hợp góc" được bảo hiểm. Những thứ như ngắt cho các thiết bị ngoại vi khác (như UART, ADC, v.v.) có thể ảnh hưởng đến tần suất bạn lấy mẫu dữ liệu cầu phương khiến quá trình giải mã cầu phương đôi khi bị mất xung. Các xung bị bỏ lỡ này là "ok" đối với một số ứng dụng, như núm nhập dữ liệu, nhưng vẫn gây khó chịu cho tôi.

@Leon Heller thực sự thích bộ xử lý XMOS cho những thứ tương tự. Đối với những người không biết, công cụ XMOS về cơ bản là một MCU đơn giản nhưng siêu nhanh. Khi hầu hết các MCU chạy trong phạm vi <25 MIPS, công cụ XMOS đang đẩy 500 MIPS. XMOS không thực hiện nhiều thiết bị ngoại vi dựa trên phần cứng, như UARTs. Thay vào đó họ "bit-bang" nó và làm UART trong phần mềm. Họ cũng bit-bang những thứ như USB và 10mbps Ethernet. Ok, tôi siêu đơn giản hóa điều này, nhưng bạn có được điểm. Đây là ý kiến ​​của tôi: có những người làm đồ họa và có những người làm CPU. Nếu bạn là một loại CPU và không thích đồ họa thì bộ xử lý XMOS có thể phù hợp với bạn.

Chủ đề về các mã Gray trong một triển khai FPGA đã được đưa lên và thực hiện các bộ đếm vị trí lên / xuống trong mã màu xám. Thông thường có hai lý do để sử dụng mã Gray: nếu bạn có một số logic không đồng bộ đang diễn ra (2 đồng hồ trở lên) hoặc nếu bạn muốn các bộ đếm chiếm ít logic hơn. Thông thường, bạn sẽ không có logic không đồng bộ trong FPGA (ngoài việc lấy mẫu dữ liệu cầu phương ở các chân đầu vào) và FPGA đã có các chuỗi mang siêu nhanh (còn gọi là bộ cộng nhị phân). Vì vậy, thực sự, trong các trường hợp bình thường, không cần bất kỳ bộ đếm mã màu xám nào cho việc này.

Bạn có thể sử dụng CPLD cho việc này, thay vì một FPGA. Điều này sẽ làm việc cho 1 hoặc 2 bộ giải mã bậc hai, nhưng khi bạn thêm nhiều bộ giải mã, việc giao tiếp với MCU trở nên phức tạp hơn. Các GPU rất tốt cho việc này vì giao diện MCU có thể là SPI hoặc điều đơn giản khác không chiếm hàng chục chân trên MCU.

Cách "chính xác" để thực hiện điều này trong một đồ họa là trong đó đồ họa có bộ đếm 8-16 bit đơn giản theo dõi vị trí. Bộ đếm này không bao giờ được thiết lập lại sau khi khởi tạo, và đôi khi thậm chí không. Phần mềm (SW) sẽ thăm dò vị trí này thường xuyên và sẽ giữ một bản ghi về "vị trí trước đó". Lấy vị trí hiện tại và trừ đi vị trí trước đó sẽ cho phần mềm biết vị trí đã thay đổi bao xa.

Lý do bộ đếm vị trí không bao giờ được đặt lại là vì chúng tôi đang cố gắng tránh "đọc phá hủy". Đó là khi CPU đọc một thanh ghi gây ra điều gì đó không thể đảo ngược - như xóa bộ đếm vị trí. Đôi khi việc đọc phá hoại là không thể tránh khỏi, như khi đọc một phần mười, nhưng nói chung bạn muốn tránh chúng. Suy nghĩ đằng sau này là ngoài bài viết này. Tôi đã cố gắng tìm một trang web tốt để thảo luận về họ, nhưng tôi đã thất bại. Lấy làm tiếc.

Khi nói về tốc độ đếm, bên dưới, ý tôi là bộ đếm vị trí có thể tăng hoặc giảm nhanh như thế nào. Do tính chất cầu phương của vật thể, "tốc độ xung" là một phần tư tốc độ đếm. Tôi giả sử rằng với mỗi xung đầy đủ, chúng ta có thể đếm lên / xuống 4 lần. Tôi biết có nhiều cách khác để đếm (một đếm trên mỗi xung đầy đủ), nhưng tôi bỏ qua nó ngoài hiệu trưởng.

Bỏ qua bộ xử lý XMOS (giống như một bộ xử lý đồ họa, trong bối cảnh của một vài đoạn tiếp theo), MCU sẽ bị giới hạn ở tốc độ đếm tối đa dưới 500 Hz và trong nhiều trường hợp tối đa dưới 100 Hz. Tất nhiên có thể có một số ngoại lệ cao hơn 1 KHz, nhưng đối với hầu hết mọi người, điều đó khó thực hiện. Đối với MCU điển hình của bạn, bạn đang làm rất tốt để có được tần số trên 100 Hz, giả sử rằng MCU không dành riêng cho giải mã cầu phương.

Một núm nhập dữ liệu thông thường có 12 đến 20 xung trên mỗi vòng quay, hoặc 48 đến 80 đếm trên mỗi vòng quay. Giả sử núm có đường kính 1 inch, một người điển hình nhưng quá nhiệt tình có thể nhận được khoảng 4 vòng mỗi giây khi cố gắng cuộn qua nhiều dữ liệu. Điều đó đạt đến tốc độ đếm từ 192 đến 320 Hz. Vẫn trong khả năng của một MCU, nhưng chỉ vừa đủ và chỉ với lập trình cẩn thận.

Một đồ họa, tùy thuộc vào cách viết logic, có thể xử lý tốc độ đếm hơn 100 MHz. Tôi đã viết logic của mình để xử lý tốc độ đếm lên tới khoảng 50 KHz, nhưng nó có thể thực hiện nhiều bộ giải mã bậc hai trong một lượng logic rất nhỏ. Trong một Xilinx Spartan-3, bạn cần khoảng 50 lát và 1 Block-RAM để thực hiện bộ giải mã 32 đến 512 (bạn sẽ hết chân trước khi hết logic).

Vì vậy, cái nào tốt hơn, FPGA, MCU hay XMOS? Như thường lệ, nó phụ thuộc. Nó không chỉ phụ thuộc vào những thứ thông thường như tốc độ đếm và số lượng bộ giải mã, mà còn phụ thuộc vào những gì người thiết kế thoải mái sử dụng và những gì khác trong hệ thống. Sở thích của tôi là FPGA, nhưng đó chỉ là loại người của tôi! :)


Tôi sẽ đề nghị một số tiêu đề và thay đổi định dạng để làm cho câu trả lời này hoàn hảo.
Kortuk

Tôi thích nhận xét của bạn về các lần đọc phá hủy, nhưng sẽ thêm vào đó: nếu bộ xử lý không thể thực hiện đọc nguyên tử giá trị bộ đếm toàn chiều rộng, thì IMHO sẽ an toàn hơn khi đọc "piecewise" đọc dữ liệu trực tiếp hơn là đọc một phần chốt những người khác Nếu đọc tìm nạp dữ liệu trực tiếp, thì bộ xử lý có thể đọc byte thấp / byte cao / byte thấp và cho rằng nếu hai giá trị byte thấp khớp nhau, dữ liệu sẽ tốt (nếu chúng không khớp, hãy thử chuỗi lần nữa). Cách tiếp cận này sẽ hoạt động ngay cả khi trong khi dòng chính thực hiện một chuỗi như vậy thì một ngắt xảy ra và trình xử lý của nó cũng thực hiện chuỗi đó.
supercat

Ngược lại, việc phần cứng chốt toàn bộ bộ đếm và sau đó cho phép đọc giá trị chốt theo từng phần cho phép mã được đơn giản hóa nếu nó có thể đảm bảo nó sẽ không bị gián đoạn bởi mã cũng cần đọc bộ đếm, nhưng nếu mã đơn giản hơn bị gián đoạn bởi mã đọc bộ đếm thời gian có thể bị lỗi. Ví dụ, mã dòng chính chốt giá trị bộ định thời 0x03FF và đọc một nửa số đó. Sau đó, một ngắt chốt 0x0400, đọc bộ đếm và trả về. Cuối cùng, dòng chính đọc nửa kia của bộ đếm, thu được 0x0300 hoặc 0x04FF, tùy thuộc vào một nửa được đọc trước.
supercat

BTW, tôi tự hỏi liệu có bất kỳ bộ đếm nào có thể đọc được vi điều khiển thực hiện mã màu xám "mức byte" hay không, ví dụ như có từng byte (hoặc đơn vị có thể đọc được) được báo cáo ở dạng bổ sung nếu bit thấp nhất của byte cao hơn tiếp theo được đặt? Thiết kế như vậy sẽ đảm bảo rằng việc đọc tất cả các byte của bộ định thời và thực hiện các thao tác xor cần thiết sẽ mang lại kết quả đọc hợp pháp trừ khi có nhiều số đếm xảy ra giữa việc đọc LSB và byte tiếp theo, ngay cả trong trường hợp bộ đếm đi qua lại giữa ví dụ các giá trị 0x02FF và 0x300 [sẽ được báo cáo là 0x02FF và 0x03FF].
supercat

3

Đề nghị của tôi sẽ là để Arduino thực thi mã ứng dụng người dùng và chỉ cần nói chuyện với 3 hoặc 6 bộ vi điều khiển có chi phí rất thấp khác để thực hiện giải mã cầu phương. Số lượng micros bên ngoài phụ thuộc vào khả năng giải mã bộ mã hóa độ phân giải cao như vậy ở tốc độ nhất định. Kính hiển vi bên ngoài sẽ hoạt động giống như ở chuột - chúng theo dõi đồng bằng đếm bộ mã hóa kể từ truy vấn vị trí cuối cùng. Giả sử rằng bạn không cố gắng thực hiện phản hồi vị trí thời gian thực cho điều khiển động cơ vòng kín và chỉ muốn biết mỗi động cơ ở đâu tại một thời điểm tùy ý, điều này có thể giúp ích cho bạn. Sử dụng SPI hoặc I2C để nói chuyện với tất cả các micrô bên ngoài và tất nhiên bạn sẽ cần phải xử lý cuộn qua bộ đếm trong trường hợp bộ điều khiển chính (Arduino) không yêu cầu cập nhật vị trí thường xuyên,


Hmm, micros micros rẻ hơn sẽ thách thức hoạt động (và là thứ tôi có thể rút ra được). Nói về các chip riêng biệt, có ý tưởng nào nếu chúng tạo ra các IC giải mã cầu phương chuyên dụng không? Tôi đoán cho ứng dụng của mình, tôi chỉ cần ảnh chụp nhanh của các vị trí mã hóa trái ngược với theo dõi thời gian thực. Điều quan trọng là tất cả các vị trí của bộ mã hóa được bắt cùng một lúc.
Được thực hiện vào

2
họ hoàn toàn làm bộ giải mã cầu phương. Tôi đã không sử dụng một IC rời rạc cho việc này trong một thời gian, nhưng tôi nghĩ đó là HCTL-2000. Hãy chắc chắn rằng bạn chú ý đến băng thông của IC hoặc micro mà bạn có thể sử dụng để giải mã. 10k dòng / vòng quay có độ phân giải cực cao, do đó việc quay trục quá nhanh rất có thể dẫn đến số lượng bị mất. Nếu bạn không quan tâm đến câu hỏi của tôi, bạn đang sử dụng bộ mã hóa nào?
Dave

1
Ôi nhìn này! Họ tạo bộ đếm / giải mã 32 bit. Thật hoàn hảo! Mặc dù vậy, trước tiên tôi vẫn cần phải đi song song với IC nối tiếp (đầu ra trong 4 lần chuyển 8 bit, không đủ chân trên micro cho 6 trong số chúng). Hoạt động 33 Mhz là cách nhiều hơn tôi cần. Tôi đang sử dụng bộ mã hóa TRD-S2500-BD.
Được thực hiện vào

Liệu nó có giúp ích gì cho việc giải mã bằng logic và đưa ra các xung "lên" và "xuống" cho Arduino không?
endolith

1
@endolith nhưng tôi tự hỏi nếu điều đó vẫn sẽ đánh thuế arduino quá nhiều. Sau đó, bạn cần chắc chắn rằng Arduino có thể thu được các xung lên / xuống nhanh chóng này từ 6 bộ mã hóa độ phân giải cao trong khi nó đang xử lý ứng dụng người dùng.
Dave

2

Sử dụng chip XMOS XS1-L1 $ 7,50, với sáu luồng thực hiện giải mã - một luồng cho mỗi bộ mã hóa:

http://www.xmos.com/

Điều đó để lại hai chủ đề để làm những thứ khác.

Bảng mạch XK-1A có sẵn từ Digi-Key chỉ có giá 99 và đi kèm với trình gỡ lỗi XTAG-2. Nó có mọi thứ bạn cần trên đó Phần mềm phát triển là miễn phí và tôi nghĩ tôi đã thấy phần mềm mã hóa trên diễn đàn người dùng. Bảng 1600 MIPS XC-1A là một tùy chọn khác, và cũng có giá 99.

Đây có lẽ là cách dễ nhất và rẻ nhất để làm điều đó.


2
Uhh, vì một số lý do tôi không nghĩ rằng điều này được tính là cấp độ sở thích mới bắt đầu nữa.
Được thực hiện vào

1
@Faken một bộ mã hóa dòng 10k không chính xác ở cấp độ sở thích! Có 6 trong số đó trên một micro và mong đợi micro sẽ đọc chúng khi quay ở bất kỳ vận tốc góc hợp lý nào, tôi nghĩ rất nhiều. Bạn đang lái trực tiếp tải của bạn và yêu cầu độ phân giải thực sự cao?
Dave

1
Vâng, tôi hiểu rằng bộ mã hóa 10k không phải là thứ cấp độ sở thích nhưng thành thật mà nói, sự khác biệt duy nhất giữa bộ mã hóa 10k và bộ mã hóa 200 dòng chỉ là một bộ đắt hơn, ngoài ra, chúng hoạt động khá giống nhau. Sự khác biệt giữa Arduino 16 mhz và XMOS 500 Mhz không hoàn toàn đơn giản.
Được thực hiện vào

Tôi cần phải lái xe trực tiếp vì các vấn đề phản ứng dữ dội của thiết bị. Tôi đang thiết kế một máy đo tọa độ dựa trên liên kết 6 DOF, mọi thứ đều được thực hiện ngoại trừ các thiết bị điện tử mà tôi đang vật lộn.
Được thực hiện vào

1
Tôi nghĩ rằng downvote là do bạn đề xuất một chip giải mã bậc hai mạnh hơn, phức tạp và đắt tiền hơn, sau đó là chip chạy phần còn lại của thiết bị.
davr
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.