Jump to content

    

jcxz

Свой
  • Content Count

    6287
  • Joined

  • Last visited

Community Reputation

0 Обычный

About jcxz

  • Rank
    Гуру
  • Birthday 12/01/1974

Контакты

  • ICQ
    311337544

Информация

  • Город
    Омск

Recent Profile Visitors

14099 profile views
  1. STM32F103 Timer + DMA + GPIO

    Если ТС осилит асм и сможет написать подряд этак 1000 команд записи в порт GPIO и измерит время их выполнения, то его радужные заблуждения насчёт частоты GPIO быстро рассеятся.
  2. STM32F103 Timer + DMA + GPIO

    Ещё можно попробовать усыпить процессор - может это и даст какой выигрыш на время обмена. Но скорее Вам надо пересматривать архитектуру и искать другое решение. Без ногодрыга. Даже с DMA. Да и чего вы хотите добиться в результате? Может это вообще недостижимо таким способом...
  3. Послать через какой профиль? В BT существует понятие "профилей". Да и есть обычные BT и BLE-модули - то же есть разница. Если "пару байт", то подойдёт любой, в котором есть нужный профиль.
  4. А какие требования к его возможностям? Или чтобы только волны излучал?
  5. Мой constPNaN взят как раз из проекта IAR.
  6. STM32F103 Timer + DMA + GPIO

    Непонятно с чего Вы решили что GPIO может работать на частоте ядра? Часто частота GPIO как раз и составляет эти самые 6 МГц. И никакой DMA тут не поможет ускориться. Иногда частота GPIO явно указывается в мануале на МК.
  7. Чем же хуже? Тем что это работает, а то что заложил некий автор - не работает? И в каких современных компиляторах у нас плавучка не IEEE, а какой-то свой доморощенный формат? Ну а если уж так этого бояться, то можно заложить соответствующий #ifdef/#endif для всех имплементаций.
  8. LPC1768 для освоения ARM

    if (желание_заниматься_МК == true) пишем_на_си(); else if (желание_изучать_линух == true) учим_линух(); else if (есть_деньги_купить_готовое_ничего_не_делая == true) идём_в_магаз_и_покупаем(); else reset();
  9. Если так, то это ужасно кривой метод. Почему не сделать нормально?: //спец.значения float: +NaN и -NaN union { u32 i; float f; } const constPNaN = {B31 - 1}, constNNaN = {B31 - 1 | B31};
  10. Либо программа ТСа, которую он туда уже зашил и запустил (а тут написать об этом забыл), из-за своей кривизны быстро протёрла этот самый 3-й до дыры. Вангую через некоторое время увидеть здесь сообщение ТС типа: "Отбой, проблема была в моём коде. Ошибку уже нашёл"
  11. LPC1768 для освоения ARM

    Посоветую тогда изучать программирование под линух или винду. В МК, без знания периферии, делать нечего.
  12. Я там случайно обрезал нижние строки из асм-вставки (уродский новый движок форума!). Полнее будет так: где: extern "C" u64 JsonInputParse(JsonInput *, void const *, void const *); extern "C" u64 JsonInputErrorExec(JsonInput *, u8 const *, u8 const *, uint); extern "C" u64 JsonInputParseExec(JsonInput *, void const *, void const *); struct JsonInputJmp { u32 sp; }; extern "C" JsonInputJmp jsonInputJmp; Т.е. - JsonInputJmp просто хранит SP, к которому нужно будет вернуться. Начинается работа парсера с вызова: u64 q = JsonInputParse(&d.sh.jsi, s, se); s и se - указатели на начало и конец распарсиваемого фрагмента JSON-тела. Внутри выполняется развесистая обработка с множеством ветвлений, машиной состояний, вызовом множества функций. Которые парсят входящий JSON, в разных точках могут обнаруживать ошибки и при этом должны вызвать функцию JsonInputError() передав ей код и место ошибки (между s и se) в аргументе. Она восстановит исходное положение стека из JsonInputJmp, затем вызовет си-шную JsonInputError(), которая обработает ошибку (сформирует JSON-сообщение об ошибке с указанием её места в исходном фрагменте JSON) и вернётся в точку после вызова JsonInputParse() так, как будто был штатный выход из функции без ошибки (но вернув в q состояние ошибки). Стек не нарушится. Если же JsonInputParse() выполнила работу обработав фрагмент s...se без ошибок, то она просто выполнит return вернув в q состояние "Всё ок". В принципе - если внутри всей этой работы внутри JsonInputParse() JsonInput * (из 1-го аргумента) существует везде, то можно структуру JsonInputJmp хранить внутри JsonInput (или породить последнюю из первой). И таким образом избавиться от статической jsonInputJmp. Но мне это в данном случае не нужно. setjmp()/longjmp() неудобны тем, что требуют штатного выхода из функции тем же способом, что и при нештатном, резервируя под это одно значение аргумента. Кроме того: не позволяют передавать дополнительные аргументы. Да и вообще - накладывают кучу ненужных ограничений. Зачем эти ограничения, если мы всё это может сделать сами так, как наиболее удобно для данного конкретного места? Здесь это у меня реализовано так, в другом месте я реализовал по другому (как там удобнее). И не связан никакими искусственными ограничениями. Снимаются со стека ненужные в точке возврата из JsonInputParse() значения первых двух её аргументов. Они туда сохраняются для функции JsonInputErrorExec(), которая по ним строит сообщение о локализации ошибки в входящем фрагменте JSON. А в точке возврата они уже не нужны - там и так знают что передавали внутрь.
  13. Ой сколько Вы написали! Я столько читать не осилю. И честно непонятно - зачем столько? Вопрос же простейший. Я частенько пользуюсь такого рода приёмом. Только не через setjmp()/longjmp(), а пишу свою обёртку на асм. Дело выеденного яйца не стоит. Например так: JsonInputParse: PUSH {R0,R2,R4-R11,LR} PUSH {R1} LDR R3, pjmp STR SP, [R3] BL JsonInputParseExec ADD SP, SP, #8 POP {R2,R4-R11,PC} ;__noreturn void JsonInputError(uint); _Z14JsonInputErrorj: LDR R3, pjmp LDR SP, [R3] MOVS R3, R0 POP {R1} POP {R0,R2,R4-R11,LR} B JsonInputErrorExec JsonInputParse сохраняет состояние стека (вызывается сначала) и вызывает начало блока кода JsonInputParseExec из которого надо выходить в разных местах. JsonInputError - восстанавливает стек (вызывается после, в любой точке JsonInputParseExec или вложенных в него функций). Очень удобно, когда нужно зайти в какую-то развесистую обработку чего-то, со множеством уровней вложенности вызовов функций. А потом легко выйти по какому-то условию наружу из этого развесистого. PS: Если в родителе (откуда идёт вызов) и в внутри потомка используется плавучка, то и её контекст тоже нужно сохранить.
  14. Вопрос, набивший уже оскомину на этом форуме: Зачем для JSON нужны какие-то "библиотеки"? Уже не говоря о том, зачем им куча? Это ведь простой формат. Парсинг всего входящего текстового JSON у меня укладывается в каких-то ~500 строк си. При этом поддерживаются все стандартные типы данных JSON + некоторые расширения. И никаких куч оно не использует - вполне себе довольствуется одним(!), вполне себе статическим(!) блоком памяти (для сохранения распарсенного JSON в бинарном виде). И принимает входящее JSON просто как последовательный поток символов - может работать с любым источником JSON на лету. PS: Если так дальше пойдёт "прогресс", то скоро и преобразование числа в строку будет невозможно без неких "библиотек"...
  15. А "до" почему не можете? Просто тупо в лоб записать/прочитать содержимое первой ячейки из региона адресов каждого дополнительного чипа памяти - неужто без RTOS вообще никак?