а в сумме

Сомтри. Давай допустим, что мне надо в случайном порядке пройтись по всем ключам. Т.к. порядок не последовательный, то надо будет пересчитывать суммы заново

не, допустим тебе надо дернуть адрес строки 1012

тогда у тебя 4048 циклов на получение

или 5000 раз в секунду

на частоте 20МГц

не, допустим тебе надо дернуть адрес строки 1012

Для адреса строки 1012 надо посчитать 1011 сумм, так?

1012

прибавить адрес массива еще

1012 сумм

сумма за такт

Сомтри. Давай допустим, что мне надо в случайном порядке пройтись по всем ключам. Т.к. порядок не последовательный, то надо будет пересчитывать суммы заново

Значит для всего массива кол-во сумм будет »> sum(range(1,1013)) 512578

наврал

у тебя же 2 байта смещение

тогда 2 такта на сумму

Ага. И 512578 сумм чтобы пройтсь по всему массиву длин не по порядку, так?

нет

пересчитай

5 тактов * 1012

Это чтобы последний адрес получить

да

Чтобы предпоследний 5 * 1011

Пред пред последний 1010

да

1 + 2 + ... + 1011 + 1012 = 512578

512578 * 5 это кол-во тактов чтобы обойти все ключи не по порядку

НА 5 УМНОЖ КАЖДОЕ

а епт

1 + 2 + ... + 1011 + 1012 = 512578

Да я не такты тут пишу, а кол-во сумм)

короче получается 8 раз в секунду при 20МГц

короче получается 8 раз в секунду при 20МГц

8 раз что?

8 раз что?

8 раз посчитать все успеет

с загрузками и сложениями

за 1 секунду

это без учета чтения и сравнения строк, не забывай

512578*5 тактов пройдет за секунду 8 раз, так?

только адрессации

да

Тогда достаточно быстро. Супер

это если у тебя мега на 20МГц работает

обычно там 16 или 12

это без учета чтения и сравнения строк, не забывай

Мне строки сравнивать не надо, только ключи

обычно там 16 или 12

Ну такого плохого случая (512578*5) никогда не будет, так что все супер

ну смотри - загрузка ключа (3 байта) выполнится за 9 тактов + сравнения

Ну такого плохого случая (512578*5) никогда не будет, так что все супер

верно

твоя задача уместить свой код в 10-12 кб

тогда ты поместишься массивом во внутреннюю флэш

Хорошо, спасибо большое!

Всем спасибо

?

Это же не третья ревизия?

Хорошо, спасибо большое!

а еще, ты можешь сначала в одну сторону считать смещения, а на следующем этапе поиска - в обратную, тебе это увеличит производительность

Да. Точно

а еще, ты можешь сначала в одну сторону считать смещения, а на следующем этапе поиска - в обратную, тебе это увеличит производительность

Надо только еще адрес конца этого массива хранить

да, не получится )

Почему?

потому что у тебя хеши вразнобой

если отсортируешь, можно критерием определять в какой половине искать

сначала или с конца

тогда да - получится

но тогда нужно не адрес конца хранить

а сумму всех строк

адрес конца известен

твоя задача уместить свой код в 10-12 кб

Вот это кстати уже искусство программирования))

+

ERROR: S client not available

потому что у тебя хеши вразнобой

Какие хеши? Ключи?

да

отсортируй по возрастанию

найди середину ;)

Ну вообще сортированные по возрастанию, но не вижу связи между тем сортированные ли они и получится ли это реализовать

найди середину ;)

А. Середина

Понял

ты знаешь в какой половине ключ

и ищешь сначала или с конца

Бинарный поиск реализовать можно

Или нет..

Не, нельзя

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

памяти на дерево хватит то? ))

схемы железячки нет, потому что проприетарщина

найди середину ;)

Ну да. Адрес ключа по середине запомнить и все отлично будет

не адрес

а вес

один из тестпойнтов подписан 3V3 - там всегда будет 3.3 или это могут быть тупо для прошивки пины?

сравниваешь искомый ключ с серединой

а вес

????

если больше - ищешь с конца

сравниваешь искомый ключ с серединой

Смотреть, если больше этого ключа, то с конца

Вес?

если меньше - сначала

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

если меньше - сначала

Да, это понятно

Почему вес? Адрес же

ну значение

ясно, я чот не в тему спросил

А. Точно

НЕ АДРЕС