А, там еще крутилка размера USB буфера, которая может потребоваться для получения стабильных бОльших скоростей. Я редко выше 57600 использовал, поэтому размер буфера не крутил
Во время передачи, передатчик довольно эффективно давит отражения, успешно как подтягивая вверх так и утаскивая вниз. После передачи он отцепляется от линии возваращя туда приёмник, в итоге на линии становятся все приёмники, то есть никто линию никуда тянет -- и шум начинает влиять. И да, я не думаю, что проблема проявляется на связи точка-точка.
mea culpa, условия в которых проблема встречается, следовало сразу определить...
Гипотетически, такое требование может взяться из необходимости моментального ответа на пришедший байт. Но это мой, несколько надуманный пример, чтобф оправдать наличие двойного стоп-бита.
Логично, но тогда непонятно чем второй стопбит изменит ситуацию -- мы просто меняем шило (разрешение в N бит паузы перед ответом) на мыло (1 бит к каждому входному байту всегда). Но теперь я идею понял :)
Если линия не согласована, да так, что это мешает передаче, то по какой причине её не согласовали?
Да, терминатор на конце линии помогает лучше всего для гарантии. Второй стопбит, который почти все приёмники игнорируют, даёт время избавиться от "звона" от передачи. Для передачи с большим количеством пауз (длинных последовательностей единиц) вообще это никак не помогает, а эксперименты которые мы проводили показывали что 8n2 эффективно подавляет "левый" приём на стороне компа при использовании телефонного кабеля и COM<=>(токовая петля) конвертера. (по осцилографу там всплески где-то в 5% амплитуды были, который MAX радостно конвертировал в нечто более высокое, которое комп распознавал за старт)
При переходе на USB адаптеры лет 10 назад оно осталось уже в форме legacy. Наверное, интересно было бы перепроверить -- есть ли еще польза какая от второго стопа или нет :) Но у меня нет сейчас лабы под руками.
Тогда вообще не складывается. У меги 1 буфер байт + байт который собирается (или это просто 2 байта буфер? давно трогал её). То есть у нас всегда есть время в полный байт на то чтобы забрать байт из входного регистра и свободить его для следующего.
В какой ситуации берётся требование что-то сделать строго за стоп-бит?
И у FTDI и у CP были флаги в реестре которые позволяли поднять частоту поллинга. Если моя память не подтекает, то у FTDI дефолт около 15мс. Я снижал до 3-5мс чтоб получить стабильную связь на больших скоростях с минимальными задержками.
Так UART сам буферизирует 1 символ, даже на 8051, разве нет?
Но буферизация одного символа не помогает, так как через 16 тактов уже следующий символ и затем следующий. То есть тактика работает если можно в 32 такта уложить обработку двух но в 16 одного нет.
Либо я не понимаю о чем идет речь :)
Я в 8051 порой вынужден был потратить 256 байт кода под табличку для упаковки обработки принятого символа чтобы hex2bin и bin2hex делать со всеми проверками максимально дёшево по тактам и ОЗУ -- и использовать буфер половинного объёма, основной поток мог обрабатывать медленно не задерживая коммуникацию в кольце вообще
Это была шутка. Оригинальные разрешения зачастую 8K, даже на 4K его пережимают для экономии канала. Плюс нужны все наборы дальше вниз вплоть до 360p (да, у меня когда wifi удлиннитель задурил -- я видел что netflix реально может до 360p упасть вниз, выглядит жутко)
Таким образом, семейство алгоритмов шифрования Salsa20 потенциально может претендовать на роль надежной и быстрой замены более популярного AES
"Мы берём два числа, складываем их. Таким образом, семейство алгоритмов сложения потенциально может претендовать на роль надежной и быстрой замены всех шифров мира."
Я должен заметить, что это нечестно -- статья в PVS-Studio блоге о каком-то продукте БЕЗ проверки этого продукта!
Какие законы?!?
Да даже fizzbuzz можно вывернуть
как правило -- любая тема может быть супер сложной...
просто если ты в ней уже разобрался -- она внезапно перестаёт такой быть =))
Чтобы путать причину и следствие надо знать что оба события взаимосвязаны именно одино с другим, а не оба являются следсвиями чего-то третьего.
https://xkcdsw.com/2274 для этого стрипа особенно чудесен:
Да, заряд надо смотреть на них самих при этом..
А разве литиевые нынче не на 1.5 вольта в том же габарите, так что всё прям красивое?
На линуксе тоже: https://granitedevices.com/wiki/FTDI_Linux_USB_latency
А, там еще крутилка размера USB буфера, которая может потребоваться для получения стабильных бОльших скоростей. Я редко выше 57600 использовал, поэтому размер буфера не крутил
Во время передачи, передатчик довольно эффективно давит отражения, успешно как подтягивая вверх так и утаскивая вниз. После передачи он отцепляется от линии возваращя туда приёмник, в итоге на линии становятся все приёмники, то есть никто линию никуда тянет -- и шум начинает влиять. И да, я не думаю, что проблема проявляется на связи точка-точка.
mea culpa, условия в которых проблема встречается, следовало сразу определить...
Логично, но тогда непонятно чем второй стопбит изменит ситуацию -- мы просто меняем шило (разрешение в N бит паузы перед ответом) на мыло (1 бит к каждому входному байту всегда). Но теперь я идею понял :)
Да, терминатор на конце линии помогает лучше всего для гарантии. Второй стопбит, который почти все приёмники игнорируют, даёт время избавиться от "звона" от передачи. Для передачи с большим количеством пауз (длинных последовательностей единиц) вообще это никак не помогает, а эксперименты которые мы проводили показывали что 8n2 эффективно подавляет "левый" приём на стороне компа при использовании телефонного кабеля и COM<=>(токовая петля) конвертера. (по осцилографу там всплески где-то в 5% амплитуды были, который MAX радостно конвертировал в нечто более высокое, которое комп распознавал за старт)
При переходе на USB адаптеры лет 10 назад оно осталось уже в форме legacy. Наверное, интересно было бы перепроверить -- есть ли еще польза какая от второго стопа или нет :) Но у меня нет сейчас лабы под руками.
Тогда вообще не складывается. У меги 1 буфер байт + байт который собирается (или это просто 2 байта буфер? давно трогал её). То есть у нас всегда есть время в полный байт на то чтобы забрать байт из входного регистра и свободить его для следующего.
В какой ситуации берётся требование что-то сделать строго за стоп-бит?
Стоп. Мы говорим о 16 тактов на БИТ а не 16 тактов на БАЙТ?
И у FTDI и у CP были флаги в реестре которые позволяли поднять частоту поллинга. Если моя память не подтекает, то у FTDI дефолт около 15мс. Я снижал до 3-5мс чтоб получить стабильную связь на больших скоростях с минимальными задержками.
https://www.ftdichip.com/Support/Knowledgebase/index.html?settingacustomdefaultlaten.htm
16ms дефолт. На 1-2 становилось хуже, а на 3-5 сильно лучше при обмене
Так UART сам буферизирует 1 символ, даже на 8051, разве нет?
Но буферизация одного символа не помогает, так как через 16 тактов уже следующий символ и затем следующий. То есть тактика работает если можно в 32 такта уложить обработку двух но в 16 одного нет.
Либо я не понимаю о чем идет речь :)
Я в 8051 порой вынужден был потратить 256 байт кода под табличку для упаковки обработки принятого символа чтобы hex2bin и bin2hex делать со всеми проверками максимально дёшево по тактам и ОЗУ -- и использовать буфер половинного объёма, основной поток мог обрабатывать медленно не задерживая коммуникацию в кольце вообще
Вы про тот, который сжимает что угодно до одного байта?
Только алгоритм расжатия придумать осталос
Это была шутка. Оригинальные разрешения зачастую 8K, даже на 4K его пережимают для экономии канала. Плюс нужны все наборы дальше вниз вплоть до 360p (да, у меня когда wifi удлиннитель задурил -- я видел что netflix реально может до 360p упасть вниз, выглядит жутко)
Планшеты, телефоны, CRT мониторы VGA...
То есть таки используется **циклическое смещение** aka поворот.
"Мы берём два числа, складываем их. Таким образом, семейство алгоритмов сложения потенциально может претендовать на роль надежной и быстрой замены всех шифров мира."