Artery AT32F403A. Работа с CAN

[sdy]

Побольше бы статей про китайские чипы и их возможности, а также опыт работы с ними.Кстати, Artery же китайский производитель или все таки тайваньский?

Что насчет поставок этих контроллеров в РФ и самое главное как поддержка осуществляется?

[arty_morris]

Не знаю, разрешено ли здесь писать информацию, если что, пусть модераторы уберут.
Напишите ему: e-mail: [e-mail]
Они занимаются их продажей, очень вменяемые люди

[rusEFI]

Нива и большая ГАЗель ездят на artery. Уаз на geehy

[andrey239]

https://habr.com/ru/articles/709392/

[andrey239]

Прошивка этом примере случайно не запустится ли на stm32? Какое-то лукавство по-моему знакомиться с artery в отвязки от факта 99% совместимости в stm32/geehy/gigadevices?

По-моему интересная статья для хабра - это обзор различий stm32 и трёх (или более клонов), и написание кода, который определяет производителя чипа по нюансам поведения. В стиле аналогичной работы, проделанной по stm32f103

[arty_morris]

Не запустится. И причем здесь stm? На него болт положен.

Какие ещё нансы поведения? У меня есть задача, я её решил и делюсь, так как информации нет об этом микроконтроллере

[andrey239]

ой. https://www.arterytek.com/download/MG0007_Migrating_from_SXX32F103_to_AT32F403A_EN_V1.0.8.pdf я в нём вижу "The AT32F403A series microcontrollers are basically compatible with the SXX32F103 series" - т.е. artery какую-то связь с stm32 улавливает?

[arty_morris]

Ну если откроете, то поймёте что нет. Там описан переход с одной платформы на другую, куцый кстати

[lamerok]

На самом деле, отличий не так много, при должном подходе, можно одну прошивку и туда и туда прошивать, что собственно многие и делают. Появляется полная взаимозаменямость, одно можно на другое просто менять. Потому что хоть и "На stm болт положен.", их наделали столько, что еще лет на 50 хвтатит.

[arty_morris]

Ну если не учитывать что stm стоит на порядок дороже, и сложности с их покупкой (Али не в счёт).

Можно наверное универсальную сделать. Это мне не требуется

[lamerok]

Вы опять в обработчик прерывания не проверяете, что прерывание разрешено.

Так как один обработчик прерывания используется для обработки нескольких, всегда надо проверять, разрешено ли конкретно нужное, иначе когда нить у вас все свалится.

[arty_morris]

Всё проверено. Ничего не отваливается. Это ещё при работе с USB выяснил. Поэтому тут ничего не писал

[lamerok]

Пока, вы что-то не решите поменять. Когда -то, когда был молод, тоже все проверил, и ничего не отваливалось, потом, поменял, и тоже как бы не отваливалось, а у заказчика отвалилось. Лучше сразу сделать правильно.

[arty_morris]

Заказчик я сам. И я сразу делаю правильно, как мне нужно для работы программы

[lamerok]

Еще,

uint8_t usb_ready = 0;

Надо поставить volatile, иначе при оптимизации может тоже все рухнуть.

Вообще, все что в прерываниях изменяется, ставьте volatile.

Ну и общее, глобальные переменные - зло.

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

Правильно в прерывании послать событие, а событие отработать в отдельной задаче, уже вне прерывания.

[arty_morris]

Они же всё равно выполнятся последовательно. Не вижу особой необходимости всё выбрасывать в отдельные функции. Но и не исключаю что так тоже можно

[aabzel]

У Artery микроконтроллеров, как и у STM аппаратные подсистемы (I2S, UART, CAN и т п) выведены только на очень ограниченный набор пинов.
Если схемотехники ошибутся в топологии, то вы не сможете пользоваться I2S UART или I2S. В этом плане Artery сильно проигрывают микроконтроллерам от Nordic или TI где, например, аппаратный I2S_BCLK можно назначить вообще на любой пин.