Çoklu mikrodenetleyiciler arasındaki iletişim

N mikrodenetleyiciden (N> = 2 MCU) oluşan bir sistem uygulamaya başlamak istiyorum, ancak bir diğeriyle iletişim kurmalarına olanak tanımak istiyorum.

İdeal olarak, (N-1) mikrodenetleyicileri evin içinde istemci olarak görev yaparken, sonuncusu ("sunucu") USB ile bir PC'ye bağlanır. Şu anda sahip olduğum problemler bu (N-1) mikrodenetleyicileri "sunucu" ya nasıl bağlayacağım. İstemciler MCU'ları çok basit görevler yerine getirir, bu nedenle sadece CAN / PHY-MAC sağladıkları için böyle basit işler yapmak için ARM'leri kullanmak iyi bir çözüm olmayabilir .

İletişim, çoğu cihaz için birkaç dakikada bir defadan fazla ve başkaları için talep üzerine gerçekleşmeyecektir. Hız çok kritik değil (mesaj kısa): 1 Mbit / s Sanırım benim için WAY overkill.

Kullanmayı planladığım MCU'lar şunlardır.

• Atmel AVR Küçük / Mega
• TI MSP430
• ARM Cortex M3 / M4
• (Muhtemelen Atmel AVR UC3 - 32 bit)

Mümkünse PIC'lerden kaçınmak istiyorum (kişisel seçim), çünkü bunları programlamak için daha az olasılık vardır (yukarıdakilerin hepsinin az ya da çok açık kaynak aracı ve bazı resmi araçları vardır).

Bazı ARM'lerin CAN işlevi sağladığını biliyorum ve diğerleri hakkında o kadar emin değilim.

Şu anda bu olasılıkları buldum:

1. Veri göndermek için basit GPIO (mesajın başlangıcını belirtmek için YÜKSEK> 16 bit, mesajın sonunu belirtmek için DÜŞÜK> 16 bit). Bununla birlikte, tüm bitleri algılayabilmek için standart bir frekansta << (frekans_sayı, frekans_server) olmalıdır. İstemci MCU'su başına yalnızca bir kablo gerekir.
2. RS-232 : Bunun en yaygın kullanılan iletişim protokolü olduğunu düşünüyorum, ancak ne kadar iyi ölçeklendiğini bilmiyorum. Şu anda en fazla 64 müşteri MCU'sunu düşünüyorum (muhtemelen daha sonra)
3. USB: AFAIK bu çoğunlukla RS-232'ye benziyor, ancak bu durumda çok iyi ölçeklendiğini sanmıyorum (USB birçok cihazı desteklese de - doğru hatırlıyorsam 255 - bu uygulama için aşırı karmaşık olabilir)
4. RJ45 / Ethernet: Gerçekten kullanmak istediğim şey bu, çünkü uzun mesafelerde sorunsuz bir şekilde iletime izin veriyor (en azından korumalı> Cat 6 kablosu ile). Sorun maliyettir (PHY, MAC, transformatör, ...). Gerçi evde iyi lehimleme yapabiliyor musunuz bilmiyorum. Bu şekilde bir müşteri MCU'suna ihtiyacım olmaz
5. Kablosuz / ZigBee : modüller çok pahalıdır, ancak masanın arkasında "spagetti" den kaçınmanın yolu olabilir
6. RF modülleri / alıcı-vericiler: 300 MHz - 1 GHz bandındakilerden bahsediyorum, bu yüzden evde lehimlemek zor olmalı. Modüllerin hepsi yerleşiktir, ancak ZigBee kadar pahalıdırlar (en azından RF'in Mouser'daki modülleri, Sparkfun'da daha ucuz olanları var gibi görünüyor).
7. YAPABİLMEK? Çok sağlam görünüyor. Otomotiv uygulamalarında kullanmayı düşünmeme rağmen, yine de iyi bir alternatif olabilir.
8. I²C / SPI / UART ? Yine - mümkünse kablolarla "spagetti" den kaçının
9. PLC'ler gerçekten bir seçenek değildir. Uzunluk arttıkça ve güç şebekesinin kapasitans yüküne bağlı olarak performans oldukça hızlı düşer. Fiyat açısından Ethernet ile aynı olduğunu düşünüyorum.

Ayrıca, eşzamanlı iletim durumunda hangi protokol "daha iyi" olacaktır (diyelim ki aynı anda iki cihazın iletimine başlaması nadirdir: hangi protokol en iyi "çatışma yönetim sistemi" / "çarpışma yönetim sistemini" sağlar?

Özetlemek gerekirse : Hem esnekliği (maksimum cihaz sayısı, çakışma / çarpışma yönetim sistemi, ...) hem de fiyatı göz önünde bulundurarak çok hafif veri iletişimi yapan dağıtılmış bir istemci sistemi için en iyi çözümün ne olabileceğini duymak isterim , evde yapmak kolay (lehimleme), ... Ben sadece iletişim modülü üzerinde 20 $ harcamaktan kaçınmak istiyorum, ama aynı zamanda masanın arkasında 30 tel olması emmek olacaktır.

Şu anda görüntülediğim çözüm, GPIO veya RS-232 ile yakın MCU'lar arasında temel iletişim ( ucuz !) Yapmak ve sunucu ile iletişim kurmak için "bölge" başına bir MCU'da Ethernet / ZigBee / Wi-Fi kullanmak ( pahalı) olacaktır. ancak yine de her istemci MCU'su başına bir Ethernet modülünden çok daha ucuzdur).

Kablolar yerine fiber optik / optik fiberler kullanmak da mümkün olabilir. Ek dönüşümler gerekli olsa da ve bu durumda en iyi çözüm olup olmadığından emin değilim. Onlar hakkında ek ayrıntılar duymak istiyorum.

Bu durumda en uygun olan CAN olabilir. Bir evin içindeki mesafeler CAN tarafından 500 kbits / s'de ele alınabilir, bu da ihtiyaçlarınız için bol miktarda bant genişliği gibi görünür. Son düğüm raftan USB'den CAN arayüzüne olabilir. Bu, bilgisayardaki yazılımın CAN mesajları göndermesine ve veri yolundaki tüm mesajları görmesine izin verir. Gerisi, bunu dış dünyaya bir TCP sunucusu veya benzeri bir şey olarak sunmak istiyorsanız yazılımdır.

CAN, I / O hatları ile kendi yolunuzu yuvarlamak dışında, aslında bir veri yolu olduğunu belirten tek iletişim aracıdır. Diğerleri ethernet dahil olmak üzere noktadan noktaya. Ethernet, mantıksal olarak anahtarlı bir veri yolu gibi görünmek için yapılabilir, ancak bireysel bağlantılar hala noktadan noktayadır ve mantıksal veri yolu topolojisini almak pahalı olacaktır. Her işlemcideki bellenim yükü de CAN'dan çok daha fazladır.

CAN ile ilgili güzel kısım, en düşük birkaç protokol katmanının donanımda ele alınmasıdır. Örneğin, birden fazla düğüm aynı anda iletim yapmaya çalışabilir, ancak donanım çarpışmaların algılanması ve bunlarla başa çıkılmasıyla ilgilenir. Donanım, CRC sağlama toplamı oluşturma ve doğrulama da dahil olmak üzere tüm paketlerin gönderilmesi ve alınmasıyla ilgilenir.

PIC'lerden kaçınma nedenleriniz bir anlam ifade etmiyor. Kendi programınızı oluşturmak için programcılar için birçok tasarım var. Birincisi, LProg'um , bu sayfanın altından şematik. Bununla birlikte, zamanınızı kuruşa / saate değer vermedikçe, kendinizinkini oluşturmak uygun maliyetli olmayacaktır. Aynı zamanda programcıdan daha fazlası hakkında. Hata ayıklamaya yardımcı olacak bir şeye ihtiyacınız olacak. Microchip PicKit 2 veya 3 çok düşük maliyetli programlayıcılar ve hata ayıklayıcılardır. Onlarla hiçbir kişisel deneyimim olmasa da, başkalarının bunları rutin olarak kullandığını duyuyorum.

Katma:

RS-485 için bazı öneriler görüyorum, ancak bu CAN ile karşılaştırıldığında iyi bir fikir değil. RS-485 sadece elektrik standardıdır. Diferansiyel bir veriyoludur, bu nedenle çoklu düğümlere izin verir ve iyi bir gürültü bağışıklığına sahiptir. Bununla birlikte, CAN tüm bunlara, artı çok daha fazlasına sahiptir. CAN genellikle diferansiyel veri yolu olarak da uygulanır. Bazıları RS-485'in elektrikle arayüzünün basit olduğunu iddia ediyor. Bu doğrudur, ancak CAN da öyle. Her iki durumda da tek bir yonga bunu yapar. CAN durumunda, MCP2551 iyi bir örnektir.

Böylece CAN ve RS-485 elektriksel olarak hemen hemen aynı avantajlara sahiptir. CAN'ın en büyük avantajı bu katmanın üzerindedir. RS-485 ile bu katmanın üstünde hiçbir şey yoktur. Kendi başınasın. Otobüs tahkimi, paket doğrulaması, zaman aşımları, yeniden denemeler, vb.

CAN protokolü paketleri, sağlama toplamlarını, çarpışma yönetimini, yeniden denemeleri, vb. Tanımlar. Sadece orada zaten var ve düşünülmüş ve test edilmiş değil, aynı zamanda gerçekten büyük avantajı birçok mikrodenetleyicide doğrudan silikonda uygulanmasıdır. Aygıt yazılımı, paket gönderme ve alma düzeyinde CAN çevre birimine arayüz oluşturur. Gönderme için, donanım, çarpışma algılama, geri çekilme, yeniden deneme ve CRC sağlama toplamı oluşturma işlemini gerçekleştirir. Almak için, paket algılama, saat eğimi ayarlama ve CRC sağlama toplamı doğrulaması yapar. Evet, CAN çevre birimi genellikle RS-485 ile kullanılan gibi bir UART'tan daha fazla bellenim alacaktır, ancak silikon düşük seviyeli protokol ayrıntılarının çoğunu işlediğinden genel olarak çok daha az kod alır.

Kısacası, RS-485 geçmiş bir çağdan geliyor ve bugün yeni sistemler için çok az mantıklı. Asıl mesele geçmişte RS-485'i kullanan ve CAN'ın bir şekilde "karmaşık" olduğunu düşünen insanlar gibi görünüyor. Düşük CAN seviyeleri karmaşıktır, ancak herhangi bir yetkili RS-485 uygulaması da karmaşıktır. RS-485 tabanlı bazı iyi bilinen protokollerin yerini CAN tabanlı yeni sürümler almıştır. NMEA2000 daha yeni CAN tabanlı bir standarda bir örnektir. CAN tabanlı OBD-II ve J-1939'da artık eski olan başka bir otomotiv standardı J-J1708 (RS-485 tabanlı) var.

CAN özelliğine sahip denetleyiciyi öneririm, çünkü bu özellik tam olarak denetleyici ağ amaçlarına yöneliktir.

RS232 kolayca uygulanabilir, ancak iletişimi 2 düğümden fazla uygulamaya çalışırsanız (bu amaç için oluşturulmadığından) gerçekten zorlaşacaktır.

Ethernet uygulaması için doğal olan bazı ana bilgisayar ve istemci bağlantılarından bahsettiğiniz için Ethernet de tatlı bir seçenek olabilir.

Aynı hattı tüm cihazlara bağlama olasılığı varsa, birden fazla kablo kullanan RS-485 burada iyi çalışabilir.

Örneğin, geleneksel kategori 5e ağ kablosu ile kullanılıyorsa, her iki yönde (tam bir dubleks modül kullanarak) veri iletimi için çalışmak için iki çiftiniz olabilir, ortak toprak olarak bir çift hatta belki tek bir tel ve müzakere etmek için geri kalanı olabilir hangi cihaz hangi anda iletecek. RS-232'den biraz daha karmaşıktır, ancak modüller CAN ve Ethernet'ten daha ucuzdur ve kablo sınırı 1200 m'dir. Dezavantajı, kendi çatışma çözümleme protokolünüzü yapmanız gerektiğidir. İletmek isteyen cihazı, özel bir kabloyu kontrol edip yüksek olup olmadığını kontrol edin. Değilse, yüksek konuma getirin ve iletişim kurmaya başlayın ve öyleyse rastgele bir süre bekleyin. Yine de bunun uzun mesafelerde ne kadar iyi çalışacağından emin değilim.

Manchester Encoding verileriyle çalışan bir RS-485 otobüsü seçerim .

RS-485 çünkü:

• Ucuz
• Uygulaması kolaydır
• Güç kullanır
• Uzun mesafelere izin verir (1200 metreye kadar)
• Yüksek veri hızları (10 Mbps'ye kadar)
• Parazitlere karşı yüksek bağışıklık
• Aynı veriyolunda 256 cihaza kadar izin veren alıcı-vericiler vardır
• Düşük parça sayısı

Manchester kodlaması çünkü:

• Uygulaması kolaydır
• Kendiliğinden senkronize edilebilir

Veri bütünlüğü için mesaj bir uzunluk ve bir CRC alanı içerebilir.

CRC işlevi örneği:

unsigned char crc_calc(unsigned char buffer[], unsigned short size)
{
  unsigned long i;
  unsigned char crc;

  crc = CRC_INIT;

  for (i=0;i<size * 8;i++)
  {
    crc = (crc << 1) | (crc >> (7));

    if (buffer[i/8] & (0x80 >> (i%8)))
    {
      crc ^= CRC_POLY;
    }
  }

  return crc;
}

CRC_INITve CRC_POLYCRC'yi hesaplamak için kullanılan rastgele değerlerdir.

Uzunluk ve CRC alanlarına sahip bir mesaj örneği:

Tercih ettiğiniz seçeneği Ethernet ile tercih ettiğim seçenek olan CAN ile karşılaştıralım.

Gerekli bileşenler:

• Ethernet: RJ45 konektör, manyetik, Phy çip (MCU'ya entegre edilmedikçe). Ayrıca, anahtarlardan her düğüme bir kabloya ve bir kabloya ihtiyacınız var. Her PCB, muhtemelen ferrit de olmak üzere, birkaç kapasitör ve sonlandırma direncine ihtiyaç duyar. İyi PCB tasarımına ihtiyaç duyar.
• CAN: Alıcı-verici çip (ucuz), herhangi bir konektör, ucuz kablo sitenin etrafındaki bir döngüde bir düğümden diğerine atlayabilir. Telsiz için sadece bir kapasitör ve otobüsün her iki ucunda bir sonlandırma direnci gerekir.

1 $ mikrodenetleyiciden bahsediyorsun. Otobüsün maliyeti MCU'dan çok daha fazlası var. Hangisinin daha ucuz olduğunu bilmek için her bir çözümün toplam maliyetini toplamalısınız. MCU, konektörler, alıcı-vericiler, pasif bileşenler, PCB, kablolar, vb.

NXP'den LPC11C24 de CAN alıcı-vericisine entegre edilmiştir ve ROM'da CANOpen desteklidir (32 K veri Flash'ınızı yemez). LPCXpresso 11c24 kartı 20 EUR'dur (DB9 konektörü için alan sağlamıştır), bu yüzden gerçekten sadece kablolar ekleyin :-)

Başka bir benzer sorudan yanıt alın. İki mikrodenetleyici arasında düşük maliyetli basit iletişim

TLDR : Bazı kullanım durumlarında özellikle ucuz değil, güvenilir uyum.

Kutunun dışına baktığımda, son zamanlarda çarptığım çipi takip etmek gibi başka çözümler de olabilir. Tabii ki, hepsi ne yapmak istediğinize bağlı. UART gibi bir şey, her iki MCU'yu aynı tahtada tuttuğunuzda veya hatta ESD'yi planlıyorsanız, ayrılırsa manuel olarak korursa akla gelir.

IO-Link Uygulamaları için Ana ve Cihaz Çözümü

L6360   Master
L6362A  Device

Böyle bir çözümü ne zaman düşünürdünüz:

1. Sınır yongaları Tamamen korunur ve her MCU'yu ayrı bir kartta bulundurursanız ve açıkta kalan pimlerle, örneğin vidalı terminalle uğraşırsanız önemli olacaktır.
   • Ters kutup
   • Kesme fonksiyonlu aşırı yük
   • Aşırı sıcaklık
   • Düşük gerilim ve aşırı gerilim
   • GND ve VCC açık tel
2. Birlikte çalışabilirlik. Eğer bir başkası diğer tarafı tasarlayacaksa, bilmesi gereken tek şey verileri IO-Link aracılığıyla yönlendirmek.
3. Entegre regülatör Vcc(in) 7~30v, Vdd(out) 3.3/5v

Bana ilginç geldi, ben de oraya koyacağımı düşündüm.

Bu, uygulamanızın ölçeğine ve mikrodenetleyicilere bağlıdır. Atmel minik / mega'den bahsettiniz, oldukça küçükler. Onların durumunda I2C / SPI / UART, donanımda uygulanma avantajına sahiptir ve bu nedenle kullanımı kolaydır.