Делюсь опытом Power Profiler на рельсах AdHoc protocol

pvvx

Активный участник сообщества
Причина давно выявлена – вы не вникаете в то, что вам пишут. Только лепите бессмысленные фразы в ответ, выдергивая из контекста и не вникая в суть. Это и называется "креативный фантазер боксер, смывающийся как доходит до дела".
Но гляжу, что в течении полугода всё-таки усвоили что ваш UART не является, как ранее, опорой для рекламы фантазии про AdHoc. Пройдет ещё время, как и писал – до Нового Года, когда вы сделаете ещё один шаг. Но это очень медленно.
 

pvvx

Активный участник сообщества
И на этом я вам напомню – процессоры не работают с “байтами”, а работают со словами из бит, и ныне обычно из 64-х. Значит ваш протокол не годится и не оптимизирован для текущей аппаратуры, где атомарная единица может иметь сотни и тысячи бит… Даже в древнем Modbus атомарная единица имеет размер до 256*8 бит :p
 

pvvx

Активный участник сообщества
Про то, что AdHoc зародился у вас в процессе изучения STM8 уже наслышаны :)
Пора бы двигаться дальше, а не слыть программером без технических знаний.
 

cheblin

Member
банщик, совсем кукуха отлетела?

причём тут размерность шины проца, когда AdHoc это прежде всего протокол, где минимальная еденица передачи байт.
 

A_D

Active member
Даже протоколы, бывает, оптимизируют под железо, что бы они использовали его максимально эффективно, не полагаясь на минимальную единицу передачи по интерфейсу какому-либо (это бит, к слову).
 

cheblin

Member
протоколы, бывает,
на практике я вижу обратное.
железо подкорячивается под протокол. под USB например.

хотелось бы, для расширения кругозора, посмотреть пример, подтверждающий ваше утверждение. поделки банщика плиз, не предлагать.
 

pvvx

Активный участник сообщества
банщик, совсем кукуха отлетела?

причём тут размерность шины проца, когда AdHoc это прежде всего протокол, где минимальная еденица передачи байт.
А где и у какого современного физического интерфейса единица передачи байт?
Ваше занятие абстракциями с креативными западными клоунами уже сказывается - лезете туда, где у вас нет знаний.
Межпроцессорный обмен так-же не в байтах.
 

pvvx

Активный участник сообщества
В итоге вся ваша проделанная работа насмарку, т.к. будет ужасно тормозить в реальном применении.

С теоретической стороны надо было начинать с того, что минимальная единица – это бит и задавать их кол-во для атомарного блока обмена, и динамически. А счас у вас байтовая ерунда, да с неизвестным порядком бит в нем :)
хотелось бы, для расширения кругозора, посмотреть пример, подтверждающий ваше утверждение. поделки банщика плиз, не предлагать.
Как же вас задевают чужие успехи. На этом и поиграем :p
 

cheblin

Member
ща банщик расскажет как будет передавать 3 бита по Buetooth/ethernet не передавая байта.

начинай.
 

pvvx

Активный участник сообщества
C UART расстались, но забыли что у UART есть режим в 9 бит, да и как с I2C и SPI? Там порядок бит данных разный у разных чипов и Индиана Джонс вам не поможет :p
 

pvvx

Активный участник сообщества
ща банщик расскажет как будет передавать 3 бита по Buetooth/ethernet не передавая байта.

начинай.
Элементарно - читайте описание протокола фрейма приема-передачи. Это вам не игра от ваших креативных клоунов по достройке их неработающей игры.
 

pvvx

Активный участник сообщества
И уж лучше вы нам расскажите, как современный проц будет вычитывать байт по своей шине в сотне бит :)
Если не смыслите в технике, то плодите свой overhead дальше... Он у вас на каждом этапе и минимальной команде кода AdHoc.
Выкиньте фразу про скорость из своего AdHoc и добавьте - самый тормозной протокол.
 

pvvx

Активный участник сообщества
Вам уже давно указали, что по безграмотности вы пишите какую-то абстракцию не применимую на практике. Не учитывая даже минимальную теорию, а гоня отсебятину про какие-то "байты". Обычно это называют игрой или забавой. Забавляйтесь дальше сами, пока не осмыслите указанное.
 

pvvx

Активный участник сообщества
Ждем элементарного примера сравнения скорости передачи и получения простого текстового файла через AdHoc и сжатого пусть gzip. Так само собой давно происходит в простом HTTP.

Когда это продемонстрируете, тогда и пишите что у ваш протокол является скоростным :)

А до этого ваша комкание в 8 бит будет сжиматься gzip и передаваться по сети. И у gzip свой атомарный байт - в несколько тысяч бит :p И как итог AdHoc нафиг там не сдался.
 

pvvx

Активный участник сообщества
По настоянию креативного клоуна следующим этапом будем дописывать SSD побайтно, чтобы он побыстрее перешел в режим read-only :)
И c USB мы тоже не будем оптимизировать блок на размер передачи и на USB2.0 получим великий трансфер в AdHoc до 1000 байт в сек...
 

pvvx

Активный участник сообщества
Креативный клоун обещал описать сферу применения AdHoc. Но, как оказалось, что в современном мире её просто нет, кроме как игры в эту игру. :p
 

A_D

Active member
хотелось бы, для расширения кругозора, посмотреть пример, подтверждающий ваше утверждение. поделки банщика плиз, не предлагать.
Как самый простой вариант - это мой же CV Meter, где я протокол передачи замеров подогнал под ограничения USB в 64 байта, что бы максимально занять report полезными данными (хотя в самом протоколе, точнее банально структуре пакета, есть проблемы, те же довольно избыточные метки времени для каждого замера, о которых вы писали ранее).
А если смотреть прям на железяки - то те же шины Avalon Stream, VIP в ПЛИС - протокол передачи по ним того же потокового видео оптимизирован так, что бы максимально забивать шину данными (более того, в VIP - без задержки в 1 такт на чтение sof):
1584797411347.png
Как можно видеть, шина 24 бита, а данные - байты. Да, это очень простые случаи можно сказать, но наглядно показывающие, что если за 1 такт\проход\запрос можно передавать больше 1 байта в железе\шине\интерфейсе - обязательно стараются это делать.
 

cheblin

Member
ну, так для чего вы мне приводите подтверждение моего же тезиса что жедезо подгоняют под протокол. USB в данном случае, а не наоборот.
вот есть спецификация USB и пофиг на то, чё у тебя там за железо и какой разрядности проц.
 
Сверху Снизу