skyspark

Выложил https://bitbucket.org/skyspark/scmrtos-mingw-port. Писал наспех, за вечер, из кода текущего проекта так что есть некоторые актефакты.

Выдыхаем, спасибо. Совладал. Проблемы обнаружилось две: 1. если собирать внешним make-ом получается не понятно что и виснет где и раньше. Переключился на internal стало интересно. 2. если отлаживаться st-util'ом виснет как и раньше, но после аппаратного сброса (без разрыва debug-сессии) работает правильно. Разобрался с настройками родного opencdt и с ним все стало хорошо. на всякий случай версия компилера (http://www.openstm32.org): arm-none-eabi-gcc.EXE (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288] P.S. Извините за беспокойство :rolleyes:

Вот только добрался снова до этого кода. Да, по всей видимости ошибся (уж под утро дело было), но эффект был такой же как и ранее. Пробежался по истории репозитория увидел, что потребовалось еще одно изменение INLINE static volatile uint_fast8_t & cur_proc_priority() { return Kernel.CurProcPriority; } Ну без этого "строгие" ++-ы валили ошибку.

Глянул дизасмом: Вариант без volatile (нерабочий): 08002206: beq.n 0x8002220 <OS::TKernel::sched()+40> 84 SchedProcPriority = NextPrty; >0800220a: str r2, [r0, #12] 90 DUMMY_INSTR(); >08002216: nop 93 while(CurProcPriority != SchedProcPriority); // until context switch done >0800221a: ldr r3, [r0, #0] 87 do >0800221c: cmp r3, r2 0800221e: bne.n 0x8002214 <OS::TKernel::sched()+28> Вариант с volatile (рабочий): 08002206: beq.n 0x8002222 <OS::TKernel::sched()+42> 84 SchedProcPriority = NextPrty; 0800220a: str r3, [r0, #12] 90 DUMMY_INSTR(); 08002216: nop 93 while(CurProcPriority != SchedProcPriority); // until context switch done 0800221a: ldr r2, [r0, #0] 0800221c: ldr r3, [r0, #12] 87 do 0800221e: cmp r2, r3 08002220: bne.n 0x8002214 <OS::TKernel::sched()+28> Все-таки регистр r2 перед сравнением не обновляется. Оптимизатор?

Добрый день. Я проковырялся пару дней с разными версиями развития событий, хотя не первый год использовал scmRTOS на разных процах, в т.ч. и на STM32L15x (и F1xx). Пробовал обе порты, пробовал откатиться к версии когда был родной startup и старая версия порты (проект давний и он на старых прошивках живет). Вызов raise_context_switch() проходит, PendSVC_ISR() вызывается, контекст переключается (!), но из while(...) он выходит только в процесс с максимальным приоритетом, вот только он один исправно и живет. SystemTimer_ISR() тоже зовется, что касается "кубовского" обработчика, то он вызывается из хука таймера (там только счетчик миллисекунд, раньше так жил DMAшный драйвер I2C в какой-то версии CPAL). А, что интересно, "кубовская" часть живет себе исправно и scmRTOS-ные обертки для дров исправно работают - события и сообщения исправно ходят из ISR'ных callback'ов куба. В приступе паранои, я отключил все дрова и пробовал просто подергать один поток событиями из другого или еще проще поморгать светодиодами из разных потоков по sleep. Еще думал, что может дебаг портит все - попробовал отключить его и посмотреть времянки анализатором дергая ножками из raise_context_switch(), PendSVC_ISR() и SystemTimer_ISR() - все зовется, while(...) висит) Помню, что-то похожее давным-давно видел на AVR8, но там как-то быстро решилось все и я уже не помню причины. Пока живу вторую неделю с volatile - работает. Одно не попробовал пройтись там дизасмом и посмотреть разницу - обрадовался, что заработало) ЗЫ Ac6 версии 1.4, GNU Tools 1.3, ставил как плагин Eclipse.

Добрый день. Пробовал сделать по аналогии с FreeRTOS под Qt, но с движком WinAPI. Доделать не успел, и сейчас на это нет времени, код могу выложить на bitbutcket.

Добрый день. Перенес проект в Eclipse на CDT с таким набором: scmRTOS+STM32L15x+OpenSTM(+CUBE). Столкнулся с проблемой переключения контекста (после обновления Eclipse до Mars, всех плагинов и самой порты ОС): Выполняется только задача с максимальным приоритетом, остально время висим тут: {...} while(CurProcPriority != SchedProcPriority); // until context switch done В отладчике вижу что CurProcPriority = SchedProcPriority, проблема знакомая с AVR8 и оптимизатором в IAR. Я грешил на что оставил stdlib при переносе и откатился в далекое прошлое, когда в проекте не было sdtlib был родной (порты OC) startup и все работало, поиграть с оптимизацией, собрать yagarto'ой, но это не изменило ситуацию. Решилось так: volatile uint_fast8_t CurProcPriority; Хочется узнать почему она изначально не объявлена volatile как и SchedProcPriority?

Кое что есть, джойстики делают на AVR, это стандартное HID устройство. Смотри тут: http://www.marktmarshall.com/doku.php?id=projects:avr-hid Ну и серфом по инету, точно есть конструкция для подключения модельного пульта как джойстик, посмотри на форумах по авиамоделизму, там все было.

Мария. Не понятно, зачем дважды конфигурировать fifo на EP2, но это ни чего не меняет. А вот где EP6AUTOINLENх. Может по этому не взводит флаги. А ассинхронный дизайн действительно так необходим? Синхронный выглядит понятнее и продолжает синхронный дизайн в ПЛИС.

Я разобрался с проблемой. Статья действительно помогла :) Дело было в том, что если поднят флаг FULL, то необходимо запрещать запись в fifo, со стороны мастера. В противном случае КТ перестает работать. Было каким-то похожим образом, вечером посмотрю.

Привет. Начал разбиратся с сайпресом, столкнулся с проблемой, конфигурирую EP2 как ISOC IN AUTOIN=1. Выбираю нулевой адресс fifo. С ПЛИС дергаю лапкой SLWR и/или PKEND. Тактовую ПЛИС беру IFCLK = 48МГц. Наблюдается следющее: Если дергать лапкой SLWR, сигнал FULL = 0, тоже просходит если дернут PKEND 4 раза (по числу буфферов) ,EMPTY ведет себя адекватно после первого клока записи или окончания пакета EMPTY = 0. Инитил так, больше ничего не делал: REVCTL = 0x03; // REVCTL.0 and REVCTL.1 set to 1 SYNCDELAY; CPUCS = 0x12; SYNCDELAY; IFCONFIG = 0xE3; SYNCDELAY; EP2CFG = 0xD0; // EP2 is DIR=IN, TYPE=ISO SYNCDELAY; FIFORESET = 0x82; // Reset the FIFO SYNCDELAY; FIFORESET = 0x82; // Reset the FIFO SYNCDELAY; FIFORESET = 0x82; // Reset the FIFO SYNCDELAY; FIFORESET = 0x82; // Reset the FIFO SYNCDELAY; EP2FIFOCFG = 0x0C; // EP2 is AUTOOUT=0, AUTOIN=1, ZEROLEN=1, WORDWIDE=0 SYNCDELAY; EP2AUTOINLENH = 0x02; // Auto-commit 512-byte packets SYNCDELAY; EP2AUTOINLENL = 0x00; SYNCDELAY; PINFLAGSAB = 0x00; SYNCDELAY; PINFLAGSCD = 0x00; SYNCDELAY; Конечная точка сконфигурировал так: ;; Endpoint Descriptor db DSCR_ENDPNT_LEN ;; Descriptor length db DSCR_ENDPNT ;; Descriptor type db 82H ;; Endpoint number, and direction db ET_ISO ;; Endpoint type db 00H ;; Maximun packet size (LSB) db 02H ;; Max packect size (MSB) db 01H ;; Polling interval Не могу понять, почему он не отсылает пакеты. И достаточно ли USB Console что бы проконтролировать, она мне не зависимо состояния буффера говорит: Isoc IN failed.

Спасибо помогло :). Понял как оно работет.

Читал Synthesizable Finite State Machine Design Techniques от туда, понимаю что нормально, но почему Квартус валит ошибку. Защелкивание он валит по всем выходам КА. В проекте только один КА и больше ничего. В железе проверял уже подключая к остальной схеме, на сколько я понял защелкивается. Не совсем понимаю куда девается reg_fstate в случае с двумя блоками always.

Упорно не получается сделать FSM так что бы работало :). Я наверное что-то не понимаю :cranky: . После первых экспериментов, воспользовался smf файлом, и нарисовал что нужно. Смотрю симулятором и в железе EP2C5T144C8 @ 100Мгц. Quartus генерирует код вида: always @(posedge clock) begin if (clock) begin fstate <= reg_fstate; end end always @(fstate or reset or tx_busy or f_smpl_rdy or f_all_reg) begin if (reset) begin ... end else begin case (fstate) WAIT: begin if (f_smpl_rdy) reg_fstate <= START_PACKET; // Having else block to avoid latch inference else reg_fstate <= WAIT; ... end На это квартус говорит: Warning (10240): Verilog HDL Always Construct warning at bsc.v(56): inferring latch(es) for variable "f_adrrst", which holds its previous value in one or more paths through the always construct В симуляторе работает, в железе виснет. Мне сначала показалось, что разумным было бы внести все в один блок always @(posedge clock) и это естественно устраняет варнинг, но получается бред если посмотреть в RTL Viewer и в симуляторе. Когда убираю регистр fstate и вношу все в один блок always @(posedge clock) и делаю case (reg_fstate), вроде все начинает работать но только в симуляторе. Направте не путь истинный, как реализовать FSM, почему код генерируемый стандартными стредствами IDE приводит к защелкиванию схемы?

Ну видимо так и придеться делать :). Посоветуйте, что нибудь из ШИМ-контроллеров, а то помню только UC3842 (ну и TL494) и для батарей она некатит особо. По сути надо получить 500В с током 50мкА и 5В (питание инструментального ОУ и ЦАПа) ну пусть 50мА. Т.е. всего 300мВт получаеться источник. Что касаеться изоляции обмоток, то наверное тефлон между слоями и раздельные платы первичной и вторичной цепей, выводы с транса МГТФом.