Arka fon

Mütevazı mikrodenetleyici özellikleri gerektiren bir proje geliştiriyorum:

• 8 12 bit, 10 kHz ADC
• 1kB RAM
• 48-QFN veya daha küçük kaplama alanı
• 20kbps papatyayla zincirlenebilir gürültüye dayanıklı ve hata düzeltici iletişim protokolü

Sinyal işleme gereksinimleri oldukça düşüktür ve çoğu sistemdeki ana işlemciye aktarılabilir. İlk üç spesifikasyonun karşılanması kolaydır ve 2 dolardan daha az miktarda yapılabilir. Bununla birlikte, iletişim çok gürültülü bir ortamda gerçekleşecek, bu nedenle LIN ve I2C gibi gürültüye karşı savunmasız ağlar devre dışı. LIN'e karşı ek bir argüman, her şeyi 5V veya 3.3V'de çalıştırmak istiyorum ve LIN alıcı-vericileri 12V gerektirir ve bu nedenle sensör kartı başına ekstra bir regülatör veya tel gerektirir. Başlangıçta bu görev için CAN'ı seçtim. Bununla birlikte, CAN kontrolörleri önemli bir maliyet ekler ve bunun yazılımda yapılıp yapılamayacağını merak ediyorum.

CAN Fiziksel Katman

CAN spesifikasyonu, OSI ağ referans modelinin Veri Bağlantısı ve Fiziksel katmanlarını tanımlar. Fiziksel katmanı uygulamak için NXP TJA1040 / 50 , Maxim MAX3058 / 59 , Microchip MCP2551 ve TI SN65HVD1050 gibi birçok ucuz 8 pimli IC mevcuttur. Fiziksel katmanı D / A dönüştürücüler veya op-amplerle uygulamak imkansız olmasa bile zor olacaktır, bu nedenle bu IC'ler maliyeti 1 $ ya da daha fazladır.

CAN Veri Bağlantısı / Protokol Katmanı

Veri Bağlantısı katmanı için, bazı mikro denetleyiciler temel UART, I2C ve SPI iletişim katmanlarına CAN protokol modülleri ekler. Bununla birlikte, bunlar temel yongalardan önemli ölçüde daha pahalıdır.

CAN protokol modüllerinin maliyetinin araştırılması

Bu iddiayı doğrulamak için, CAN ve CAN dışı sürümlerde birkaç popüler mikro:

• ATmega16 - ATMEGA16M1 (CAN ile): 3,87 $, ATMEGA168A (CAN yok): 3,23 $
• dsPIC - DSPIC33FJ64MC802 (CAN ile): 6.14 $, DSPIC33FJ64GP202 (CAN yok): 5.48 $
• PIC18 - PIC18F2480 (CAN ile): 6.80 $, PIC18F24J10 (CAN yok): 2.10 $
• Cortex-M3 - STM32F103C4T6A (CAN ile): 6,50 dolar, STM32F100C4T6B (CAN yok): 2,73 dolar

Adil olmak gerekirse, sadece eşdeğer bellek boyutlarına sahip mikro denetleyicileri karşılaştırdım, ancak CAN olmayan sürümlerin çoğu daha küçük bellek boyutlarıyla daha az kullanılabilir. Microchip MCP2515 gibi harici CAN denetleyicileri neredeyse 2 $ ' dır , bu nedenle seçeneğiniz varsa CAN'ın mikro denetleyiciye entegre edilmesi açıktır.

İlginçtir, ATmega kısmı, Digikey'in envanterinde açık ara CAN donanımlı en ucuz parçadır.

CAN protokol katmanının işlevi

DsPIC mikro denetleyicilerinde bulunan CAN modülü aşağıdakileri yapar:

CAN bus modülü bir protokol motoru ve mesaj tamponlama / kontrolünden oluşur. CAN protokol motoru, CAN veri yolunda mesaj almak ve iletmek için tüm işlevleri yerine getirir. Mesajlar ilk olarak uygun veri kayıtları yüklenerek iletilir. Durum ve hatalar uygun kayıtlar okunarak kontrol edilebilir. CAN veriyolunda algılanan tüm mesajlar hatalara karşı kontrol edilir ve daha sonra, alıcı kayıtlarından birinde alınması ve saklanması gerekip gerekmediğini görmek için filtrelerle eşleştirilir.

Bu yazılımda oldukça yapılabilir görünüyor.

Soru

Bir yazılım protokolü katmanı yalnızca düşük maliyetli bir UART donanımlı mikrodenetleyici ve bir CAN alıcı-vericisi ile CAN spesifikasyonunu uygulamak için kullanılabilir mi? Varsa, açık kaynaklı uygulamalar var mı?

Alternatif olarak, alıcı-vericiler UART'larla özel bir protokol uygulamak için kullanılabilir mi? Tek master bir topoloji ile iyiyim; Tahkimin özel bir protokolde doğru bir şekilde elde edilmesinin zor olabileceğini anlıyorum.

CAN protokolünün sadece bellenimde uygulanmasının zor olacağını ve doğru olması biraz zaman alacağını düşünüyorum. İyi bir fikir değil.

Ancak, fiyatlarınız yüksek. Az önce kontrol ettim ve QFN paketindeki bir dsPIC 33FJ64GP802, 1000 adet için mikroçipirektte 3.68 USD satıyor. Gerçek üretim hacimleri için fiyat daha düşük olacaktır.

Donanım CAN çevre birimi sizin için bazı gerçek şeyler yapar ve fiyat artışı, iddia ettiğiniz şeyin yakınında değildir.

Katma:

Ürün yazılımı rotasını denemeye kararlı olduğunuz için, akla gelen belirgin sorunlardan bazıları. Büyük olasılıkla henüz başıma gelmemiş başka sorunlar olacak.

20 kbit / s hızda CAN yapmak istiyorsunuz. Bu, CAN için çok yavaş bir hızdır ve en az 10 metre boyunca 1Mbit / s'ye kadar çıkar. Bir veri noktası vermek için, NMEA 2000 gemi sinyalizasyon standardı CAN üzerinde 200 kbits / s'de katmana yerleştirilmiştir ve bu büyük bir geminin bir ucundan diğer ucuna gitmek içindir.

İhtiyacınız olan her şeyin bit başına bir kesinti olduğunu düşünebilirsiniz ve ihtiyacınız olan her şeyi bu kesintide yapabilirsiniz. Bu işe yaramaz, çünkü her CAN bit zamanında birkaç şey oluyor. Özellikle alt bit düzeyinde iki şey yapılması gerekir. Birincisi bir çarpışmayı tespit etmek, ikincisi ise bit hızını anında ayarlamak.

Bir CAN veriyolunda resesif ve baskın olan iki sinyal durumu vardır. Resesif, hiçbir şey otobüsü sürmediğinde olur. Her iki hat da toplam 60 by ile birlikte çekilir. MCP2551 gibi ortak yongalar tarafından uygulanan normal bir CAN veriyolunda, her iki uçta 120 Ω sonlandırıcı bulunmalıdır, dolayısıyla toplam 60 the, iki diferansiyel hattı pasif olarak bir araya getirmelidir. Baskın durum, eğer doğru hatırlıyorsam, her iki hattın aktif olarak ayrıldığı zaman, resesif durumdan 900mV civarında bir yerde. Temel olarak, bu bir diferansiyel çift ile uygulanması dışında açık bir toplayıcı veri yolu gibidir. CANH-CANL <900mV ise bus resesif durumdadır ve CANH-CANL> 900mV olduğunda baskındır. Baskın durum 0 ve resesif 1'i işaret eder.

Bir düğüm otobüse "1" yazdığında (gitmesine izin verir), başka bir düğümün 0 yazıp yazmadığını kontrol eder. Gönderdiğinizi düşündüğünüzde otobüsü baskın durumda (0) bulduğunuzda ve Şu anda gönderdiğiniz bit 1, o zaman başka biri de gönderiyor demektir. Çarpışmalar sadece iki gönderenin aynı fikirde olmaması durumunda önemlidir ve kural, resesif durumu gönderenin mesajını geri çekmesi ve iptal etmesidir. Baskın devleti gönderen düğüm bunun olduğunu bile bilmiyor. Bir CAN veriyolunda tahkim böyle çalışır.

CAN veri yolu tahkim kuralları, başkasının 0 göndermediğinden emin olmak için 1 olarak gönderdiğiniz her bit üzerinden otobüsü yarı yolda izlemeniz gerektiği anlamına gelir. Bu kontrol genellikle bitin yaklaşık 2 / 3'ü kadar yapılır. ve CAN veri yolu uzunluğundaki temel sınırlamadır. Bit hızı ne kadar yavaş olursa, veri yolunun bir ucundan diğer ucuna en kötü durum yayılımı için o kadar fazla zaman vardır ve bu nedenle veri yolu daha uzun olabilir. Bu kontrol , otobüse sahip olduğunuzu ve 1 bit gönderdiğinizi düşündüğünüz her bitte yapılmalıdır .

Başka bir sorun da bit hızı ayarlamasıdır. Bir otobüsteki tüm düğümler bit hızı üzerinde RS-232'den daha yakın olmalıdır. Küçük saat farklılıklarının önemli hatalara dönüşmesini önlemek için, her bir düğüm nominal değerinden biraz daha uzun veya daha kısa bir işlem yapabilmelidir. Donanımda bu, bit hızından 9x ila 20x daha hızlı bir yerde bir saat çalıştırarak uygulanır. Bu hızlı saatin döngülerine time quanta denir. Yeni bitlerin başlamasının, olması gerektiğini düşündüğünüz yere göre dolaştığını tespit etmenin yolları vardır. Donanım uygulamaları daha sonra yeniden senkronize etmek için biraz bir kez quanta ekler veya atlar. Beklenen bit süreleri ile gerçek ölçülen bit süreleri arasındaki fazdaki küçük farklılıklara ayarlayabildiğiniz sürece bunu uygulamanın başka yolları da vardır.

Her iki durumda da, bu mekanizmalar biraz farklı zamanlarda çeşitli şeylerin yapılmasını gerektirir. Bu tür zamanlama bellenimde çok zorlaşır veya otobüsün çok yavaş çalışmasını gerektirir. Diyelim ki, 20 kbit / s hızında firmware'de bir zaman quanta sistemi uyguluyorsunuz. Her bit için en az 9 zaman kanadı, 180 kHz kesme gerektirir. Bir dsPIC 33F gibi bir şeyle bu kesinlikle mümkündür, ancak işlemcinin önemli bir kısmını yiyecektir. Maksimum 40 MHz komut hızında, kesme başına 222 komut döngüsü elde edersiniz. Tüm kontrolleri yapmak o kadar uzun sürmemeli, ama muhtemelen 50-100 döngü, yani işlemcinin% 25-50'si CAN için kullanılacak ve çalışan diğer her şeyi önceden alması gerekecek. Bu, bu işlemcilerin sıklıkla çalıştığı birçok uygulamayı önler, anahtarlama güç kaynağı veya motor sürücüsünün darbe kontrolü ile darbe gibi. Her kesmede 50-100 döngü gecikmesi, böyle yongalarla yaptığım birçok şey için tam bir gösteri durdurucu olacaktır.

Yani bir şekilde CAN yapmak için para harcayacaksınız. Bu amaca yönelik özel donanım çevre biriminde değilse, önemli yazılım yükünü kaldıracak daha büyük bir işlemciye sahip olmak ve daha sonra diğer her şey için öngörülemeyen ve olası büyük kesme gecikmesi ile başa çıkmak.

Sonra bir ön mühendislik var. CAN çevre birimi çalışır. Yorumunuzdan, bu çevre biriminin artan maliyeti 0,56 ABD doları gibi görünüyor. Bu benim için bir pazarlık gibi görünüyor. Çok yüksek hacimli bir ürününüz olmadığı sürece, CAN'ı yalnızca ürün yazılımına uygulamak için harcayacağınız önemli zaman ve masrafı geri almanın bir yolu yoktur. Hacimleriniz bu kadar yüksekse, bahsettiğimiz fiyatlar zaten gerçekçi değil ve CAN donanımını ekleme farkı daha düşük olacak.

Gerçekten bunun mantıklı olduğunu görmüyorum.

Biz kullanmak PIC18F25K80 . Bir DSP'si olmasa da, miktarı ~ 2 $. Bahsettiğiniz PIC18F2480 için neredeyse doğrudan bir yedek. Muhtemelen Microchip'ten taşınan CAN için CCS derleyicisini ve yazılım yığınını kullanıyoruz. İhtiyacım olan ve denediğim her şey için iyi çalışıyor.

Bunu doğru okuyorsam, sadece bir UART ve bazı akıllı bellenim kullanarak CAN işlevselliğini bitirmek istediğiniz gibi görünüyor. Güven bana, bu asla işe yaramayacak - CAN veya CANopen'in incelikleri hakkında iyi bir metin okumanızı öneririm. Bu rotadan giderek, aradığınız tüm maliyet tasarruflarını ortadan kaldıracaksınız.

Ben ya bir CAN modülü ile bir mikrodenetleyici kullanmak ve ekstra 2 $ geçmek veya RS-485 üzerinde Modbus gibi bir UART ile uyumlu farklı bir protokol düşündünüz mü?

Ben de bir PIC µC üzerinde bit-bang CAN-Protokolü düşünüyorum, bu yüzden lütfen EricM, eğer gerçekten yaptıysanız, lütfen en azından PIC18F veya DSPic'in çekirdek frekansında hangi bit hızında cevap verdiğinizi söyleyin. Teşekkürler!

Genel olarak: RS 485, birincil sorulan sorunun çözümü olacaktır, ancak tüm protokollerde olduğu gibi tam dubleks olmayan UART iletişimi (nokta 2 noktası) olan CAN- (hatta FlexRay) -Transceiver'leri kullanmak da mümkün olacaktır. NRZ kodlaması kullanın.

Ancak UART / V24 / RS232'de tam dubleks çoğunlukla ayrıntılı olarak düşünmeden kullanılır, bu yüzden belki de uygulamanızın süper döngüsüne veya statemachine biraz beyin koymanız gerekir ...

Ama geri CAN-bitbanging: Ben yıllardır CAN ile çalışıyorum ve asla bir bitbanging uygulama görmedim, ama düşünebildiğim kadarıyla, DSPic veya ARM gibi modern µC ile tp 100kBit bit zamanlamaları için çalışması gerekir. (80MHz veya üzerinde Çekirdeklere sahip ...)

En azından sadece geri okuma kabul edilirse ... Gönderme, bit yapılarının hazırlanmasında biraz ek yük anlamına gelir, böylece% 100 veri yüküne ulaşılamaz, ancak CAN'ta% 65'ten fazlası nadirdir ...