Как Вы обрабатываете большую передачу данных на очень ограниченной памяти, встроенные системы?
После некоторых исследований я обнаружил, что моя Oraganization использует McAfee VirusScan Enterprise. Задача «Защита доступа» имеет определяемое пользователем правило как Cryptolocker - расширение, защищенное , которое блокирует создание этой папки.
Я нашел больше информации об этом здесь: https://kc.mcafee.com/corporate/index?id=KB50998&page=content&pmv=print
4 ответа
Я сделал бы что-то как рассеяние, собираются на ПК. Создайте связанный список структуры как это:
typedef struct data_buffer {
char flags;
char[128] data;
}
Имейте один из битов в среднем "ReadyToFlash" флага и один для "Высвечивания". Необходимо смочь настроить количество буферов в связанном списке, чтобы помешать флэш-памяти ловить UART, как это пишет или наоборот.
Если флэш-память добирается до буферного блока, который не является "ReadyToFlash", который она остановила бы, и у Вас должен будет быть свой IRQ UART, запускаются, она создает резервную копию. Если UART добирается до блока, который является "ReadyToFlash", или "Высвечивание" его заполняется слишком быстро, и Вам, вероятно, нужен другой буфер, если у Вас есть динамическая память, Вы могли бы сделать эту настройку во времени выполнения и добавить буфер к списку на лету, иначе необходимо будет просто сделать некоторое эмпирическое тестирование.
Это точно, для чего было создано управление потоком, я знаю, что это - огромная настроенная боль, но если бы Вы включаете управление потоком на последовательной линии, Вашими проблемами была бы история.
Я предполагаю, что Вы передаете двоичный файл, таким образом, XON-XOFF не является лучшим решением, которое оставляет аппаратное управление потоками.
Другая опция состоит в том, чтобы использовать протокол со встроенным управлением потоком, таким как XModem. У меня есть подобный встроенный проект, где флэш-память записана на 128-байтовых страницах. Какое совпадение, что XModem отправляет данные в 128-байтовых блоках затем, ожидает ACK, прежде чем это отправит следующее.
UART и сторона ПК поддержки приложений RS-232, квитирующий (управление потоком)? Если так, когда Ваш получать буфер рядом с тем, чтобы быть полным, имейте отбрасывание ISR строка CTS - если сторона ПК настроена для уважения аппаратного управления потоками, это должно прекратить отправлять, когда это видит это условие. После того как Вы высушили (или почти высушили), получить буфер, утверждайте CTS снова, и ПК должен начать отправлять снова.
Обратите внимание, что это делает программное обеспечение на встроенном устройстве значительно более сложным - является ли это компромиссом, который Вы готовы сделать, должен был бы быть анализ, сделанный Вами и Вашим менеджером и командой.
Не уверенный, что я пропускаю здесь, но если факт - то, что средняя скорость данных, прибывающих из ПК, выше, чем средняя скорость, которую можно записать этому во флэш-память, затем Вы или испытываете необходимость в большом количестве RAM, или Вы испытываете необходимость в управлении потоком.
Но Вы говорите, что это работало, когда у Вас были буферы блоков, но теперь, когда у Вас есть буферы байта, которые это не делает?
Можно ли придерживаться буферов блоков, которые заполнены прерыванием RX UART, и когда каждый буфер полон, передайте его к коду SPI/Flash для освобождения того буфера с помощью прерывания SPI? Это сохранит Вас копирующий каждый байт, и вместо того, чтобы иметь необходимость сделать логику кольцевого буфера дважды для каждого байта, необходимо будет только сделать это для каждого блока.