Seri protokol sınırlama / senkronizasyon teknikleri

Asenkron seri iletişim bugünlerde bile elektronik cihazlar arasında yaygın bir şekilde yayıldığı için, zaman zaman çoğumuzun böyle bir soru ile karşılaştığına inanıyorum. Bir elektronik cihaz Dve PCseri hatla bağlı (RS-232 veya benzeri) bir bilgisayarı ve sürekli bilgi alışverişi için gerekli olanları düşünün . Yani PC, her biri bir komut çerçevesi gönderiyor X msve her biri Ddurum raporu / telemetri çerçevesiyle Y msyanıt veriyor (Rapor isteklere yanıt olarak veya bağımsız olarak gönderilebilir - burada gerçekten önemli değil). İletişim çerçeveleri herhangi bir isteğe bağlı ikili veri içerebilir . İletişim çerçevelerinin sabit uzunlukta paketler olduğunu varsayalım.

Sorun:

Protokol sürekli olduğu için, alıcı taraf senkronizasyonu kaybedebilir veya devam etmekte olan bir çerçevenin ortasında sadece "birleştirme" yapabilir, bu nedenle sadece çerçevenin başlangıcının (SOF) nerede olduğunu bilemez. Bir veri, SOF'a göre pozisyonuna bağlı olarak farklı anlamlara sahipse, alınan veriler potansiyel olarak sonsuza dek bozulacaktır.

Gerekli çözüm

SOF'u kısa kurtarma süresiyle tespit etmek için güvenilir sınırlandırma / senkronizasyon şeması (yani, senkronizasyon için 1 kare den daha uzun sürmemelidir).

Şu an bildiğim teknikler (ve bazılarını kullanıyorum):

1) Başlık / sağlama toplamı - önceden tanımlanmış bayt değeri olarak SOF. Çerçeve sonunda sağlama toplamı.

• Artıları: Basit.
• Eksileri: Güvenilir değil. Bilinmeyen iyileşme süresi.

2) Bayt doldurma:

• Artıları: Güvenilir, hızlı kurtarma, herhangi bir donanım ile birlikte kullanılabilir
• Eksileri: Sabit boyutlu çerçeve tabanlı iletişim için uygun değil

3) 9. bit işaretlemesi - her bir baytı ek bit ile hazırlayın, SOF ile işaretli 1ve veri baytları ile işaretlenir 0:

• Artıları: Güvenilir, hızlı kurtarma
• Eksileri: Donanım desteği gerektirir. PCDonanım ve yazılımın çoğu tarafından doğrudan desteklenmez .

4) 8. bit işaretleme - yukarıdakilerin emülasyonu, 9. yerine 8. biti kullanırken, her veri sözcüğü için yalnızca 7 bit bırakıyor.

• Artıları: Güvenilir, hızlı kurtarma, herhangi bir donanım ile birlikte kullanılabilir.
• Eksileri: 7 bitlik gösterime / konvansiyonel 8-bit gösterime / den bir kodlama / kod çözme şeması gerektirir. Biraz savurgan.

5) Zaman aşımı tabanlı - SOF'u belirli bir boşta kalma süresinden sonra gelen ilk bayt olarak kabul edin.

• Artıları: Genel veri yok, basit.
• Eksileri: Bu güvenilir değil. Windows PC gibi zayıf zamanlama sistemleri ile iyi çalışmaz. Potansiyel verimlilik ek yükü.

Soru: Sorunu çözmek için diğer olası teknikler / çözümler nelerdir? Kolayca çalışılabilen yukarıdaki listedeki eksileri işaret edebilir misiniz ? Sistem protokolünüzü nasıl (veya siz) tasarlarsınız?

Sistem protokolünüzü nasıl (veya siz) tasarlarsınız?

Tecrübelerime göre, herkes iletişim sistemlerinde hata ayıklamak istediğinden çok daha fazla zaman harcıyor. Bu yüzden, bir iletişim protokolü için bir seçim yapmanız gerektiğinde, sistemin mümkünse hata ayıklamasını kolaylaştıracak herhangi bir seçeneği seçmenizi şiddetle tavsiye ediyorum.

Birkaç özel protokol tasarlayarak oynamanızı tavsiye ederim - eğlenceli ve çok eğitici. Ancak, önceden var olan protokollere de bakmanızı tavsiye ediyorum. Verileri bir yerden başka bir yere iletmem gerekirse, önceden var olan bir protokolü, başka birisinin zaten hata ayıklamak için harcadığı çok fazla zaman harcamayı denerdim.

Kendi iletişim protokolünüzü sıfırdan yazmak, herkesin yeni bir protokol yazarken yaşadığı sık karşılaşılan sorunların birçoğuna çarpma olasılığı yüksektir.

Bilgisayar İletişimine Gömülü için İyi RS232 Tabanlı Protokollerde listelenen bir düzine gömülü sistem protokolü var - hangisi gereksinimlerinize en yakın olanı?

Bazı durumlar önceden var olan herhangi bir protokolü tam olarak kullanmayı imkansız hale getirmiş olsa bile, neredeyse gereksinimleri karşılayan bir protokolle başlayıp daha sonra ayarlayarak daha hızlı bir şekilde çalışacak bir şey alma ihtimalim daha yüksek.

kötü haber

Daha önce de söylediğim gibi :

Ne yazık ki, herhangi bir iletişim protokolünün tüm bu güzel özelliklere sahip olması mümkün değildir:

• şeffaflık: veri iletişimi şeffaf ve "8 bit temiz" - (a) olası herhangi bir veri dosyası iletilebilir, (b) dosyadaki bayt dizileri her zaman veri olarak işlenir ve asla yanlış bir şey olarak yorumlanmaz ve (c ) hedef, tüm veri dosyasını hatasız, herhangi bir ekleme veya silme olmadan alır.
• basit kopya: paketleri basitçe değiştirmeden paketin veri alanına kör bir şekilde kopyaladığımızda paketleri oluşturmak en kolay yoldur.
• benzersiz başlangıç: paket başlangıcı sembolünün tanınması kolaydır, çünkü başlıklarda, başlık CRC'sinde, veri taşıma yükünde veya veri CRC'sinde asla başka bir yerde bulunmayan bilinen bir sabit bayttır.
• 8 bit: yalnızca 8 bit bayt kullanır.

Bir iletişim protokolünün tüm bu özelliklere sahip olması için herhangi bir yol olsaydı şaşırır ve memnun olurdum.

iyi haberler

Soruna yönelik diğer olası teknikler / çözümler nelerdir?

Genellikle, bir metin terminalindeki bir insan iletişim cihazlarının yerini alabiliyorsa, hata ayıklamayı çok daha kolaylaştırır. Bu, protokolün göreceli olarak zamandan bağımsız olacak şekilde tasarlanmasını gerektirir (bir insan tarafından yazılan tuş vuruşları arasındaki nispeten uzun duraklamalar sırasında zaman aşımına uğramaz). Ayrıca, bu protokoller bir insanın yazması ve sonra ekranda okuması kolay olan baytlarla sınırlıdır.

Bazı protokoller, mesajların "metin" veya "ikili" modda gönderilmesine izin verir (ve tüm olası ikili mesajların aynı anlama gelen "eşdeğer" bir metin mesajı almasını gerektirir). Bu, hata ayıklamayı çok daha kolay hale getirmeye yardımcı olabilir.

Bazı insanlar bir protokolü yalnızca basılabilir karakterleri kullanmak için sınırlandırmanın “israf” olduğunu düşünüyor, ancak hata ayıklama süresindeki tasarruflar çoğu zaman buna değer.

Daha önce bahsettiğiniz gibi, veri alanının başlığın başlangıcı ve başlık sonu baytlarının da dahil olduğu herhangi bir rasgele bayt içermesine izin verirseniz, bir alıcı ilk açıldığında, alıcının açık senkronizasyonu bir paketin ortasındaki veri alanında başlığın başlangıcı (SOH) baytı gibi görünüyor. Genellikle alıcı, sözde paketin sonunda (genellikle ikinci bir gerçek paketin yarısı kadar olan) eşleşmeyen bir sağlama toplamı elde eder. Bir sonraki SOH'yi aramadan önce tüm sözde mesajın (ikinci paketin ilk yarısı dahil) yalnızca atılması çok caziptir - bunun sonucunda alıcı birçok mesaj için senkronizasyondan uzak kalabilir.

Alex.forencich'in belirttiği gibi, alıcının arabellek başlangıcında bir sonraki SOH'ye kadar baytları atması için çok daha iyi bir yaklaşımdır. Bu, alıcının (bu veri paketindeki birkaç SOH byte'ından geçtikten sonra) ikinci paket üzerinde hemen senkronize olmasını sağlar.

Kolayca çalışılabilen yukarıdaki listedeki eksileri işaret edebilir misiniz?

Nicholas Clark'ın belirttiği gibi, tutarlı ek yük byte doldurma (COBS), sabit boyutlu çerçevelerle iyi çalışan sabit bir ek yüke sahiptir.

Genellikle göz ardı edilen bir teknik, özel bir kare sonu marker baytıdır. Alıcı bir iletimin ortasında açıldığında, özel bir kare sonu işaretleyici baytı, alıcının daha hızlı senkronizasyonuna yardımcı olur.

Bir alıcı bir paketin ortasında açıldığında ve bir paketin veri alanı bir paket başlangıcı gibi görünen baytlar içeriyorsa (sözde bir paketin başlangıcı) verici bir seri ekleyebilir bu paketten sonraki kare sonu işaret baytlarının sayısı, böylece veri alanındaki bu tür paket başlangıcı baytları, bir sonraki paketin hemen senkronize edilmesine ve doğru şekilde kodunun çözülmesine engel olmaz - son derece şanssız ve sağlama toplamı Bu sahte paketin doğru görünüyor.

İyi şanslar.

Bayt doldurma programları yıllar boyunca benim için çok iyi çalıştı. Güzeller çünkü yazılım veya donanımda kolayca kullanılabiliyorlar, veri paketleri göndermek için standart bir USB-UART kablosu kullanabilirsiniz ve endişelenmenize gerek kalmadan kaliteli çerçeve elde etme garantiniz vardır. zaman aşımları, çalışırken değiştirme veya bunun gibi bir şey.

Bir uzunluk baytı (paket uzunluğu modulo 256) ve bir paket seviyesi CRC ile birleştirilmiş bir bayt doldurma yöntemini savunacağım ve ardından UART'ı bir parite biti ile kullanacağım. Uzunluk baytı parite biti ile iyi çalışan bırakılan bayt saptamasını sağlar (çünkü çoğu UART parite başarısız olan baytları düşürür). Daha sonra paket düzeyinde CRC size ekstra güvenlik sağlar.

Bayt doldurma yüküne gelince, COBS protokolüne baktınız mı? İletilen her 254 için 1 baytlık sabit bir genel gider yükü ile bayt doldurma işlemi yapmak için dahice bir yoldur (ayrıca çerçevelemeniz, CRC, LEN, vb.).

https://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing

Seçenek # 1, SOH artı sağlama toplamı, güvenilirdir ve bir sonraki bozuk çerçevede kurtarır.

Bir iletinin uzunluğunu zaten bildiğinizi veya uzunluğu SOH'yi hemen takip eden bayt (lar) içinde kodlanmış olduğunu farz ediyorum. Kontrol bayt (lar) mesajın sonunda belirir. Ayrıca, en azından en uzun mesajınız olduğu sürece veriler için bir alıcı tarafı arabellek gerekir.

Tamponun başında bir SOH baytı gördüğünüzde, muhtemelen bir mesajın başlangıcıdır. Bu iletinin onay değerini hesaplamak için arabellek taraması yapar ve arabellek içindeki onay baytlarıyla eşleşip eşleşmediğine bakın. Eğer öyleyse, bitti; Aksi takdirde, bir sonraki SOH baytına gelinceye kadar verileri arabellekten atarsınız.

Bir mesaj aslında veri hatalarına sahipse, bu algoritmanın onu ortadan kaldıracağını unutmayın - ama muhtemelen yine de bunu yapacaktınız. Kontrol algoritmanız ileriye doğru hata düzeltmeyi içeriyorsa, düzeltilebilir hatalar için her bir potansiyel mesaj hizasını kontrol edebilirsiniz.

Mesajlar sabit uzunluktaysa, SOH baytını tamamen verebilirsiniz - geçerli bir kontrol değeri için HER HER olası başlangıç ​​konumunu test edin.

Ayrıca kontrol algoritmasını da bırakabilir ve yalnızca SOH baytını tutabilirsiniz, ancak bu algoritmayı daha az deterministik hale getirir. Buradaki fikir geçerli mesaj hizalamaları için, SOH'un her zaman mesajın başında görüneceğidir. Yanlış bir hizalamanız varsa, veri akışındaki bir sonraki bayt başka bir SOH olma olasılığı düşüktür (SOH'nin mesaj verilerinde ne sıklıkla göründüğüne bağlıdır). Geçerli SOH baytlarını yalnızca bu temelde seçebilirsiniz. (Temel olarak, T1 ve E1 gibi senkron telekom servisleri üzerindeki çerçevelerin çalışması budur.)

Belirtilmeyen ancak yaygın olarak kullanılan seçeneklerden biri (özellikle internette) ASCII / metin kodlamasıdır (aslında çoğu modern uygulama UTF-8'i varsaymaktadır). Tecrübelerime göre, donanım uzmanları bunu yapmaktan nefret ediyorlar, ancak yazılım çalışanları bunu neredeyse her şeyden daha çok tercih etme eğilimindedir (çoğunlukla Unix'in her şeyi metne dayalı yapma geleneği için gelir).

Metin kodlamanın avantajı, çerçeveleme için yazdırılamayan karakterleri kullanabilmenizdir. Örneğin, en basit olanı 0x00çerçevenin başlangıcını ve çerçevenin 0xffsonunu belirtmek gibi bir şey kullanmak olacaktır .

Verilerin metin olarak kodlanmasının iki ana yolunu gördüm:

1. Bir donanım / montaj elemanından bunu yapması istendiğinde, büyük olasılıkla hex kodlaması olarak uygulanacaktır. Bu sadece ASCII'deki baytları onaltılık değerlerine dönüştürüyor. Tepegöz büyük. Temel olarak her gerçek veri baytı için iki bayt iletirsiniz.

2. Bir yazılımcıdan bunu yapması istendiğinde, muhtemelen base64 kodlaması olarak uygulanacaktır. Bu internetin fiili kodlamasıdır. E-posta MIME eklerinden URL veri kodlamasına kadar her şey için kullanılır. Genel gider tam olarak% 33. Basit hex kodlamadan çok daha iyi.

Alternatif olarak, ikili verileri tamamen bırakabilir ve metin iletebilirsiniz. Bu durumda en yaygın teknik, verileri yeni satırla sınırlandırmaktır (sadece "\n"veya "\r\n"). NMEA (GPS), Modem AT komutları ve Adventech ADAM sensörleri bunun en yaygın örneklerinden bazılarıdır.

Tüm bu metin tabanlı protokoller / çerçeveleme aşağıdaki artılara ve eksilere sahiptir:

Pro:

• Hata ayıklamak kolay
• Bir betik dilinde uygulanması kolaydır
• Donanım sadece Hyperterminal / minicom kullanılarak test edilebilir
• Donanım üzerinde uygulanması kolaydır (PIC gibi gerçekten küçük bir mikro değilse)
• Sabit boyutlu çerçeve veya değişken boyutta olabilir.
• Tahmin edilebilir çerçeve oluşturma ve hızlı senkronizasyon kurtarma süresi (geçerli karenin sonunda kurtarır)

con:

• Saf ikili aktarımla karşılaştırıldığında çok büyük ek yük (daha sonra yine metin G / Ç "0", dört bayt 0x00000000 yerine bir bayt (0x30) gönderme sayıları "sıkıştırabilir"
• PIC gibi çok küçük mikroplara uygulamak o kadar temiz değil (kütüphanenizde bir sprintf()işlev yoksa )

Şahsen bana göre artıları eksileri ağır basar. Tek başına hata ayıklama kolaylığı 5 puan olarak sayılır (bu nedenle tek başına tek puan zaten her iki eksiden daha ağır basar).

Öyleyse çoğu zaman yazılımcılardan gelen çok dikkatlice düşünülmeyen çözümler yoktur: çerçevelemeyi düşünmeden kodlanmış veri gönderir.

Geçmişte ham XML gönderen bir donanıma sahip olmak zorunda kaldım. XML orada tüm çerçevelendi. Neyse ki, <xml></xml>etiket sınırlarıyla çerçeve sınırlarını bulmak oldukça kolaydır . Benim için en büyük avantaj, çerçeveleme için birden fazla byte kullanması. Ayrıca, etiket öznitelikler içerebileceğinden <tag foo="bar"></tag>çerçevenin kendisi de sabit olmayabilir: bu nedenle çerçevenin başlangıcını bulmak için en kötü durum için arabelleklemeniz gerekir.

Son zamanlarda insanların JSON'u seri portlardan göndermeye başladığını gördüm. JSON ile çerçeveleme en iyi ihtimalle bir tahmin. Çerçeveyi algılamak için yalnızca "{"(veya "[") karakteriniz vardır, ancak verilerde de bulunurlar. Böylece, çerçeveyi bulmak için özyinelemeli bir iniş ayrıştırıcıya (veya en azından bir ayraç sayacı) ihtiyaç duyarsınız. En azından şu anki çerçevenin zamanından önce bitip bitmediğini bilmek önemsiz: "}{"ya "]["da JSON'da yasadışı ve bu nedenle eski çerçevenin bittiğini ve yeni bir çerçevenin başladığını gösterir.

"X bit biti" olarak tanımladığınız şey, verileri sabit bir kesirle genişletme özelliğine sahip bazı kodlayıcıları sınırlayıcı olarak kullanmak için serbest bırakan başka kodlara genelleştirilebilir. Genellikle bu kodlar başka faydalar da sağlar; CD'ler , her 1 arasında maksimum 0 bit çalışma uzunluğu sağlayan sekiz ila on dört modülasyon kullanır . Diğer örnekler, hata algılama ve düzeltme bilgilerini kodlamak için ek bitler kullanan İleri Hata Düzeltme bloğu kodlarını içerir .

Bahsetmediğiniz bir diğer sistem, işlemleri veya paketleri sınırlamak için yonga seçme satırı gibi bant dışı bilgileri kullanmaktır.

Diğer bir seçenek de satır kodlaması olarak bilinen şeydir . Çizgi kodlaması, sinyale iletimi kolaylaştıran (DC dengeli ve maksimum çalışma uzunluğu garantileri) bazı elektriksel özellikleri verir ve çerçeveleme ve saat senkronizasyonu için kontrol karakterlerini destekler. Çizgi kodlar tüm modern yüksek hızlı seri protokolleri kullanılmaktadır - 10M, 100M, 1G ve 10G Ethernet, seri ATA, FireWire, USB 3, PCIe, vb Ortak hat kodlardır 8b / 10b , 64b / 66b ve 128b / 130b. Ayrıca, çerçeveleme bilgisi sağlamayan, yalnızca DC balansı ve saat senkronizasyonu olan daha basit satır kodları da vardır. Bunların örnekleri Machester ve NRZ'dir. Hızlıca senkronize etmek istiyorsanız, muhtemelen 8b / 10b kullanmak istersiniz; diğer satır kodları acele ile senkronize edilmek üzere tasarlanmamıştır. Yukarıdakileri içeren bir satır kodu kullanmak, iletmek ve almak için özel donanım kullanılmasını gerektirir.

Seçenek 5’e gelince, standart RS232 serisinin, hattın birkaç byte kez boşta kaldığı aralıklarla gönderilmesini ve alınmasını desteklemesi beklenir. Ancak, bu tüm sistemlerde desteklenmiyor olabilir.

Genel olarak, en basit ve en güvenilir çerçeve yöntemi, bir uzunluk alanı ve basit CRC veya sağlama toplamı rutini ile birlikte seçenek 1'dir. Kod çözme yordamı basittir: başlangıç ​​baytı alana kadar baytları atın, uzunluk alanını okuyun, tüm kareyi bekleyin, sağlama toplamını kontrol edin, iyi durumda tutun. Sağlama toplamı bozuksa, başlangıç ​​baytı alıncaya kadar arabellekten baytları atmaya başlayın. Bu tekniğin ana konusu, aslında çerçeve baytının başlangıcı olmayan bir çerçeve baytı başlangıcı bulmaktır. Bu sorunu hafifletmek için, bir teknik, başka bir kontrol karakterine sahip olan çerçeve baytının başlangıcıyla aynı değere sahip baytlardan kaçmak ve ardından kaçak bayt'ı değiştirerek farklı bir değere sahip olmaktır. Bu durumda, aynı şeyi yeni kontrol baytıyla da yapmanız gerekecektir.