esaulenka

Здесь написано "мы официально заявляем, что ничего делать для поддержки не будем. Счастья вам, здоровья, держитесь там". Буквально сообщением ниже расписаны танцы с бубнами, как подменить библиотеки на сторонние, чтобы оно заработало. И, наверное, оно таки работает. Проверять не на чем. Воспоминания 10-летней давности о PC-осциллографе веллеман, который у нас в институте стоял, какие-то нехорошие остались. Хотя я тогда был совсем маленький и глупый... А виртуалка - штука хорошая, конечно. Но, боюсь, задача "обеспечить максимально прозрачный и быстрый доступ к LPT" для авторов виртуалок не является приоритетной.

Ну так даже смотреть необязательно, достаточно описание прочитать (ссылка - в первом же сообщении). Оно умеет считать CRC (миллионом разных способов. не лень было.. :) ) и добивать массив до нужного размера. Наверное, у половины здесь присутствующих подобные утилиты есть. Я тоже делал, но строго заточенную под нужную задачу - что-то общее делать категорически лень. Так что совершенно не понимаю, в чём prottoss виноват. Есть, кстати, ещё более универсальная SRecord. Там, правда, ключи писать с непривычки мозг ломается...

... то производитель флешки обычно обещает "в первой странице битого блока не будет FF". Этого достаточно, чтобы при форматировании разобраться, что происходит. Только мужика этого Хэмминг зовут :-) Да, возможность коррекции одного бита (и обнаружения более сложных ошибок) на один блок. Длина блока может быть произвольной (обычно считают ECC по всей странице сразу). По опыту изучения дампов NAND'а WinCE - занятие малоперспективное. Лучше уж эмулятор написать (исходники-то доступны!) и крутить там эту ФС, как душе угодно.

Полистайте на досуге любой (!) даташит на параллельную NAND. Там размер страницы 528, 2112 и прочие "некратные".

Идея, в принципе, верная - использовать какие-нибудь "лишние" аппаратные прерывания (благо их в современных камнях с избытком). Даже на ноги ничего выводить не надо (разве что для отладки будет полезно). Но, по хорошему, требуемый функционал хорошо ложится на RTOS. Я тоже когда-то велосипеды строил - низкоприоритетные прерывания, длинные процедуры которые выполняются за несколько заходов (чтоб в паузах можно было что-то ещё сделать). В очередной раз порекламирую scmRTOS - компактно, наглядно, хорошо документировано. По функционалу до "больших" ОСей бесконечно далеко, но этого никто и не обещал. PS вроде б можно крутить приоритет текущего прерывания. Надо б внимательно прочитать, в какой момент оно в контроллере прерываний сравнивается. Но зачем подкладывать себе же такие очевидные грабли?!

Если понимание "что там внутри" отсутствует, самый лучший принцип - "работает - не трогай". Это, правда, совсем не означает, что разбираться в "кишках" не надо. Надо только лезть туда с шашкой после того, как придёт понимание, что может сломаться и где это можно увидеть. А по сути - есть сорсинсайт (уже рекламировали), есть understand. Обе программы есть на рутрекере. Я в чужом проекте разбирался, засунув его в эклипс (там удобные переходы объявление/определение/использование) и рисуя на листочке блок-схемы. Или вижуал студия (там, правда, платный вижуал ассист нужен).

Плохо задумано, к сожалению. Idle - это пауза >= одному байту. Я никогда не интересовался, как обстоят дела с паузами у GNSS приёмников, но предположим, что плохо - паузы могут быть в произвольный момент времени. Например, приходят пакеты 10 байт, пауза, 2 байта, пауза. Принимаем в буфер 1 10 байт (где проверка на переполнение, кстати?!), запускаем передачу. Принимаем в буфер 2 пару байт, запускаем передачу. Сколько чего отправилось из буфера 1, неизвестно - вероятнее всего, несколько байт уйти не успели.

Ну ещё бы. Semihosting - это старый механизм. Довольно гибкий, но крайне медленный: - софт в контроллере на каждый putchar() выставляет брекпоинт. - отладчик "ловит" этот брекпоинт, считывает переданный байтик (по определённой комбинации регистров, насколько я помню), отправляет в консоль. Помимо двунаправленной консоли, можно ещё кучу "плюшек" организовать, но, вроде б, это так никто и не поддержал. Подробности есть на arm.com в разделе "ARM Compiler Software Development Guide" -> "Semihosting". Но постоянные остановки ядра на пользу реалтайму не идут, конечно же. SWO - это совсем другая штука. Ядро кладёт байтик в специальный регистр, а дальше "оно само". Но тут канал однонаправленный (впрочем, в 99% случаев отладочный канал такой и нужен). Это если только энергосбережение какое-то отлаживать. Но там и внешний уарт мешать будет. А так - SWD и SWO штуки независимые, можно использовать только что-то одно.

Я конечно понимаю, что у Вас с STM какие-то особо личные отношения, с технической частью вопроса никак не связанные. Но справедливости ради, "мазохизм с этим FSMC" был только на самой первой линейке этих процессоров. Уже лет 8 прошло с тех пор, можно смело использовать любую другую линейку STM. Там и другие ошибки поправили, кстати (errata на ту серию - аж на 40 с лишним страниц).

Внутрь Atmel'овской реализации не полез, но судя по описанию, у них сделан стандартный вариант: сначала - key expansion (11 блоков по 16 байт), а потом - дешифрование этим ключом. С учётом того, что им дешифровывать надо много, а свободной памяти в загрузчике обычно много, подход верный. У меня была идея расширять ключ непосредственно перед очередным раундом шифрования. Это медленнее, если надо шифровать больше одного блока одним и тем же ключом, зато экономится 160 байт ОЗУ. Как вчера выяснилось, это вовсе не моя идея, и в интернете полно таких реализаций :-) Вот, например, ещё и сишные исходники от TI: http://downloads.ti.com/tsu_encryption/tsu...8.zip?tracked=1

Не получается у него. Человек такой... Пользуясь случаем, хочу сказать "спасибо" за книжку к scmRTOS. Подробно, понятно и с душой.

Почитал описание дырки. Нужно 5e17 запросов, чтобы подобрать ключ. Предположим, что у злоумышленника есть зашифрованный текст, какие-то догадки по содержимому исходного текста (предположим, он знает половину из 16-ти байт) и медленный канал, по которому можно слать свои запросы. Ему надо уметь подделывать исходный текст, т.е. знать ключ. Запрашивать что-то, предположим, можно, но явно не 5e17 раз (за сутки через канал пролезет сильно меньше миллиона пакетов. чисто физически). В общем, кажется мне, эта дырка - не про embedded шифрование, когда скорость взлома перебором сильно ограничена. Или я что-то принципиальное не понимаю? PS нарыл микрочиповские app note http://www.microchip.com/Developmenttools/...PartNO=SW300052 Они молодцы, у них AES работает сильно быстрее, чем у нас получилось. Надо разбираться, их реализация по скорости очень нравится. А вот XTEA у них получилось медленнее AES'а. Так что алгоритм *TEA на 8-битниках не очень-то и полезен... PPS вот, кстати, ещё одна реализация, претендующая на супер-компактность: https://github.com/cmcqueen/aes-min

Если нехорошие люди смогут сделать "подслушивалку", цена репутации измеряется... Миллионами, наверное... Другой вопрос, что ключи генерируются для каждого устройства (точнее, для пары), и "подслушивалка" должна быть довольно продвинутой. А чем плохи *TEA, что они "для галочки" ? Вроде б то же шифрование (о наличии "дырок" пока толком неизвестно), только перебирается на порядки быстрее.

Уже успели пообещать, что у нас AES. Идея "расширять ключ, когда потребуется" вполне рабочая, если использовать только один блок. Для шифрования всё делается просто "влоб", для дешифрования надо изрядно подумать, но тоже можно. Но что-то подсказывает, что упрёмся в быстродействие, и будем смотреть что-то попроще...

Убивает детей, конечно же. И невинных девушек насилует. Это ж преступник, по лицу видно. Господа, ну что за привычка такая? Был задан технический вопрос. Вопроса "срочно научите меня жить" не было, зачем демагогию разводить? Уже который раз на электрониксе флуд ни о чём :-( drehows, по делу. По-хорошему, надо делать защиту от превышения тока. Однако беглое изучение вопроса показало, что дешёвое решение - LiIon аккумулятор, спираль и кнопка между ними. Всё. Использовать дополнительно мосфет - хорошая идея, хотя бы кнопка не сгорит :-) Надо брать LiIon с платой защиты (продавцы обозначают их protected LiIon), появляется минимальная защита от слишком большого повышения/понижения напряжения. Для заряда LiIon китайцы выпускают стандартные модули. Также существует миллион различных микросхем, но для единичного изделия проще купить модуль. Можно, кстати, дешёвый power bank купить - в комплекте аккумулятор и схема заряда. И коробочка бонусом :-)

Беда с электрониксом :-( Вместо обсуждения техники народ начал считать чужие деньги, которые разработчики лопатой гребут на перепродаже отладок (вот же гады! небось виллы на Канарах у каждого!). И особо важный вопрос "STM32F427 звучит гораздо круче, чем К1921". Беда, господа инженеры, беда... Извините за оффтоп.

Здравствуйте, коллеги. Подскажите, пожалуйста, какую-нибудь библиотеку шифирования/дешифрования AES. Целевая платформа - 8-битник, ОЗУ свободно около 150 байт. Пока что нашёл https://github.com/kokke/tiny-AES128-C - там нужно около 200 байт. Или идеями поделитесь, если в "кишках" этого AES'а копались. Может, как-то расширение ключа делать по мере необходимости? Вроде б ничего не мешает хранить только текущий ключ...

Я уверен, что разговор не о том. Во-первых, слова 'SPI' в теме не было. Зато была ссылка на даташит и слово 'NAND'. А во-вторых, там была мысль о том, что битый блок можно стереть (и он, возможно, сотрётся). Потом можно записать туда информацию, и она, возможно, корректно считается обратно. Или некорректно. Как повезёт. Мешает отсутствие готового нижнего уровня. Этот нижний уровень, собственно, и должен решать вопросы: - не каждый блок можно использовать (битые блоки) - минимальный размер стирания - блок (16 килобайт в данной конкретной микросхеме) - полезная штука - wear leveling, чтоб не "протереть дырку" в каком-то часто используемом месте. А вот поверх этого всего можно и "обычную" ФС надстраивать...

Второй способ более правильный. Табличка битых блоков в ОЗУ, при старте пробегать по первым страницам каждого блока и смотреть: - данных нет (всё 0xFF) - нормальный чистый блок - данные есть, ECC сходится - нормальный занятый блок - данные есть, ECC не сходится - битый блок Идея поднять файловую систему правильная. Вопрос только в том, что компактных ФС для "голого" NAND'а в открытом доступе особо и не видно... Разве что NXFFS из NuttX должна довольно легко выдираться. Или yaffs смотреть. Я не пробовал, мы свой велосипед строили (зря, наверное, куча времени уходит...). Всевозможные реализации Fat16/32 в чистом виде на NAND не ложатся никак. Ещё есть всевозможные платные решения, но, мать их, всё закрыто - исходников нет, тестов нет, одни рекламные обещания "дайте нам денег, у нас всё самое-самое лучшее".

Предлагаю изучить вопрос "что такое шина SPI". Вообще SPI, не вдаваясь в детали FRAM и XMega. Тут-то и выяснится, что операций "чтение" и "запись" по отдельности нет. На каждый байт, записанный в шину мастером, слейв записывает свой байт, и мастер его оттуда читает. Отсюда вывод - чтобы что-то прочитать с шины, мастер должен туда что-то записать. Обычно записывают ноль или 0xFF. Теперь пишете функцию обмена одним байтом: unsigned char ProcessSPI (unsigned char data) { // записать data в шину // подождать, пока отправится (мне лень изучать документацию XMega, извините) // return данные из шины } и вызываете её: // установить write enable ChipSelect (true); ProcessSPI (0x06); ChipSelect (false); // проверить статус ChipSelect (true); ProcessSPI (0x05); status = ProcessSPI (0x00); ChipSelect (false);

Во всяком случае, надо документацию читать на перед тем, как что-то делать. Попробуйте привести сопротивление на выходе операционника к значению из даташита. И питание ему увеличить, если есть возможность. Около нуля входного сигнала он по-прежнему работать не будет (нужно отрицательное питание), ну да ладно.

Старшие товарищи меня поправят, я 140УД-что-то-там видел только на лабораторках в институте. Смотрю документ "технические данные" от Интеграла. Как минимум, там есть странный параметр "сопротивление нагрузки от 2 до 10 килоом". У Вас явно не так. Напряжение на входе при питании от +5В должно быть меньше 3.3 вольт - т.е. полной шкалы акселерометра видно не будет. Макс. напряжение на выходе при тех же +5В питания - аналогично, +3.3 вольта. В общем, какой-то подозрительный операционник...

Хм. Хотел кинуть первую же попавшуюся ссылку "операционные усилители", а там такое же безобразие нарисовано, как и у Вас. Беда-а-а-а... Выходное сопротивление Вашего преобразователя довольно большое. Если АЦП неидеальный (почему бы сразу не сказать, что используется?..), он и будет влиять на напряжение на этом делителе. И кто такой DA3 ? Самое простое решение - инвертирующий усилитель с коэф. усиления меньше единицы. Самое правильное решение - инструментальный усилитель, тогда не будет влияния на датчик (у инвертирующего усилителя входной ток ненулевой, а допустимый ток акселерометра нам никто не сказал - возможно, появится погрешность).

Соответствие паспорта датчику легко проверить по серийному номеру. Соответствие паспорта правде придётся проверять самостоятельно :-) Пока что даже по этим измерениям видно, что (напряжение_ось_вверх - напряжение_ось_вниз) / масштабный_коэффициент равно двум g. В одном положении датчик показывает +1g, в другом - -1g. Разность как раз даёт два (или минус два). Два с половиной процента погрешности предлагаю списать на некорректные измерения. Значение нуля можно примерно считать как середину измеренных значений. Правда, Вам нужен инклинометр, и такая точность, скорее всего, недостаточна. Что с этим делать, не знаю. У нас получился датчик "просигнализировать, что объект повернули относительно начального положения". Пара градусов на совсем дешёвом акселерометре - без проблем. Но там можно запоминать начальное значение и отбрасывать совсем медленные изменения (из-за влияния температуры, например).

Так. Давайте-ка табличку: - масштабный коэффициент по оси X (из паспорта) - напряжение по каналу X, ось X направлена вертикально вверх (с вольтметра) - напряжение по каналу X, ось X направлена вертикально вниз (с вольтметра) (ещё 6 аналогичных цифр по остальным двум осям). А потом будем заниматься арифметикой. Если посмотреть внимательнее, в документе "ПЗ" цифра "2.5 вольта в покое" указана с немаленьким допуском. Вот и не надо верить интернетам :-) Сказано, что у вас 2,5 В +/- 0,2В - значит, так и надо считать: там от 2,3 до 2,7 В, а сколько точно - неизвестно.