Изучаем STM32 Cortex M3

[eddy]

Подниму свой вопрос. Пытаюсь на основе работающего кода для HID сделать CDC. Но что-то у меня даже стадию энумерации не проходит (пока оставил "чисто HID'овскую" энумерацию). Причем, железяка уходит в глубокий зависон (hardfault?).
Вот мне бы хоть решить проблему, какого черта она виснет: внутрь обработчиков USB не засунешь диагностические сообщения (иначе сразу компьютер считает железку неизвестной)...

[dgrishin]

внутрь обработчиков USB не засунешь диагностические сообщения

Есть такая тема - SWV (Serial Wire Viewer) - та него можно попробовать логи отправлять.

[eddy]

Содра config descriptorл с PL2303 . Вот его компьютер воспринял (до этого был какой-то из сети, со страной длиной 67 байт). Дальше пошло:

Aug 12 19:12:53 ishtar kernel: cdc_acm 1-6.2:1.0: Zero length descriptor references
Aug 12 19:12:53 ishtar kernel: cdc_acm: probe of 1-6.2:1.0 failed with error -22
Aug 12 19:12:53 ishtar kernel: pl2303 1-6.2:1.0: pl2303 converter detected
Aug 12 19:12:53 ishtar kernel: pl2303 1-6.2:1.0: pl2303_vendor_read - failed to read [8484]: -32
...

Остается правильную обработку остальных конечных точек реализовать + специфические запросы (вроде line_coding).

[Passer_by]

Такие объемные доки обычно набирают не с "нуля". Скорее всего берут что-то из близкого семейства и правят. Но бывает правят невнимательно.

И не только в этом беда. Основная беда всех ARM-ов - отсутствие работы с битами на уровне команд процессора, которая, в свою очередь, проистекает из баловства сей уважаемой конторы с Big- и Little- endian, которые определяются на самом последнем этапе проектирования ядра.
А это делает любой Cortex изначально ущербным в качестве ядра микроконтроллера. Ибо операции проверки битов регистров периферии не атомарны.
Иными словами, то, что на захудалом PIC-е выполняется за одну команду, в ARM-е требует не менее 3-х. И в их последовательность может вклиниться изменение данных в периферии. А это уже чревато. Отсюда и появляются всякие HAL-ы и прочие костыли. Средствами одного CMISIS-а эта проблема, к сожалению, не решается.
Про то, что отсутствие битовых команд жрет память программ, как не в себя и увеличивает время выполнения программы по отношению к PIC-ам, например, я уже просто молчу.

[scorpi_0n]

Да не позорьтесь такую чушь нести. Атомарность в ПИКах - посмеялся.
И разве 24-е и 32-е не load/store? Что-то у вас совсем все перепуталось.

[Djakovskij]

увеличивает время выполнения программы по отношению к PIC-ам, например, я уже просто молчу.

Улыбнуло..

[Passer_by]

И разве 24-е и 32-е не load/store?

24-e и dsPIC - не Load/Store.
Вот фрагмент кода, переключающего тактирование ядра для dsPIC33E

;Fcy=Fosc/2=1/2((Fin*M)/(N1*N2))=1/2((8 000 000*60)/(2*2))=60 000 000 Гц
;новая величина М=60 (PLLFBD=58)
    mov     #0x003A, W0
    mov     W0, PLLFBD
;новая величина N2=2 (PLLPOST=0), новая величина N1=2 (PLLPRE=0)
    mov     #0x0000, W0
    mov     W0, CLKDIV
;размещение нового типа генератора (NOSC=0b011 первичный генератор с ФАПЧ) в W0
    mov     #0x0003,W0
;разблокировка OSCCONH (старший байт) 
    mov     #OSCCONH, W1
    mov     #0x78, W2
    mov     #0x9A, W3
    mov.b   W2, [W1]		; запись 0x0078
    mov.b   W3, [W1]		; запись 0x009A
;установка нового типа генератора
    mov.b   WREG, OSCCONH
;разблокировка OSCCONL (младший байт)
    mov     #OSCCONL, W1
    mov     #0x46, W2
    mov     #0x57, W3
    mov.b   w2,[W1]		;запись 0x0046
    mov.b   w3,[W1]		;запись 0x0057
;разрешение переключния тактирования
    bset    OSCCON, #OSWEN      ;операция атомарна запрос на переключение тактирования установкой бита OSWEN bit
;ожидание завершения преключения тактирования
WaitOSCSwitch:	
    btsc    OSCCON, #OSWEN      ;
    bra	    WaitOSCSwitch       ;
;ожидание блокировки основной PLL
WaitMainPLLLock:
    btss    OSCCON,#LOCK	;операция атомарна 
    bra	    WaitMainPLLLock     ;

Тот же код для Cortex приведу позже. Посмотрим, где же там атомарность..
32-е PIC-и, таки да. Тоже самое, что и ARM - MIPS потому что.
Там те же костыли, что и HAL, только название другое.

Да не позорьтесь такую чушь нести. Что-то у вас совсем все перепуталось.

И без перехода на личности, pls...
Обсуждаем Cortex-ы, а не меня. Пользователь должен представлять себе не только достоинства, но и недостатки выбранного предмета приложения сил. PIC-и приведены в качестве примера. Как наиболее известные...

[scorpi_0n]

24-e и dsPIC - не Load/Store.

Разве?

;новая величина М=60 (PLLFBD=58)
    mov     #0x003A, W0
    mov     W0, PLLFBD

А что это по вашему?

Посмотрим, где же там атомарность..

;разблокировка OSCCONL (младший байт)
    mov     #OSCCONL, W1
    mov     #0x46, W2
    mov     #0x57, W3
    mov.b   w2,[W1]		;запись 0x0046
    mov.b   w3,[W1]		;запись 0x0057

Нет тут никакой атомарности. Ищите по никам Alex_B и DL36. Они расписывали в своё время прелести "атомарности" на PIC24.

32-е PIC-и, таки да. Тоже самое, что и ARM - MIPS потому что.
Там те же костыли, что и HAL, только название другое.

А что вы сравниваете? MIPS и HAL? Чудесно просто!

И без перехода на личности, pls...

Ничего личного, но чушь - ваша. За домашнее задание - ДВА!

PIC-и приведены в качестве примера. Как наиболее известные...

Все эти моменты уже давно сгорели в бесконечных холиварах. PIC-и выглядят убого и точка.

[Passer_by]

При чем здесь указанный Вами код?
Я говорил исключительно об атомарности битовых операций.
Вернемся, таки, к Cortex-ам.

//NMI occurs if quartz error present
void NMI_Handler (void)
{
	//CSS is turned on and if HSE errors occurred, the HSE and PLL must be disabled
	//and HSI must be the system clock source at 8 MHz therefore we must turned on the 
	//PLL with multiplier 12 to achive frequency 48 MHz of system clock
	RCC-›CR &=~RCC_CR_CSSON;
	RCC-›CFGR = (RCC-›CFGR & ~(RCC_CFGR_PLLMUL | RCC_CFGR_PLLSRC | RCC_CFGR_SW)) | (RCC_CFGR_PLLMUL12);
	RCC-›CR |= RCC_CR_PLLON;
	while((RCC-›CR & RCC_CR_PLLRDY) == 0)
	{

	}
	//switch system clock from HSI to PLL
	RCC-›CFGR |= (uint32_t) (RCC_CFGR_SW_PLL);
	while ((RCC-›CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_PLL)
	{
				
	}
	//clear CSSC bit 
	RCC-›CIR|=RCC_CIR_CSSC;
}

Заметьте, здесь работа с битами вообще не атомарна.
Дизассемблер приводить будем?

Разве?
А что вы сравниваете? MIPS и HAL? Чудесно просто!
Ничего личного, но чушь - ваша. За домашнее задание - ДВА!
Все эти моменты уже давно сгорели в бесконечных холиварах. PIC-и выглядят убого и точка.

Я сравниваю Microchip Harmony для MIPS и STM HAL для ARM.
Что то, что другое призвано заткнуть дыры в архитектуре.
Еще раз прошу Вас унять эмоции и перейти в конструктивное русло обсуждения...
Еще раз повторю. Это не попытка развести холливар.
Это попытка донести до пользователей STM32, что имеется серьезный источник ошибок,
связанный с неатомарностью битовых операций с регистрами ядра и периферии на
сравнительном примере.
Особенно для тех, кто хочет пользоваться исключительно CMISIS.

[scorpi_0n]

При чем здесь указанный Вами код?
Я говорил исключительно об атомарности битовых операций.

В STM32 для пинов есть BSSR, а для остального битбэндинг.

Заметьте, здесь работа с битами вообще не атомарна.

Ну и что? Во всех ли случаях нужна эта атомарность?

Я сравниваю Microchip Harmony для MIPS и STM HAL для ARM.

Для чего? Смысла с этого аж никакого. Особенно рьяно с этого смеются бывшие любители АВР, они вообще о Microchip Harmony впервые слышат.

Что то, что другое призвано заткнуть дыры в архитектуре.

Какие дыры? По сравнению с чем? С 8080, 8051 или PDP11?

Еще раз прошу Вас унять эмоции и перейти в конструктивное русло обсуждения...
Еще раз повторю. Это не попытка развести холливар.

Ещё раз, прекратите нести чушь, не разобравшись. Сиять своими незнаниями совсем необязательно.

Это попытка донести до пользователей STM32, что имеется серьезный источник ошибок,
связанный с неатомарностью битовых операций с регистрами ядра и периферии на сравнительном примере.
Особенно для тех, кто хочет пользоваться исключительно CMISIS.

Проблемы неатомарности присутствуют везде, и в PIC, и в AVR. Это отдельная тема и ARM здесь не исключение. А уж CMSIS здесь вообще ни причём. К чему вы это приплели совсем непонятно.