Хранение больших целых чисел / значений во встроенной системе - PullRequest
3 голосов
/ 26 декабря 2011

Я разрабатываю встроенную систему, которая может тестировать большое количество проводов (до 360) - по сути, система проверки непрерывности. Система работает путем синхронизации тестового вектора и считывания выходных данных с другого конца. Выходные данные затем сравниваются с сохраненным результатом (который будет на SD-карте), который сообщает, каким должен был быть вывод . Тестовые векторы - просто ходячие, поэтому нет необходимости хранить их где-либо. Процесс будет выглядеть примерно так:

  1. Контрольный вектор выхода (ходячие)
  2. Считать в выходной тест-вектор.
  3. Считать соответствующий выходной тест-вектор с SD-карты, который сообщает, каким должен быть выходной вектор.
  4. Сравните тестовые векторы из шагов 2 и 3.
  5. Запишите ошибки / неисправности в отдельный массив.
  6. Вернитесь к шагу 1, если не проверены все провода.
  7. Вывод ошибок / неисправностей на ЖК-дисплей.

Мое оборудование состоит из большого сдвигового регистра, который синхронизирован с микроконтроллером AVR. Для каждого тестового вектора (который также будет 360-битным) мне нужно будет прочитать 360-битный. Таким образом, для 360 проводов общий объем данных будет 360 * 360 = 16 КБ или около того. Я уже знаю, что не могу сделать это за один проход (то есть прочитать все данные, а затем сравнить), поэтому это должен быть вектор-тест по вектору-тестом.

Поскольку нет внутренних типов, которые могут содержать такие большие числа, я намерен использовать массив битов длиной 360 бит. Теперь мой вопрос: как мне сохранить этот битовый массив в текстовом файле?

Один из способов - хранить необработанные значения, то есть в каждой строке сохранять необработанные двоичные данные, которые я считывал из регистра сдвига. Итак, для 8 проводов это будет 0b10011010. Но это может быть уродливо для до 360 проводов - каждая строка будет содержать 360 байтов.

Другим способом является сохранение шестнадцатеричных значений - это будет просто два символа для 8 бит (9А для вышеупомянутого) и около 90 символов для 360 бит. Это, однако, потребовало бы от меня чтения текста - строка за строкой - и каким-то образом преобразовать шестнадцатеричное значение для представления в битовом массиве.

Так что же является лучшим решением для такого рода проблем? Мне нужно, чтобы решение было полностью «детерминированным» - у меня не может быть вызовов malloc или чего-то подобного. Они в какой-то степени не встроены в то, что я читал.

РЕЗЮМЕ

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

1 Ответ

6 голосов
/ 26 декабря 2011

Это не целочисленные значения, а битовые карты; они не имеют арифметического значения. То, что вы предлагаете, - это просто байтовый массив длиной 360/8, который вообще не связан с «большими целыми числами». Однако возможна некоторая более подходящая структура данных или представление.

Если тестовый вектор представляет собой одиночный бит на 360, тогда неэффективно и нет необходимости хранить 360 битов для каждого вектора, значение от 0 до 359 достаточно для однозначного определения каждого вектора. Если правильный вывод также является одним битом, то он также может быть сохранен как битовый индекс, если нет, то вы можете сохранить его как список индексов для каждого бита, который должен быть установлен, с некоторым значением часового значения> = 360 или < 0, чтобы указать конец списка. Там, где большинство векторов содержат менее 22 установленных битов, эта структура будет более эффективной, чем хранение 45-байтового массива.

Из любого значения индекса бита вы можете определить адрес и маску отдельного провода по:

byte_address = base_address + bit_index / 8 ;
bit_mask = 0x01 << (bit_index % 8) ;

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

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

...