From OpenSCADAWiki
Jump to: navigation, search
 
Line 1: Line 1:
 
== {{Anch|Notes|Зауваження}} ==
 
== {{Anch|Notes|Зауваження}} ==
Комунікації через послідовні інтерфейси мають низку особливостей. Найбільш важливою особливістю є критерій закінчення повідомлення та час очікування цього критерію. У одних протоколах таким критерієм виступає ознака закінчення або вказаний розмір повідомлення. В інших протоколах таким критерієм є відсутність даних у вхідному потоці протягом вказаного часу — час символу. У обох випадках час очікування критерію, або символу, є ключовим та сильно впливає на загальний час обміну. Відповідно, чим менше цей час тим краще. Тут і виникає проблема латентності обладнання та його драйверів.
+
Комунікації через послідовні інтерфейси мають низку особливостей. Найбільш важливою особливістю є критерій закінчення повідомлення та час очікування цього критерію. У одних протоколах таким критерієм виступає ознака закінчення або вказаний розмір повідомлення. В інших протоколах таким критерієм є відсутність даних у вхідному потоці протягом вказаного часу — час символу. У обох випадках час очікування критерію, або символу, є ключовим та сильно впливає на загальний час обміну і цілісність даних. Відповідно, чим менше цей час тим краще, якщо відсутні втрати хвоста даних. Тут і виникає проблема латентності обладнання та його драйверів.

Latest revision as of 19:27, 17 September 2024

Information about message (contribute)
This message has no documentation. If you know where or how this message is used, you can help other translators by adding documentation to this message.
Message definition (Modules/Serial)
== {{Anch|Notes|Notes}} ==
Communications via the serial interfaces have a number of features. The most important feature is the criterion for the end of the message and the waiting time of this criterion. In some protocols, such a criterion is a sign of the end or the specified message size. In other protocols, such a criterion is no data in the input stream for a specified time — the symbol time. In both cases, the criterion waiting time, or the symbol, is a crucial and strongly affects the overall exchange time and the data integrity. Consequently, the smaller this time, the better if you have no loss the data tail. Here the problem of hardware and its drivers latency happens.
Translation== {{Anch|Notes|Зауваження}} ==
Комунікації через послідовні інтерфейси мають низку особливостей. Найбільш важливою особливістю є критерій закінчення повідомлення та час очікування цього критерію. У одних протоколах таким критерієм виступає ознака закінчення або вказаний розмір повідомлення. В інших протоколах таким критерієм є відсутність даних у вхідному потоці протягом вказаного часу — час символу. У обох випадках час очікування критерію, або символу, є ключовим та сильно впливає на загальний час обміну і цілісність даних. Відповідно, чим менше цей час тим краще, якщо відсутні втрати хвоста даних. Тут і виникає проблема латентності обладнання та його драйверів.

Зауваження

Комунікації через послідовні інтерфейси мають низку особливостей. Найбільш важливою особливістю є критерій закінчення повідомлення та час очікування цього критерію. У одних протоколах таким критерієм виступає ознака закінчення або вказаний розмір повідомлення. В інших протоколах таким критерієм є відсутність даних у вхідному потоці протягом вказаного часу — час символу. У обох випадках час очікування критерію, або символу, є ключовим та сильно впливає на загальний час обміну і цілісність даних. Відповідно, чим менше цей час тим краще, якщо відсутні втрати хвоста даних. Тут і виникає проблема латентності обладнання та його драйверів.