Tại sao FTDI mà không phải là AVR với bộ điều khiển USB tích hợp?


8

Tôi đã thực hiện một chương trình đơn giản trong Visual C #, giao tiếp với AVR thông qua chip FT232RL.

PC <-> FTDI <-> MCU.

Tôi đang sử dụng FTD2XX_NET.dll để truy cập trực tiếp vào Thiết bị USB.

Tôi đang tự hỏi, sự khác biệt giữa một cặp FTDI-AVR và một AVR với Bộ điều khiển USB tích hợp là gì? Tôi nghĩ rằng phải có một số khác biệt về tốc độ giao tiếp. Còn gì khác không?


2
Với FTDI, lập trình viên cho AVR không phải thực hiện ngăn xếp USB mà chỉ cần hỗ trợ UART. Có nhiều sự khác biệt khác mà tôi không biết Tôi chắc chắn, đó là lý do tại sao tôi không trả lời mà chỉ là nhận xét
Funkyguy

1
Ngoài ra FTDI đi kèm với trình điều khiển đã ký cho hầu hết các nền tảng và VID & PID được mã hóa cứng hợp lệ để bạn không phải trả tiền cho 65536 địa chỉ khi bạn chỉ cần một địa chỉ.
venny

Cảm ơn ý kiến. Khác biệt về hiệu suất? Cách nào tốt hơn cho giao tiếp PC và MCU? Thành thật mà nói, FTDI dễ dàng hơn nhiều từ các bộ điều khiển usb buil-in.
MrBit

Trong phần mềm PC với cách FTDI, có các chức năng rất khó. Và tôi không biết liệu một nỗ lực với một AVR có đáng không
MrBit

1
FTDI là nối tiếp câm. MCU có thể tiền xử lý, kích hoạt các kênh bên, hỗ trợ UMS, v.v.
Ignacio Vazquez-Abrams

Câu trả lời:


11

Có khá nhiều lý do, nhưng chúng, ít nhất là đối với hầu hết mọi người, khá thích hợp.

Những lý do mà tôi thấy và đã trải nghiệm

  • Sự lựa chọn trong các USB hỗ trợ USB khá hạn chế, đặc biệt là họ TINY. Nếu vì một lý do nào đó, một AVR được yêu cầu không có sự kết hợp của USB và một số thiết bị ngoại vi khác, thì đây là một lựa chọn dễ dàng. Một ví dụ mà lò xo để tâm là các AVR hỗ trợ PLL.
  • Mặc dù thiết bị ngoại vi USB được triển khai trong phần cứng, bạn vẫn cần đặt ngăn xếp USB trong phần sụn. Điều này chiếm khá nhiều tài nguyên (ví dụ LUFA yêu cầu ít nhất 6kB flash và 1,5kB RAM để thực hiện CDC đầy đủ và đây là một trong những thư viện nhẹ nhất)
  • Ngắt USB và các sự kiện xe buýt USB chiếm tài nguyên có thể gây rối với phần mềm quan trọng về thời gian. Ví dụ: các phép đo ADC tốc độ cao có thể bị rối rất tệ khi tác vụ USB bị gián đoạn.
  • Không phải tất cả các cài đặt thư viện USB đều hoạt động tốt với tất cả các AVR hỗ trợ USB. Ví dụ: Bộ tải khởi động USB sử dụng LUFA không hoạt động với các thiết bị XMEGA.
  • FTDI sử dụng trình điều khiển đã ký tự động cài đặt bằng Windows Update, trong khi nhiều thư viện USB, ví dụ ASF và LUFA, thì không. Điều này làm cho việc triển khai cho người dùng cuối trở nên cồng kềnh hơn.
  • Một số triển khai có hiệu suất thấp hơn, ví dụ FT2232H có thể kết nối FIFO với USB với tốc độ 8MiB / s, điều này không thể thực hiện được với một AVR.
  • Nhiều dự án không có toàn quyền kiểm soát phần cứng và phần mềm, ví dụ: máy in 3D có các dự án phần cứng và phần mềm hoàn toàn riêng biệt. Để giữ mức độ tương tác càng cao càng tốt, các chức năng của USB và vi điều khiển được tách ra.

Tuy nhiên, với các thư viện USB đã sẵn sàng sử dụng, chi phí đáng kể cho các cầu nối USB FTDI (chúng thường có giá cao hơn cả các loại AVR rất cao cấp) và không bị phạt hiệu năng trong hầu hết các ứng dụng, hiện tại rất khó để chứng minh các chip FTDI có toàn quyền kiểm soát phần cứng và phần sụn.


2
Ngay cả khi một dự án nằm trên một vi điều khiển được tích hợp giao diện USB và kế hoạch là sử dụng nó, vẫn đáng để có một tiêu đề để truy cập vào các chân UART, vì bạn có thể nhận được đầu ra gỡ lỗi hữu ích từ đó trong khi cố gắng lấy USB mã để làm việc.
Chris Stratton

4
Nhận xét của @ ChrisStratton chỉ ra một vấn đề khác: Các thiết bị USB là một thứ tự cường độ khó gỡ lỗi hơn so với nối tiếp UART đơn giản. Vì vậy, nó tăng tốc độ phát triển và loại bỏ những ẩn số để lại phần cuối của USB cho chip FDTI đang hoạt động. Rõ ràng là nền kinh tế thay đổi theo số lượng, nhưng đối với sản xuất nhỏ với áp lực thời gian, giải pháp FDTI thường tốt hơn.
markrages

Ồ, tl;drđoạn văn của bạn chắc chắn là một kết thúc bất ngờ ... Bạn có ngăn xếp USB / sê-ri chỉ nói về phần sụn (mặc dù có điểm cực kỳ hợp lệ), và sau đó BAM ... "chỉ một kẻ ngốc mới sử dụng FTDI". Vui nhộn. Yêu nó!
alex xám

@alexgray: Wow, bạn thực sự đang nói chuyện cực đoan đấy. Tôi không nghĩ rằng tôi đã nói bất cứ điều gì; đây chỉ là những loại mục tiêu tiêu biểu mà mọi người có trong thiết kế sản phẩm. Tôi đã xử lý các dự án được tối ưu hóa xung quanh khá nhiều sự kết hợp của các điểm này. Đối với các dự án sở thích, có thể có cách tiếp cận Trump vs Sanders để giải quyết 'tôi hay tôi không đi cầu FTDI RS-232?', Nhưng trong kỹ thuật thực sự, bạn thực sự chỉ nên xem xét khách quan tất cả các ưu và nhược điểm kết luận tối ưu.
dùng36129

4

Có những lợi thế trong việc sử dụng một chip USB riêng biệt và cho phép AVR giao tiếp thông qua UART của nó.

Một ngăn xếp USB phải đáp ứng việc bỏ phiếu từ PC chủ. Điều này xảy ra ít nhất mỗi mili giây. Điều đó có nghĩa là thậm chí còn khó khăn hơn để đảm bảo phản ứng cứng trong thời gian thực đối với các sự kiện, vì MCU có thể bị gián đoạn để trả lời cuộc thăm dò USB của máy chủ.

Khi không có gì để liên lạc hoặc MCU muốn tập trung hoàn toàn vào nhiệm vụ thời gian thực, nó vẫn phải phản hồi một số sự kiện bỏ phiếu của máy chủ lưu trữ, nếu không máy chủ sẽ 'mất' thiết bị. Vì vậy, thật khó để bỏ qua. Một chip USB chuyên dụng, giống như một FTDI giảm tải các tác vụ đó từ AVR.

Một vấn đề nhỏ là ngăn xếp USB sẽ tiêu thụ một lượng bộ nhớ flash và RAM hợp lý, do đó chip cần nhiều tài nguyên hơn so với một AVR đơn giản.

Ngoài ra, hai phần có thể được tách thành hai bảng, vì vậy USB không phải là chi phí cố định, nhưng có thể được chia sẻ trên nhiều bảng.

Về mặt ngược lại, lợi ích chính của việc sử dụng một AVR có tích hợp ngoại vi USB và ngăn xếp USB là chỉ có một phần để mua và lắp ráp.

Gần đây tôi chưa kiểm tra, nhưng tôi tin rằng các chip FTDI mới hơn cung cấp tốc độ truyền dữ liệu USB cao hơn so với USB của AVR. Tuy nhiên, các UART AVR chậm đến mức một AVR có USB truyền nhanh hơn so với sự kết hợp của FTDI (hoặc bất kỳ giao diện USB nào) giao tiếp qua UART của AVR vì UART AVR chậm.

Chỉnh sửa: FTDI thực hiện các giao diện khác ngoài UART. Ví dụ SPI. Tôi không có kinh nghiệm sử dụng chúng. Một số AVR hỗ trợ chuyển 9 (có thể 12) megabit SPI. FTDI là chủ SPI, không lý tưởng. Nếu AVR đang truyền, nó có thể ổn. Như FTDI có bộ đệm, nhưng nhận được có thể "giống như uống từ vòi cứu hỏa". AFAIK, bạn sẽ phải làm việc trên PC chủ để làm cho nó hoạt động.

Tốc độ truyền cao nhất thể thông qua bảng con Ethernet 100mbits, nhưng tôi chưa thấy các phép đo thông lượng.

Tôi rất vui khi sử dụng các bộ vi điều khiển khác ngoài AVR. Vì vậy, tôi có thể sử dụng một cái gì đó với UART nhanh và bộ điều khiển DMA có thể di chuyển các ký tự mà không cần sự tham gia của CPU. Nếu đó là một cách tiếp cận hữu ích, có thể nhìn vào Arduin Because, hoặc mbed, mbed ST được gọi là nucelo có chi phí thấp.


như về tốc độ truyền tải UART của AVR, vâng, nó rất chậm ... vì vậy, (để khắc phục điều này) có cách nào khác để thực hiện giao tiếp giữa các chip AVR & FTDI không? Bây giờ tôi đang ở tốc độ 230,4kbps ở chế độ uart
MrBit

@ user3829694 - Tôi không chắc ý của bạn là gì. Ae bạn hỏi làm thế nào để đi nhanh hơn 230,4kbps? Hay bạn đang nói rằng 230,4kbps là ổn đối với bạn?
xe cứu thương

Tôi đang hỏi, nếu tôi muốn tốc độ cao hơn tôi có thể làm gì khác? Tôi nghĩ FT245 FIFO, nó có thể lên tới 1Mb / giây. Tôi đang cố gắng thực hiện các dự án HID với "giám sát thời gian thực" chỉ để thu thập dữ liệu từ avr (có cảm biến, v.v.) sang dạng PC. Nhưng với UART ngay cả ở tốc độ tối đa (230,4kb / giây), tốc độ truyền của toàn bộ bộ đệm (256byte) sẽ mất khoảng 9ms: 230,4kbit = 28,8kByte = 1 / 28,8 = 34,722us mỗi byte * 256byte = 8,88ms / 256byte tôi nghĩ lần này không tốt cho việc theo dõi thời gian thực
MrBit

nếu tôi muốn làm mới biểu mẫu của mình cứ sau 10 - 100ms (gửi dữ liệu nhận sau mỗi 10 - 100ms) thì sẽ không còn thời gian để AVR xử lý các tác vụ khác.
MrBit

@ user3829694 - Được rồi, vì vậy bạn muốn di chuyển dữ liệu nhanh chóng, với ít chi phí.
xe cứu thương
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.