Изучаем STM32 Cortex M3

[olegprom19]

А менять придется часто, потому что на большинство ИОН максимально допустимое входное напряжение порядка 6...7 вольт. Обычно они рассчитаны на 5 вольт.

))
чет не посмотрел входное напряжение

[dkm]

с выходным напряжением 2,500В. Ни разу не подводили. Только не забывать на выходе прицепить конденсатор 1мкФ. Когда начинал с ними работать, поначалу недооценил значение этого конденсатора, не поставил его. И получил неслабый возбуд. В общем, рекомендую.

В даташитах на некоторые стмки стоит и нижнее ограничение,что-то около Vd-0.7v. Не помню уже с какой серией вышел косяк (шум и нелинейность), сейчас всегда ставлю ОУ, поднимаю до 3В, так АЦП стабильнее работает.

[olegprom19]

В даташитах на некоторые стмки стоит и нижнее ограничение,что-то около Vd-0.7v. Не помню уже с какой серией вышел косяк (шум и нелинейность), сейчас всегда ставлю ОУ, поднимаю до 3В, так АЦП стабильнее работает.

Для STM32F103
VDDA ADC power supply Min=2.4V Max=3.6V

[eddy]

Что-то рано я насчет CDC радовался: нормально работает он только если данные отправлять мелкими посылками (меньше 64 байт). Если же я хочу "за один присест" передать на МК больше 64Б данных, получается полная лажа! Приходящие данные складываю в буфер 256 байт длиной, а в основном цикле проверяю: если какие-то данные в буфере есть, считываю их:

int USB_receive(char *buf, int bufsize){
    if(!bufsize || !idatalen) return 0;
    uint16_t epstatus = USB-›EPnR[2];
    USB-›EPnR[2] = SET_STALL_RX(epstatus);
    USB-›CNTR = 0;
    int sz = (idatalen › bufsize) ? bufsize : idatalen, rest = idatalen - sz;
    memcpy(buf, incoming_data, sz);
    if(rest › 0){
        memmove(incoming_data, &incoming_data[sz], rest);
        idatalen = rest;
    }else idatalen = 0;
    USB-›CNTR = USB_CNTR_RESETM | USB_CNTR_CTRM;
    usb_isr();
    epstatus = USB-›EPnR[2];
    USB-›EPnR[2] = SET_VALID_RX(epstatus);
    return sz;
}

В начале пробовал установить NAK_RX - та же проблема: все, что дальше 64 байт тупо теряется. Т.е. пока я в этой функции копирую уже принятые предыдущие 64 байта, новые идут нафиг. Если с компьютера повторить отправку совершенно тех же данных, то "добьется" недостающее. Но если отправить другой буфер, ничего не пройдет.

Чертовщина какая-то! Как же правильно успевать обрабатывать-то эти данные?

[eddy]

"Методом Монте-Карло" починил. Остается еще добавить возможность отправки больше чем 64 байт данных и более-менее причесать код.
Эмулятор ch340 я делать передумал: там вообще никакой не CDC, все реализовано через vendor requests.
В общем, CDC в виде эмулятора PL2303 за глаза хватит. Главное - добить его, чтобы надежно работал. Пока что объем кода - 5кБ.

[olegprom19]

а зачем эмулировать "другой чип" есть же драйвер STMовский
или это не для ПК? а для консолей

[eddy]

есть же драйвер STMовский

Хочется мне так. Тем более, под приставками эта железка работает сразу. А с ST'шным "драйвером" оно через одно место делалось (одну железку делал именно так, коллега три дня промучился, чтобы оно с приставкой "срослось").
Хотя, конечно, мне на приставки наплевать — я не геймер — но мало ли...
Интересно, кстати, что когда я возился недавно с STM32F103, в качестве линкера был ld, а если выбирал вместо линкера gcc, то код внезапно "толстел" на ~1кБ! С STM32F042 обратная ситуация: попробовал на стадии сборки вместо gcc использовать ld, и код на 1кБ увеличился. Фигня какая-то непонятная - вроде бы объектники одного размера, elf тот же самый... Как будто бы ld плюется отладочной информацией...

[sat_art]

Если установлен Read protect Level 2 чип как то стирается?
STM32F405

[NewWriter]

Нет, всё, после этого - кирпич. Не работает отладка, нет стирания, не возможна загрузка из любых загрузчиков, кроме написанного бутлоадера на флеше.
В инете писали, что можно стереть получасовым облучением рентгеном, но ХЗ, лично не проверял. Да и не факт, что МК после будет нормально в целом работать.
Да и для собственного здоровья небезопасно.

[sat_art]

А изнутри (из самой программы) снять можно или нет?