GD32F330 - новые мк от GigaDevice

[STM32F0]

через бутлоадер это и удобней и дешевле

Может ещё и задротный линух поставить?

[Alex9797]

Проблема не в софте

Да, в той теме особенность была в том, что я ведь имел дело не с новыми процессорами, а с уже прошитыми, и залоченными. И вполне возможно, что уровень защиты памяти там был установлен level 2 - когда невозможно не только чтение памяти, но даже перепрошивка. То есть, при попытке повторной прошивки проц просто превращается в кирпич. И при этом неважно, каким программатором и каким софтом это делалось.
Кстати, вернувшись снова в ту тему по ссылке - ведь первоначально ST-Link все же видел этот GD32, а вот после стирания памяти или попытки перепрошить - переставал видеть вовсе.
То есть, новый проц прошился бы ST-Linkом без проблем.

[pamalofeev]

Проблема не в софте, а в мозгах недопонимающего "предсказателя". Нормальный ST-Link запрашивает идентификатор подключенного МК. У GD он стопудово другой, посему нормальный СТ-Линк его и не опознает.
Левые СТ-Линки не запрашивают идентификаторов.
Так что проблема как раз в железке.

Китайцы пишут, что по f130 серию включительно можно шить любым st-link, а новые серии начиная с f330 клонами.

[eddy]

Может ещё и задротный линух поставить?

Ну не в мелкомягком же мозголожестве работать!

[eddy]

Нормальный ST-Link запрашивает идентификатор подключенного МК.

Идентификатор как раз-таки софт запрашивает. В stlink 5 дней назад последний коммит сделали, надо глянуть, может и поддержку gd автор добавил.

[akegor]

не в мелкомягком же мозголожестве работать!

"А месье знает толк в извращениях!"(с) Харчи, пардон, мозголожества перебирает!

[ptr]

Ну не в мелкомягком же мозголожестве работать!

Везде приходится. Тот же STM8 кодить при помощи SDCC - удовольствие не слабонервных. Ладно хоть в 3.7 кодогенерацию до ума довели. Но человеческой внутрисхемной отладки то все равно нет. Вот и вынуждены COSMIC под виндой пользовать.
Я уже не говорю про случаи, где сбор информации с МК должен выполняться обязательно ни C# в MS SQL БД и агрегироваться в MS SSAS. Только потому, что так хочет заказчик, которому радостно MS SQL Enterprise под это дело продали.

[eddy]

Тот же STM8 кодить при помощи SDCC - удовольствие не слабонервных

УМВР. Так что не надо тут! Да, до gcc ему жуть как далеко: оптимизация под STM8 у SDCC, заточенного под 8051, вообще никакая. Ну да ладно — где надо, делаю оптимизацию руками. Всяко не говно мелкомягкое ворочать, где даже погрепать в исходниках нужные переменные не получится нормально!

Но человеческой внутрисхемной отладки то все равно нет.

А errata почитать не судьба? Зачем внутрисхемная отладка, если перед глазами есть даташит, RM и errata? Отладка нужна лишь на стадии самопальных алгоритмов, а там UART'а за глаза!

сбор информации с МК должен выполняться обязательно на C# в MS SQL БД и агрегироваться в MS SSAS

Не завидую я погромистам: они хуже проституток! Проститутки хоть свалить могут, а погромисты свою задницу подставляют постоянно кому угодно, лишь бы бабки платили!!!

[STM32F0]

Зачем внутрисхемная отладка

Зачем отладка, зачем оптимизация, зачем, зачем... зачем такие трудности, ради красных глаз и логотипа тупого пингвина?

Отладка нужна лишь на стадии самопальных алгоритмов, а там UART'а за глаза!

Совсем ардуинщик?

[jump]

погромисты свою задницу подставляют постоянно кому угодно, лишь бы бабки платили!

недавно ты распинался, что погромист...