Lý lịch

Tôi đang phát triển một dự án sẽ yêu cầu thông số kỹ thuật vi điều khiển khiêm tốn của:

• 8 ADC 12 bit, 10kHz
• 1kB RAM
• Dấu chân 48-QFN hoặc nhỏ hơn
• Giao thức truyền thông sửa lỗi và chống nhiễu 20kbps

Yêu cầu xử lý tín hiệu khá thấp và hầu hết có thể được xuất sang bộ xử lý chính trong hệ thống. Ba thông số kỹ thuật đầu tiên rất dễ gặp và có thể được thực hiện với số lượng ít hơn 2 đô la. Tuy nhiên, giao tiếp sẽ diễn ra trong một môi trường rất ồn, do đó, các mạng dễ bị nhiễu như LIN và I2C bị loại bỏ. Một lập luận bổ sung chống lại LIN là tôi muốn chạy toàn bộ ở mức 5V hoặc 3.3V, và các bộ thu phát LIN yêu cầu 12V, và do đó sẽ cần thêm bộ điều chỉnh hoặc dây trên mỗi bảng cảm biến. Ban đầu tôi chọn CAN cho nhiệm vụ này. Tuy nhiên, bộ điều khiển CAN thêm chi phí đáng kể và tôi tò mò liệu điều này có thể được thực hiện trong phần mềm hay không.

Lớp vật lý CAN

Đặc tả CAN xác định các lớp Liên kết dữ liệu và Vật lý của mô hình tham chiếu mạng OSI. Nhiều IC 8 chân rẻ tiền, chẳng hạn như NXP TJA1040 / 50 , Maxim MAX3058 / 59 , Microchip MCP2551 và TI SN65HVD1050 tồn tại để thực hiện lớp vật lý. Việc thực hiện lớp vật lý với bộ chuyển đổi D / A hoặc op-amps sẽ rất khó, nếu không nói là không thể, vì vậy những IC này rất đáng giá $ 1 hoặc do đó chúng có giá.

Lớp liên kết / giao thức dữ liệu CAN

Đối với lớp Liên kết dữ liệu, một số bộ vi điều khiển thêm các mô đun giao thức CAN vào các lớp truyền thông UART, I2C và SPI cơ bản. Tuy nhiên, những thứ này đắt hơn đáng kể so với các chip cơ bản.

Điều tra chi phí của các mô-đun giao thức CAN

Để chứng minh cho tuyên bố này, đây là một vài micros phổ biến trong các phiên bản CAN và không CAN, từ:

• ATmega16 - ATMEGA16M1 (có CAN): 3,87 đô la, ATMEGA168A (không CÓ THỂ): 3,23 đô la
• DSPIC - DSPIC33FJ64MC802 (có CAN): 6,14 đô la, DSPIC33FJ64GP202 (không thể CAN): 5,48 đô la
• PIC18 - PIC18F2480 (có CAN): 6,80 đô la, PIC18F24J10 (không thể CAN): 2,10 đô la
• Cortex-M3 - STM32F103C4T6A (có CAN): 6,50 đô la, STM32F100C4T6B (không thể CAN): 2,73 đô la

Công bằng mà nói, tôi chỉ so sánh các bộ vi điều khiển với kích thước bộ nhớ tương đương, tuy nhiên, nhiều phiên bản không thể CAN có sẵn với kích thước bộ nhớ nhỏ hơn với giá rẻ hơn. Các bộ điều khiển CAN bên ngoài, như Microchip MCP2515 , có giá gần 2 đô la, vì vậy rõ ràng sẽ hiệu quả hơn về mặt chi phí khi tích hợp CAN vào vi điều khiển nếu bạn có tùy chọn.

Thật thú vị, phần ATmega cho đến nay là phần được trang bị CAN rẻ nhất trong kho của Digikey.

Chức năng của lớp giao thức CAN

Mô-đun CAN được tìm thấy trong các bộ vi điều khiển DSPIC thực hiện như sau:

Mô-đun bus CAN bao gồm một công cụ giao thức và bộ đệm / điều khiển thông báo. Công cụ giao thức CAN xử lý tất cả các chức năng để nhận và truyền tin nhắn trên bus CAN. Tin nhắn được truyền bằng cách tải đầu tiên các thanh ghi dữ liệu thích hợp. Tình trạng và lỗi có thể được kiểm tra bằng cách đọc các thanh ghi thích hợp. Bất kỳ thông báo nào được phát hiện trên bus CAN đều được kiểm tra lỗi và sau đó khớp với các bộ lọc để xem liệu nó có nên được nhận và lưu trữ trong một trong các thanh ghi nhận không.

Điều này có vẻ khá khả thi trong phần mềm.

Câu hỏi

Một lớp giao thức phần mềm có thể được sử dụng để thực hiện đặc tả CAN chỉ với một bộ vi điều khiển được trang bị UART rẻ tiền và bộ thu phát CAN không? Nếu vậy, có bất kỳ triển khai nguồn mở nào tồn tại không?

Ngoài ra, bộ thu phát CAN có thể được sử dụng với UART để thực hiện giao thức tùy chỉnh không? Tôi ổn với cấu trúc liên kết đơn chủ; Tôi hiểu rằng trọng tài có thể khó có được ngay trong một giao thức tùy chỉnh.

Tôi nghĩ rằng việc thực hiện giao thức CAN chỉ trong phần sụn sẽ khó khăn và sẽ mất một thời gian để hoàn thành đúng. Đó không phải là một ý hay.

Tuy nhiên, giá của bạn cao. Tôi vừa kiểm tra, và một gói DSPIC 33FJ64GP802 trong gói QFN được bán với giá 3,68 USD trên microchipdirect cho 1000 chiếc. Giá sẽ thấp hơn cho khối lượng sản xuất thực tế.

Phần cứng ngoại vi CAN có thể thực hiện một số điều thực sự cho bạn và việc tăng giá cho nó không ở đâu gần với những gì bạn đang yêu cầu.

Thêm:

Vì bạn dường như quyết tâm thử tuyến phần sụn, đây là một số vấn đề rõ ràng xuất hiện trong đầu. Nhiều khả năng sẽ có những vấn đề khác chưa xảy ra với tôi.

Bạn muốn làm CAN với tốc độ 20 kbit / s. Đó là tốc độ rất chậm đối với CAN, lên tới 1Mbit / giây trong ít nhất 10 giây. Để cung cấp cho bạn một bảng dữ liệu, tiêu chuẩn báo hiệu tàu NMEA 2000 được xếp lớp trên CAN với tốc độ 200 kbits / giây và điều đó có nghĩa là đi từ đầu này đến đầu kia của tàu lớn.

Bạn có thể nghĩ rằng tất cả những gì bạn cần là một ngắt trên mỗi bit và bạn có thể làm mọi thứ bạn cần trong ngắt đó. Điều đó sẽ không hiệu quả vì có một số điều đang diễn ra trong mỗi thời gian CÓ THỂ. Hai điều đặc biệt cần phải được thực hiện ở cấp độ bit phụ. Đầu tiên là phát hiện va chạm và thứ hai là điều chỉnh tốc độ bit khi đang bay.

Có hai trạng thái báo hiệu trên xe buýt CAN, lặn và chiếm ưu thế. Recessive là những gì xảy ra khi không có gì lái xe buýt. Cả hai dòng được kéo với nhau tổng cộng 60. Một bus CAN bình thường được triển khai bởi các chip thông thường như MCP2551, nên có 120 Ω đầu cuối ở cả hai đầu, do đó tổng cộng 60 kéo hai dòng vi phân lại với nhau một cách thụ động. Trạng thái chiếm ưu thế là khi cả hai đường dây được tích cực kéo ra, khoảng 900mV từ trạng thái lặn nếu tôi nhớ đúng. Về cơ bản, đây giống như một chiếc xe buýt thu mở, ngoại trừ việc nó được triển khai với một cặp vi sai. Xe buýt ở trạng thái lặn nếu CANH-CANL <900mV và chiếm ưu thế khi CANH-CANL> 900mV. Trạng thái chiếm ưu thế báo hiệu 0 và trạng thái lặn 1.

Bất cứ khi nào một nút "ghi" 1 vào xe buýt (cho phép nó đi), nó sẽ kiểm tra xem một số nút khác có ghi 0. Khi bạn tìm thấy xe buýt ở trạng thái vượt trội (0) khi bạn nghĩ rằng bạn đang gửi và bit hiện tại bạn đang gửi là 1, điều đó có nghĩa là người khác cũng đang gửi. Va chạm chỉ quan trọng khi hai người gửi không đồng ý, và quy tắc là người gửi trạng thái ẩn trở lại và hủy bỏ tin nhắn của nó. Nút gửi trạng thái vượt trội thậm chí không biết điều này đã xảy ra. Đây là cách trọng tài hoạt động trên xe buýt CAN.

Các quy tắc trọng tài xe buýt CAN có nghĩa là bạn phải xem xe buýt giữa chừng thông qua mỗi bit bạn gửi là 1 để đảm bảo người khác không gửi 0. Kiểm tra này thường được thực hiện khoảng 2/3 đường vào bit và là giới hạn cơ bản về chiều dài xe buýt CAN. Tốc độ bit càng chậm, thời gian lan truyền trong trường hợp xấu nhất từ ​​đầu này sang đầu kia của xe buýt càng nhiều, và do đó, xe buýt có thể càng dài. Kiểm tra này phải được thực hiện mỗi bit nơi bạn nghĩ rằng bạn sở hữu xe buýt và đang gửi 1 bit.

Một vấn đề khác là điều chỉnh tốc độ bit. Tất cả các nút trên xe buýt phải đồng ý về tốc độ bit, chặt chẽ hơn so với RS-232. Để ngăn sự khác biệt nhỏ của đồng hồ tích lũy thành các lỗi đáng kể, mỗi nút phải có thể thực hiện một bit dài hơn hoặc ngắn hơn một chút so với danh nghĩa của nó. Trong phần cứng, điều này được thực hiện bằng cách chạy đồng hồ ở đâu đó nhanh hơn khoảng 9x đến 20 lần so với tốc độ bit. Các chu kỳ của đồng hồ nhanh này được gọi là lượng tử thời gian. Có nhiều cách để phát hiện ra rằng sự khởi đầu của các bit mới đang đi lang thang liên quan đến nơi mà bạn nghĩ chúng nên có. Việc triển khai phần cứng sau đó thêm hoặc bỏ qua lượng tử một lần trong một chút để đồng bộ hóa lại. Có nhiều cách khác bạn có thể thực hiện điều này miễn là bạn có thể điều chỉnh các khác biệt nhỏ theo pha giữa thời gian bit dự kiến ​​và thời gian bit thực tế đo được.

Dù bằng cách nào, các cơ chế này đòi hỏi nhiều thứ phải được thực hiện ở nhiều thời điểm khác nhau trong một chút. Kiểu thời gian này sẽ rất phức tạp trong phần sụn, hoặc sẽ yêu cầu xe buýt chạy rất chậm. Giả sử bạn triển khai hệ thống lượng tử thời gian trong phần sụn với tốc độ 20 kbits / s. Ở mức tối thiểu 9 lượng tử thời gian trên mỗi bit, điều đó sẽ yêu cầu ngắt 180 kHz. Điều đó chắc chắn là có thể với một cái gì đó giống như một DSPIC 33F, nhưng sẽ ăn một phần đáng kể của bộ xử lý. Ở tốc độ lệnh tối đa 40 MHz, bạn nhận được 222 chu kỳ lệnh cho mỗi lần ngắt. Sẽ không mất nhiều thời gian để thực hiện tất cả việc kiểm tra, nhưng có thể là 50 - 100 chu kỳ, nghĩa là 25-50% bộ xử lý sẽ được sử dụng cho CAN và nó sẽ cần phải tránh mọi thứ khác đang chạy. Điều đó ngăn cản nhiều ứng dụng mà các bộ xử lý này thường chạy, như xung bằng điều khiển xung của nguồn cung cấp năng lượng chuyển đổi hoặc trình điều khiển động cơ. Độ trễ chu kỳ 50-100 trên mỗi ngắt khác sẽ là một điểm dừng hiển thị hoàn chỉnh cho nhiều điều tôi đã thực hiện với các chip như thế này.

Vì vậy, bạn sẽ dành tiền để làm CÓ THỂ bằng cách nào đó. Nếu không phải trong thiết bị ngoại vi phần cứng chuyên dụng dành cho mục đích đó, thì trong việc có một bộ xử lý lớn hơn để xử lý chi phí phần mềm đáng kể và sau đó xử lý độ trễ ngắt lớn không thể đoán trước và có thể xảy ra cho mọi thứ khác.

Sau đó là kỹ thuật lên phía trước. Thiết bị ngoại vi CAN chỉ hoạt động. Từ nhận xét của bạn, có vẻ như chi phí gia tăng của thiết bị ngoại vi này là $ 0,5. Đó dường như là một món hời đối với tôi. Trừ khi bạn có một sản phẩm có khối lượng rất lớn, không có cách nào bạn sẽ lấy lại được thời gian và chi phí đáng kể để chỉ thực hiện CAN trong phần sụn. Nếu khối lượng của bạn quá cao, dù sao giá chúng tôi đã đề cập không thực tế và chênh lệch để thêm phần cứng CAN sẽ thấp hơn.

Tôi thực sự không thấy điều này có ý nghĩa.

Chúng tôi sử dụng PIC18F25K80 . Mặc dù nó không có DSP, nhưng số lượng ~ 2 đô la. Nó gần như là một sự thay thế trực tiếp cho PIC18F2480 mà bạn đề cập. Chúng tôi sử dụng trình biên dịch CCS và ngăn xếp phần mềm của họ cho CAN có thể được chuyển từ Microchip. Nó hoạt động tốt cho mọi thứ tôi cần và đã thử.

Nếu tôi đang đọc đúng, có vẻ như bạn muốn bit-bash chức năng CAN chỉ sử dụng một UART và một số phần mềm thông minh. Tin tôi đi, điều này sẽ không bao giờ có tác dụng - Tôi khuyên bạn nên đọc một văn bản hay về những điều phức tạp của CAN hoặc CANopen. Bạn sẽ xóa bỏ mọi khoản tiết kiệm chi phí mà bạn đang tìm kiếm bằng cách đi xuống tuyến đường này.

Tôi sẽ sử dụng một vi điều khiển với mô-đun CAN và vượt qua $ 2 trở lên, hoặc bạn có nghĩ về một giao thức khác tương thích với UART, chẳng hạn như Modbus qua RS-485 không?

Tôi cũng đang suy nghĩ về giao thức CAN-biting trên PIC PIC, vì vậy xin vui lòng EricM, nếu bạn thực sự đã làm điều đó, vui lòng trả lời và ít nhất, bitrate ở tần số lõi nào của PIC18F hoặc DSPic mà bạn có. Cám ơn!

Nói chung: RS 485 sẽ là giải pháp cho vấn đề chính được hỏi, nhưng cũng có thể sử dụng CAN- (hoặc thậm chí FlexRay) -Transceivers với giao tiếp UART không song công (điểm 2 điểm) như tất cả các giao thức đó sử dụng mã hóa NRZ.

Nhưng trong song công toàn bộ UART / V24 / RS232 hầu hết được sử dụng mà không cần suy nghĩ chi tiết, vì vậy có lẽ bạn sẽ cần phải đặt một số bộ não lên superloop hoặc stHRachine của ứng dụng của bạn ...

Nhưng trở lại với CAN-bitbanging: Tôi đã làm việc với CAN trong nhiều năm và chưa bao giờ thấy việc triển khai bitbanging, nhưng theo tôi có thể nghĩ, điều đó sẽ hoạt động với tính năng định thời bit lên 100kBit với hiện đại như DSPC hoặc ARM, v.v. (có Lõi ở 80 MHz trở lên ...)

Ít nhất là nếu chỉ xem lại đọc ... Gửi có nghĩa là một số chi phí trong việc chuẩn bị cấu trúc bit sao cho không thể truy cập 100% bus, nhưng trong CAN có thể hơn 65% là hiếm ...