xvr

data_re_out(i) <= reg_data_in(i)((NUM_PIPELINE/2)-1 downto 0); ?

Не совсем поиск лексем, но можно как ориентир рассматривать. Индусский код для проверки на True (Java) String.valueOf(myBoolVar).length() == 4 Пошёл за третьим пакетом попкорна Для начала определитесь как её будет принимать 'библиотека под Андроид'. В частности её не поплохеет если вместо текстовой строки от вашего BT приедет 'нечто' (совсем бинарное и на текст не похожее) ?

GT911 Programming Guide_v0.1 (1).pdf

Как то жто всё мне напоминает одного товарища (из Новосибирска кажется) который мне лет 5 назад писал - Я ему ответил конечно, приблизительно 'где же вы последние 25 лет были?' FORTH из той же оперы (только лет там побольше будет)

А вот и парсинг подоспел. Пошёл я за попкорном

В отсуствии volatile у OSCCONbits и присуствии уровня оптимизации >0. Проверьте, что в системных хидерах написано по поводу OSCCONbits.

С пяти строк до двух- в 2.5 раза 🙂 if ((EncInput & ~EncState) & 1) Steps += (EncInput & 2) ? 1 : -1; EncState = EncInput;

Если у вас с энкодера приходят чистые сигналы (без дребезга), и если энкодер с стопом (т.е. у него есть устойчивые положения) и если на 1 шаг энкодера он проходит все 4 состояния, то подсчёт можно сильно упростить. На фронт (или спад - по вкусу) сигнала на одной фазе проверяем сигнал на другой. Если там 1 - инкрементриуем счётчик, иначе декрементируем (или наоборот - по вкусу). Несмотря на много 'если' вверху многие энкодеры как раз такие (за исключением 'чистых сигналов' - но дребезг можно подавить отдельно)

Можно сделать ловушку из цикла в начале main. volatile int trap = 0; for(;;) { if (trap) break; } Ставите точку останова на if (trap), запускаете. Как gdb остановится сбрасываете trap (p trap=0). Всё, можно отлаживать. Всю эту машинерию можно макросом в gdb оформить

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

Школу я тоже закончил очень давно, поэтому давайте подойдём с другой стороны: 16кг на 4 метра это явно больше, чем весь шлагбаум, даже если представить его в виде гири, закреплённой на невесомом стержне. Он всего 8кг на 4 метра. Так что 16кг на 1 метр

После окончания записи - безусловно, но он может это делать и в процессе записи. Так что это не 100% надёжный вариант отследить именно окончание записи в файл. Сама директория да, а вот кластеры файла - нет. Так что для чтения файла придётся по FAT ходить

Он вам как бы намекает, что нету в вас 'main' 😞 Возможно файл с main был собран без отладочной информации? (Так, в порядке бреда)

На смартфоне нужно будет включить режим модема через Bluetooth. Но устройство должно само подключиться (по видимому оно должно быть мастером) Устройство может быть одновременно и точкой доступа и клиентом (например ESP32 так точно умеет). На точке доступа будет всегда висеть конфигурационный интерфейс, на клиенте - собственно клиент.

Отличить состояния 'девственно чистый диск' от 'что то записано' можно по наличию первой записи в root секторе. Отличить состояния 'что то пишется' от 'всё записно' со 100% вероятностью нельзя в принципе - FAT никак не помечает окончание записи в файл (если мой склероз мне не изменяет). Только по таймаутам или физическому размонтированию носителя (выдёргивание USB например) Читать то, что записано лучше всего через fatFS в режиме RO или аналог (как уже предлагали, да и сам ТС к тому же пришёл). В принципе можно предположить что ОС будет записывать сектора файла последовательно (и скорее всего так и будет), но полагаться на это нельзя. Читают FAT, это не так сложно, как кажется.

1K из конфига умножить на размер элемента стека - 8 байт (у вас же 64х битная машина)

Для автомата адаптер USB-UART должен содержать не только TX/RX пару, а ещё 2 сигнала (DTR & RTS). И они должны быть выведены на reset и boot (DTR на IO0, RTS на EN)

8 у вас - А стек у вас на один таск - 8К Он в задаётся в словах - у вас 64 бита, так что 8 * 1К Так что 64К только на стеки. У вас ровно столько кучи и есть. Плюс ещё по 240 байтов на tskTCB. Всё, куча переполнилась

Продам настольный 3х осевой фрезер - https://aliexpress.ru/item/32849365486.html?sku_id=12000018040157969 Практически новый, в подарок добавлю выносной пульт управления (энкодер, переключатель осей, переключатель скорости, кнопка аварийной остановки) Самовывоз из Москвы (район м. Динамо). 50К руб. (80% от стоимости продавца)

Не, это не спортивно. Даёшь FORTH компьютер на транзисторах! А ешё лучше на лампах. Так как никакого практического смысла это поделее не имеет, то ценность его можно оченить только с археологической точки зрения 🙂 Если действительно нужен FORTH компьютер (пока оставим за бортом вопрос кому и зачем он мог понадобится), то нужно было делать его на какой нибудь FPGA в встроенной флэшкой (какой нибудь из GoWin'ов например). Туда штук 100 FORTH процессоров влезет - можно сразу FORTH супер кластер забабахать.

Оно выделяется один раз при старте, и не освобождается. А по поводу прожоливости - посчитайте размер на один LED (я всм писал уже, что туда входит). И помножте на количесвто LED'ов В готовом примере нет функции maaloc, которую вы упоминаете (равно как и в вашеи предыдущем примере её нет) Ну и то, что пример готовый и работоспособный, совсем не значит что он у вас заработает - окружение разное (размер кучи например)

Кто такой maaloc? Это pvPortMalloc? Посчитайте, сколько памяти вы заказываете. Это ваша структура xLEDParameters + стек на таску + сама таска внутри FreeRTOS. Это всё помножить на uxNumOfLEDs. Кучв не переполнилась?

Он вам создаст кучу в bss секции. В остальном разницы с heap_4 нет. Вы ничего туда не положили, так что линкер её выкинул (она пустая) Может у вас программа успела наалоцировать что то из кучи, и она банально закончилась?

Если у вас период таймера больше, чем возможное время дребезга (где то до 30ms в среднем), то не нужно Если у вас нет состояния когда ни один контакт с галетника не подсоединён, то проявляться не будет. Если же есть, то может дребезжать между ним и реально подключенным выводом

Смотрим в heap_4.c: #if ( configAPPLICATION_ALLOCATED_HEAP == 1 ) /* The application writer has already defined the array used for the RTOS * heap - probably so it can be placed in a special segment or address. */ extern uint8_t ucHeap[ configTOTAL_HEAP_SIZE ]; #else PRIVILEGED_DATA static uint8_t __attribute__ ((section (".hbss"))) ucHeap[ configTOTAL_HEAP_SIZE ]; #endif /* configAPPLICATION_ALLOCATED_HEAP */ configAPPLICATION_ALLOCATED_HEAP у вас не определён, так что heap будет распоглагаться в сегменте .hbss, который у вас в линкерном скрипте не описан. Куда попал в результате heap одному Богу известно 😞 Вы уверены, что у вас 2 кучи? heap_4.c делает только одну. У вас ещё один алокатор где то есть? С кучей проблемы.