jcxz

А в чём позор-то? В том что я не использую никакие сторонние библиотеки для работы с периферией (и прочие CMSIS)? И не гадаю потом как они работают? Хорошо - тогда и дальше буду позориться. Что такое SYSRESETREQ в ядре я знаю, о чём и написал выше. И использовал его иногда. Да и при программировании гугл не использую, а только IDE да юзермануалы...

NVIC_SystemReset - это что? ISR? Или нет? Если ISR, то с какого бодуна он должен что-то сбрасывать или перезапускать? Если нужен сброс МК, то самый надёжный путь - через WDT. Не спешите с выводами. Может конкретно у этого STM32 это и так, но сиё не верно для всех Cortex-M. Что за МК у автора как всегда остаётся только гадать (когда уже наконец-то чайники научатся указывать о каком МК, компиляторе и т.п. вопрос??? как будто форум здесь для телепатов...). SYSRESETREQ на Tiva работает вроде нормально. А вот на NXP разных серий (LPC17xx, LPC43xx) у меня были какие-то проблемы с ним. Точно не помню, но на LPC43xx вроде вообще не работает, а на LPC17xx там вроде не всё сбрасывается. Так что на LPC использую WDT.

осталось только понять: что будет, если эта библиотека сама обратится к функциям ОС, которой нет. :smile3046:

Проще тогда не использовать ФС. Выскажу неглупое предположение, что раз так поставлена задача - обойти ФС, то очевидно она вообще не нужна.

Ну это и правильно - вначале надо отладить процесс обмена с картой без ФС. Если у Вас идут переполнения, да ещё при таком огромном буфере (на 200 мсек), то смотрите временные диаграммы работы карты. А именно - время выполнения операций записи/стирания. Возможно у Вас тормоза именно в моменты когда карта внутренне пишет данные или стирает перед ними. Возможно надо ей давать команды предварительного стирания блоков (я работал с SD давно - деталей не помню). Попробуйте разные карты. Посмотрите в CSD всё что касается размеров блоков стирания и времён. Карта при такой внутренней записи/стирании долго не выдаёт сигнал готовности. Речь не о диаграммах в доках, а о диаграммах на экране осциллографа или логического анализатора. Сигналов на шине SDIO. Блин! Опять 25! Мы здесь не телепаты чтобы знать как Вы эти свои 200kS/s выборок АЦП на карту пишете! Это у Вас там все исходники и если спрашиваете помощи, то непонятно почему и тогда толком не расскажете что именно делаете? Какова разрядность данных с АЦП? Сколько каналов АЦП? Как пишете просто бинарные данные или в текстовый вид преобразуете или ещё какую инфу к ним добавляете? Т.е. - какова требуемая скорость потока записи в байтах/сек??? Я уже не знаю как ещё понятнее спросить..... Ну что-ж - размер буфера выбран вроде достаточным. Стоп! А вы что при записи каждой порции данных потока данных в файл его открываете/закрываете? а зачем?? А так - операции с FAT ускоряются например кешированием содержимого карты в ОЗУ.

Ну так если понимаете, то тогда ещё раз - где именно тормоза? Что именно надо ускорить? Именно сам обмен с картой? (Вы вообще смотрели временные диаграммы обмена по шине?) Или всё-таки программную обработку на уровне FS (или каком другом)? Или ваша работа на пользовательском уровне по запихиванию данных в файлы? Или операции записи/стирания на карту? Или ещё где? Где оценочный расклад какая часть процесса сколько занимает (в %)? Как правило, когда для ускорения хотят тупо поднять частоту, то толком не понимают как именно работает весь процесс, где возникают основные расходы времени и тормоза. Просто даже 24МГц - это даже для SPI очень прилично (3МБ/сек), такой поток процессору уровня Cortex-M и всему ПО, которое работает с этим потоком (файловая система и т.п.) уже довльно сложно переварить. А тут у Вас SDIO! Там ещё в разы больше поток. всё это говорит о том, что львиная доля времени будет уходить не на обмен с картой, а на программную обработку. И просто поднятие частоты даст прирост скорости всего на пару процентов. Т.е. - Вы роете совсем не в том направлении. Да и вообще что-то непонятно - как именно поток данных с АЦП на 200кГц может перегрузить карту работающую на 24МГц? Или у Вас несколько каналов или Вы ещё какие-то данные пишете на карту вместе? Ещё раз вопрос - какие всё-таки требования по скорости записи??? какова скорость потока записываемых данных?

:smile3009: жесть какая.... Видимо начальник сам пробовал и у него не получилось.... или слышал звон... Чувствуется - Вы сами толком не понимаете что Вам надо и как это работает. Вообще-то DMA, при правильно организованной системе, нужен для разгрузки CPU. А на увеличение скорости обмена он напрямую не влияет. Хотя.... в STM32 с их дохлой периферией без FIFO может быть всякое..... Тупое увеличение частоты может совсем не принести нужного эффекта. Сначала нужно найти узкое место - где именно тормозит? И как построена работа с картой? И решить для себя вопрос - а сколько нужно-то (скорости)? Возможно тогда поможет просто переписывание lowlevel-функций обмена с картой, ниже файловой системы. А также кеширование дисковых операций на этом уровне.

...или DSP? Например что-нить из TMS320C674x или даже соответствующий OMAP: в DSP-ядре double-операции однотактные, внешняя память поддерживается (и SDRAM и DDR). А разве LPC4370 имеет аппаратный double?

Не вижу никакой связи. Systick используется ОС для работы шедулера, различных отсчётов времени для задач и вытеснения задач. Если нужно уйти в глубокий сон, естественно все ненужные на период глубокого сна источники прерываний следует отключать.

А антенна-то каким боком??? Или Вы думаете - она в чипе находится? :twak: Да и Web-интерфейс - откуда он взялся в ESP8266? Ничего не путаете? Там вроде только TCP-уровень обеспечивается. Может всё-таки как обычно - прокладка виновата? :smile3046:

Я захватывал с помощью HyperCam. Сжимать умеет и окно писать умеет и просто произвольную прямоугольную область экрана.

Тогда зачем Вам вообще RTC сдался? Используйте только этот PTP- таймер и всё.

Я не знаю - лучше или хуже, я просто поделился нашим опытом использования J-Link. А лучше или хуже - каждый решит для себя сам. Мы покупаем у стартеркита, проблем с ними ни разу не имели и поэтому не вижу смысла пробовать что-то другое, тратить на это время, когда надо заниматься самим проектом. Разница в пару тысяч деревянных тут роли не играет.

SysTick находится в ядре, тактирование его вроде не отключается и ест думаю неск. мкА. Активное состояние CPU, запускаемое им, будет есть во много раз больше и при этом CPU будет загружен всего на пару %

Увеличится незначительно. Зависит от: частоты сис.таймера (на нём работает шедулер), кол-ва задач, интенсивности их переключения, ну и частоты CPU. Так как требуется время на работу шедулера и некоторое время на переключение задач (сохранение/восстановление контекста). С частотой сис. таймера около 1 кГц и десятком задач уложитесь в 1-2 % загрузки CPU при его частоте в десятки МГц.

Если ПО автора (которое без ОС) написано оптимально, то там и так есть фоновый процесс, в котором выполняется просто цикл с одной командой WFE/WFI, а вся полезная работа производится внутри ISR-ов на разных уровнях приоритета. Тогда внедрение ОС приведёт к незначительному увеличению загрузки CPU и соответственно - незначительному увеличению потребления. Если же там просто суперцикл, то тут совсем другое дело. Так что говорить стоит не о том "с ОС" или "без ОС" написано, а как построен алгоритм работы ПО.

Без понятия.

Никак. Ибо эмулятор - это устройство для подключения к отлаживаемому процессору. Без процессора можно отлаживать только в симуляторе.

Что Вы так привязались к этому RTC??? Он Вам нужен только для хранения времени во время выключенного состояния МК. Как только МК включается, следует просто переписать время из RTC в один из системных таймеров (или PTP если там такой имеется) и брать время уже оттуда и синхронизировать уже этот таймер (корректируя соответственно и RTC конечно). А если связь по Ethernet есть всегда и не может пропадать, то RTC вообще не нужен - время будет получено после включения при первой же синхронизации.

В том, что используем их в коммерческих проектах. Простой в работе и отвлечения, связанные с восстановлением прошивки и прочие потери времени, обходятся много дороже чем 5000 руб. В своё время я много времени и нервов потратил на перепрошивки терровских J-Link-ов - ну его нафиг. На стартеркитовских ещё ни разу прошивки не восстанавливал за много лет. И никто в нашей конторе. Обновляются они все штатно сеггеровским софтом. А для домашних поделок и китайские клоны подойдут наверное.. хотя у меня и дома пара стартеркитовских. :-)

Для оценки загрузки ЦП нужен тип фильтра (КИХ, БИХ) и его порядок. А передискретизацию можно и кусочно-линейным способом сделать - вообще почти не грузит ЦП.

mp3 до 320 kbps и на Cortex-M3 на 78 МГц грузит проц на ~70% всего (LPC17xx). А тем более всякие АЦП, ЦАП - вообще почти никак не грузят CPU. Так что всё будет зависеть только от Ваших фильтров.

А Вы полностью тот тред прочитайте. Там же пишут, что слетает и у оригинального J-Link. Если так, то это проблема не стартеркита.

Я же сразу написал что такой вариант очевиден и не интересен. Представьте себе например мобильное устройство, которое само по себе меньше чем описанное сплетение коробочек и проводов. Скажем - тот же мобильный маленький робот. Да он ездить перестанет если на него всё это повесить. Или скажем надо отлаживать плату в устройстве в закрытом корпусе, которое к тому же стоит внутри силового шкафа. Или элементарно нужно подключиться отладчиком к устройству во время испытаний того на помехоустойчивость при подаче нано- и микросекундных помех с генератора, и чтобы сам канал эмулятора не вис от этих помех. PS: Вот если-б было что-то типа прошивки например к ESP8266, которая превращала бы его в J-Link по Ethernet.... Или подобный вариант, но с меньшим потреблением от отлаживаемого устройства.

Ага, а теперь представим папашу с ребёнком на плечах... Или двое ползущих один поверх другого... :-) Да просто элементарный раскрытый зонтик может скрыть сразу группу. В общем случае - никак не решается. Так как человек в силах обмануть такую электронику, если понимает принцип её работы.