а вообще sharik_28.05 - твои сообщения в ветке показывают, что у тебя очень слабая база знания С/С++. Пока ты не выучишь базовые понятия - массивы, строки, ссылки - ты нифига не напишешь, у тебя все время будет ерунда получаться.
Ок, тогда вариант для чайников - разбиваешь свою строчку из 13 символов на две, скажем первые 6 символов и последующие семь. Преобразуешь каждую строчку в лонг(стандартной функцией ардуино) и записываешь в ЕЕПРОМ как два лонга опять же стандартной функцией put() Два лонга займут ровно столько же, как uint64_t. так что в обьеме ты не потеряешь, а программа для новичка будет проще.
а зачем хранить ключ, когда можно хранить сигнатуру, к примеру в intе )))
Что такое сигнатура?
слепок ключа в сжатом цифровом виде, вам надо хранить всего 100 ключей, при этом в переменной типа uint16_t мы можем хранить цифры до 65536, вот эти сигнатуры и хранить, у вас же не на спец объект допуск, ну не нравится int храните в long (4 байта) ...
а главное - зачем? с какой целью, когда можно работать с числами...
я бы сделал так:
1. Получил ID ключа в формате int (1/655) думаю этого достаточно
2. Сохранил его в память в первую свободную ячейку
3. Проделал бы это со всеми остальными
4. Запустил механизм сортировки ключей
5. Пересохранил в EEPROM
6. Написал бы процедуру быстрого поиска в EEPROM (любой из семи способов, что я знаю), в предварительно сортированном списке хорошо работает шейкерная сортировка к примеру, да и метод половинного деления здесь будет неплох и, при обработке ключа, будем искать есть ли такой в базе
7. Работаем, считываем ключ, идентифицируем, сравниваем с базой сохранённых, отрабатываем, РЕСПЕКТ
вот 100500 следующим вопросом связанным с обработкой ключа будет, что медленно работает )))
PS sharik_28.05 - я не настоящий сталевар, щас настоящие подскажут...
Вся проблема высосана из пальца.
Во первых неясно почему ключ на 40 бит.
Во вторых абсолютно неважно сколько бит ключ.
Тупо массив из нужного количества 5 байтных ключей. Читаем с пропуска первые 5 байт в другой массив и сравниваем побайтно оба.
Стринг тут точно нафиг не нужен, как и переменные uint64_t
я бы сделал так:
1. Получил ID ключа в формате int (1/655) думаю этого достаточно
2. Сохранил его в память в первую свободную ячейку
3. Проделал бы это со всеми остальными
4. Запустил механизм сортировки ключей
5. Пересохранил в EEPROM
я бы чуть поправил
1. ключики храним целиком, разбив каждый на 2 части - H_KEY и L_KEY
4. делаем по H_KEY сортированный индекс, который размещаем в свободной части ЕЕПРОМ. Другой вариант - генерить индекс в сетапе при каждом старте и размещать в оперативке - всего-то 100 байт
Индекс избавляет от необходимости пересохранять все ключи в ЕЕПРОМ при добавлении новых карточек
Тупо массив из нужного количества 5 байтных ключей. Читаем с пропуска первые 5 байт в другой массив и сравниваем побайтно оба.
только пять байт? Или если нашли первые пять байт - проверяем следующие пять и так далее?
Если только пять - то это супер ненадежно, так как карточки могут иметь различие, например, только в последнем байте.
Если последовательно - то не вижу. чем это отличается от варианта выше с разбиением ключа на две половинки.
Да ему нужна СКУД.
100пропусков, с уникальным ключом.
13 знаков дают некие 10байт информации(все что меньше, влезет в 8-9байт, а ему нужно именно 13 значное число)
Как и откуда он их читает это уже его дело.
Так самое правильное и будет считать эти 5байт в массив uint8_t, а потом этот массив сравнивать в цикле с массивом значений ключей.
Он то ли от дурости, то ли от недостатка знаний, решил использовать String.
Конечно, хозяин-барин, но зачем дуракам то потакать ?
я бы сделал так:
1. Получил ID ключа в формате int (1/655) думаю этого достаточно
2. Сохранил его в память в первую свободную ячейку
3. Проделал бы это со всеми остальными
4. Запустил механизм сортировки ключей
5. Пересохранил в EEPROM
я бы чуть поправил
1. ключики храним целиком, разбив каждый на 2 части - H_KEY и L_KEY
4. делаем по H_KEY сортированный индекс, который размещаем в свободной части ЕЕПРОМ. Другой вариант - генерить индекс в сетапе при каждом старте и размещать в оперативке - всего-то 100 байт
Индекс избавляет от необходимости пересохранять все ключи в ЕЕПРОМ при добавлении новых карточек
Хосспади! Зачем! Все это может иметь смысл если мы храним десятки тысяч и более записей. Для 100 записей простой побайтный перебор прямо из EEPROM работает мнгновенно с точки зрения юзера.
а вообще sharik_28.05 - твои сообщения в ветке показывают, что у тебя очень слабая база знания С/С++. Пока ты не выучишь базовые понятия - массивы, строки, ссылки - ты нифига не напишешь, у тебя все время будет ерунда получаться.
Со стринг мне легко работать, для этого она наверно и создана, для ленивых.
И тут я совсем ничего не понял...
Ок, тогда вариант для чайников - разбиваешь свою строчку из 13 символов на две, скажем первые 6 символов и последующие семь. Преобразуешь каждую строчку в лонг(стандартной функцией ардуино) и записываешь в ЕЕПРОМ как два лонга опять же стандартной функцией put() Два лонга займут ровно столько же, как uint64_t. так что в обьеме ты не потеряешь, а программа для новичка будет проще.
Что за функция String to long? Ткните пожалуйста
а зачем хранить ключ, когда можно хранить сигнатуру, к примеру в intе )))
а зачем хранить ключ, когда можно хранить сигнатуру, к примеру в intе )))
Что такое сигнатура?
String to Unsigned long integer
1char**pointer, *stringVar;2unsignedlongunsignedVar;3stringVar ="324234g";4unsignedVar =strtoul(stringVar,pointer,10);//=324234Написано String to long, а по факту char, почему?
Потомушто: https://en.wikipedia.org/wiki/Null-terminated_string
Написано String to long, а по факту char, почему?
я уже писал почему - потому что "твои познания в С/С++ очень слабы...."
Блин, может все-таки начнешь чему-нибудь учиться?
а зачем хранить ключ, когда можно хранить сигнатуру, к примеру в intе )))
Что такое сигнатура?
слепок ключа в сжатом цифровом виде, вам надо хранить всего 100 ключей, при этом в переменной типа uint16_t мы можем хранить цифры до 65536, вот эти сигнатуры и хранить, у вас же не на спец объект допуск, ну не нравится int храните в long (4 байта) ...
как взять - к примеру CRC16 или CRC32
Со стринг мне легко работать,
Со стринг мне легко работать,
а главное - зачем? с какой целью, когда можно работать с числами...
я бы сделал так:
1. Получил ID ключа в формате int (1/655) думаю этого достаточно
2. Сохранил его в память в первую свободную ячейку
3. Проделал бы это со всеми остальными
4. Запустил механизм сортировки ключей
5. Пересохранил в EEPROM
6. Написал бы процедуру быстрого поиска в EEPROM (любой из семи способов, что я знаю), в предварительно сортированном списке хорошо работает шейкерная сортировка к примеру, да и метод половинного деления здесь будет неплох и, при обработке ключа, будем искать есть ли такой в базе
7. Работаем, считываем ключ, идентифицируем, сравниваем с базой сохранённых, отрабатываем, РЕСПЕКТ
вот 100500 следующим вопросом связанным с обработкой ключа будет, что медленно работает )))
PS sharik_28.05 - я не настоящий сталевар, щас настоящие подскажут...
Вся проблема высосана из пальца.
Во первых неясно почему ключ на 40 бит.
Во вторых абсолютно неважно сколько бит ключ.
Тупо массив из нужного количества 5 байтных ключей. Читаем с пропуска первые 5 байт в другой массив и сравниваем побайтно оба.
Стринг тут точно нафиг не нужен, как и переменные uint64_t
только пять байт? Или если нашли первые пять байт - проверяем следующие пять и так далее?
Если только пять - то это супер ненадежно, так как карточки могут иметь различие, например, только в последнем байте.
Если последовательно - то не вижу. чем это отличается от варианта выше с разбиением ключа на две половинки.
я бы сделал так:
1. Получил ID ключа в формате int (1/655) думаю этого достаточно
2. Сохранил его в память в первую свободную ячейку
3. Проделал бы это со всеми остальными
4. Запустил механизм сортировки ключей
5. Пересохранил в EEPROM
я бы чуть поправил
1. ключики храним целиком, разбив каждый на 2 части - H_KEY и L_KEY
4. делаем по H_KEY сортированный индекс, который размещаем в свободной части ЕЕПРОМ. Другой вариант - генерить индекс в сетапе при каждом старте и размещать в оперативке - всего-то 100 байт
Индекс избавляет от необходимости пересохранять все ключи в ЕЕПРОМ при добавлении новых карточек
...или припаять микросхему EERAM - 47C16 ;)
только пять байт? Или если нашли первые пять байт - проверяем следующие пять и так далее?
Если только пять - то это супер ненадежно, так как карточки могут иметь различие, например, только в последнем байте.
Если последовательно - то не вижу. чем это отличается от варианта выше с разбиением ключа на две половинки.
Да ему нужна СКУД.
100пропусков, с уникальным ключом.
13 знаков дают некие 10байт информации(все что меньше, влезет в 8-9байт, а ему нужно именно 13 значное число)
Как и откуда он их читает это уже его дело.
Так самое правильное и будет считать эти 5байт в массив uint8_t, а потом этот массив сравнивать в цикле с массивом значений ключей.
Он то ли от дурости, то ли от недостатка знаний, решил использовать String.
Конечно, хозяин-барин, но зачем дуракам то потакать ?
...или припаять микросхему EERAM - 47C16 ;)
уж проще тогда SQL сервачок развернуть, на каком-нибудь TP-LINK
я бы сделал так:
1. Получил ID ключа в формате int (1/655) думаю этого достаточно
2. Сохранил его в память в первую свободную ячейку
3. Проделал бы это со всеми остальными
4. Запустил механизм сортировки ключей
5. Пересохранил в EEPROM
я бы чуть поправил
1. ключики храним целиком, разбив каждый на 2 части - H_KEY и L_KEY
4. делаем по H_KEY сортированный индекс, который размещаем в свободной части ЕЕПРОМ. Другой вариант - генерить индекс в сетапе при каждом старте и размещать в оперативке - всего-то 100 байт
Индекс избавляет от необходимости пересохранять все ключи в ЕЕПРОМ при добавлении новых карточек
Хосспади! Зачем! Все это может иметь смысл если мы храним десятки тысяч и более записей. Для 100 записей простой побайтный перебор прямо из EEPROM работает мнгновенно с точки зрения юзера.