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

[pvvx]

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

 

[pvvx]

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

 

[pvvx]

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

 

[cheblin]

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

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

 

[A_D]

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

 

[cheblin]

протоколы, бывает,

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

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

 

[pvvx]

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

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

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

 

[pvvx]

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

С теоретической стороны надо было начинать с того, что минимальная единица – это бит и задавать их кол-во для атомарного блока обмена, и динамически. А счас у вас байтовая ерунда, да с неизвестным порядком бит в нем

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

Как же вас задевают чужие успехи. На этом и поиграем

 

[cheblin]

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

начинай.

 

[pvvx]

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

 

[pvvx]

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

начинай.

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

 

[pvvx]

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

 

[pvvx]

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

 

[pvvx]

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

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

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

 

[pvvx]

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

 

[pvvx]

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

 

[A_D]

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

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

Как можно видеть, шина 24 бита, а данные - байты. Да, это очень простые случаи можно сказать, но наглядно показывающие, что если за 1 такт\проход\запрос можно передавать больше 1 байта в железе\шине\интерфейсе - обязательно стараются это делать.

 

[A_D]

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

А как же вот эти режимы ?

 

[cheblin]

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

 

[pvvx]

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

Ух ты... Для AdHoc уже оказывается нужно своё железо. Приплыли...