Мелкие вопросы по МК и ПЛИС.

[coredumped]

Вы когда нибудь брали "напрямую у производителя"?

Регулярно покупаем без посредников. Российскую фирму, скорее всего, пошлют, а если иметь представительство в ЮВА, то проблем никаких нет.

[Chettuser]

Я STM32L151 давно щупал на отладке от STM. Даже побаловался и выкладывал на mycontroller.ru. Только тот сайтец загнулся по ряду причин. И всё равно для простых вещей возвращаюсь к тому, что попроще - PIC12 и PIC16. Вот и думаю - у меня есть самособранный PICkit 2, зачем я буду делать еще один под другие камни? Поэтому буду пока смотреть в сторону PIC24HJ и PIC32 (ох чую, щас лоток с кошачим калом в мою сторону полетит!). Тем более что сравнивать PIC32 и STM32 как бы неправильно - разные они.

[coredumped]

Щас Химера запьет икру шампанским
А мне как-то пофиг... Каждый выбирает свой путь сам

[coredumped]

Что там еще есть необходимое для начальной настройки контроллера? Я посмотрел и ничего такого не обнаружил. Или я не прав?

А у Вас уже проект заработал? Когда заработает, при чем так, как задумано, а не как получилось, тогда можно будет сказать, что все правильно.
Что же касается system_init, лично я считаю, что проще взять готовое и проверенное решение, предоставленное CMSIS, чем биться головой об клавиатуру. Лучше потратить силы на сам проект, чем на разборку стартапа. Я еще понял бы Вас, если бы Вы писали свою OS. В следующих камешках, заметьте, настройка клоков несколько сложнее, но есть экселевский файлик, который генерирует код за Вас. Не думаю, что Вы сможете сделать лучше.

А сделаю так, как посчитаю нужным, и именно с помощью той информации, которую хочу получить в ответ.

Не понятно, какую Вы хотите информацию получить в ответ. Вы положили кусок какого-то кода, и просите ткнуть носом в ошибки. Причем неясно, чего Вы хотите добиться. Если хотите разобраться, то запускайте и отлаживайте. Или Вы хотите, чтоб мы разобрались за Вас? Укажите хоть исходные данные - кварц, внешний или внутренний генератор, желаемая тактовая частота.

[coredumped]

Нет, проект не заработал. Чтобы он заработал, мне предстоит разобраться с каждым битиком, а на это нужно уйма времени.

Чтоб заработал (в первом приближении) Ваш проект - времени нужно... приблизительно часа 2. При условии, что есть собранный прототип.

Смущает то, что видел в сети много примеров, где для аналогичных целей проделывается гораздо больше записей во всякие регистры. Я хочу, чтобы специалист по STM32 глянул на этот код и сказал, достаточно ли его для включения тактирования. Возможно, я что-то не учел.

Возьмите файл system_stm32f10x.c из CMSIS - там есть все необходимые для запуска операции. Файлик написан специалистами. Он 100% работающий. Что Вам еще нужно?

[Леонид Иванович]

Чтоб заработал (в первом приближении) Ваш проект - времени нужно... приблизительно часа 2. При условии, что есть собранный прототип.

Да, плата полностью собрана. Работаю над ней где-то 2 месяца, пока только мигаю светодиодом, и то мне не нравится текст работы с портами. Как Вы описываете порты I/O? Я хочу добиться того, чтобы описание соответствия сигнал-пин было в одном месте программы, а сменить порт и пин было делом одной строчки. Пока решил использовать для каждого пина шаблонный класс с перегруженными операторами присваивания. Память немного расходуется, зато очень наглядно. Что касается двух часов, то это шапкозакидательство, которое почему-то чаще всего позволяют себе адепты ARM. И почему-то они в основной массе хамы. Не знаете, почему?

Возьмите файл system_stm32f10x.c из CMSIS - там есть все необходимые для запуска операции. Файлик написан специалистами. Он 100% работающий. Что Вам еще нужно?

Мне нужно разобраться. Здесь утверждалось, что там есть что-то нужное кроме настройки тактирования. Почитал документацию на STM32, посмотрел внутренности этого файла (которые выглядят полным кошмаром), ничего нужного не нашел. Что имелось в виду?

[coredumped]

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

Вот, для примера (Cortex-M0):

Код: Выделить всё

#define PA_IN 	GPIOA->MODER = 0x002A0000
#define PA_OUT	GPIOA->MODER = 0x002A5555

#define IORD_PIN  	GPIO_Pin_10
#define IOWR_PIN  	GPIO_Pin_11

#define IORD_LO		GPIOB->BRR = IORD_PIN
#define IORD_HI		GPIOB->BSRR = IORD_PIN
#define IOWR_LO		GPIOB->BRR = IOWR_PIN
#define IOWR_HI		GPIOB->BSRR = IOWR_PIN

#define A0_PIN		GPIO_Pin_13
#define A1_PIN		GPIO_Pin_14
#define A2_PIN		GPIO_Pin_15
#define SET_ADDR_0 	GPIOB->BRR  = 0x0000E000
#define SET_ADDR_1 	GPIOB->BSRR = 0xC0002000
#define SET_ADDR_2 	GPIOB->BSRR = 0xA0004000

[Леонид Иванович]

В этом файле, помимо настройки клоков, устанавливается таблица векторов прерываний

Таблица векторов прерываний находится в другом файле - startup_stm32f10x_md_vl.s. Но как это использовать? Например, сейчас я пишу класс Wake-порта, где нужно задействовать прерывания UART. Сделать обработчик прерывания методом класса, насколько я знаю, невозможно (так как любому методу неявно передается указатель this, а обработчик прерывания не может иметь параметров). Как лучше поступить в такой ситуации?

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

Плохой пример. Магические числа, которые нужно вычислять в уме, очень много работы при переносе сигнала на другой пин и порт. Я хочу сделать, чтобы объявление пина выглядело так:

Код: Выделить всё

Gpio<PORTC, PIN9> Pin_Led; 
Pin_Led.mode(Mode::OUTPUT_2MHz);

А использование так:

Код: Выделить всё

Pin_Led = 1;

[coredumped]

Таблица векторов прерываний находится в другом файле - startup_stm32f10x_md_vl.s. Но как это использовать?

Обратите внимание на такой оператор
SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET;
или его аналог
NVIC_SetVectorTable( NVIC_VectTab_FLASH, 0x0 );

Что же касается С++, то я противник применения этого монстра во встроенных системах, поэтому не применяю. Разбираться с особенностями написания ISR в плюсах Вам прийдется самому. Или погуглите на буржуйских форумах, там извращенцев хватает.

[Chettuser]

Подкину корм тролям: 32F429IDISCOVERY

[coredumped]

Подкину корм тролям: 32F429IDISCOVERY

И фчём прикол? Очередная мормышка от ST. Очень правильная политика - делать девборды и продавать по цене почти равной себестоимости.
Я еще дарил бы эти платки ВУЗ-ам (может они так и делают?).

[Леонид Иванович]

Обратите внимание на такой оператор SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET;

Спасибо, но это не совсем то. Переместить всю таблицу векторов нужно, например, при написании бутлодера, но сделать обработчик прерывания членом класса это не поможет.

Что же касается С++, то я противник применения этого монстра во встроенных системах

Единственная радость от появления дешевых STM32 - это то, что для встроенных систем теперь тоже можно писать на C++. Лишняя производительность процессора и оверхед друг друга скомпенсируют. Структура программы, написанной на C++ намного красивее. Что касается оверхеда, то не так он велик, как про него обычно думают.

Или погуглите на буржуйских форумах, там извращенцев хватает.

Почему извращенцев? Вот Вам самому не противно общаться в таком стиле?

Верх идиотизма... никакой информации...

А у Вас верх хамства. Как это никакой информации? Сразу понятно, что на выводе светодиода устанавливается уровень логической единицы. При желании можно определить константы LED_ON, LED_OFF.

[Chettuser]

Там еще новинок много появилось. Они меняют железо на отладках - к чему бы это? Серии остаются те же M0, M3, M4.

[oleg110592]

а с STM32 разбираться и дорогущие средства покупать - это невыгодно ИМХО

Зачем покупать - спаять можно тоже и проще чем Pickit2 и 3:

Спойлер

извините за кривую пайку, но работает

[menzoda]

Единственная радость от появления дешевых STM32 - это то, что для встроенных систем теперь тоже можно писать на C++. Лишняя производительность процессора и оверхед друг друга скомпенсируют. Структура программы, написанной на C++ намного красивее. Что касается оверхеда, то не так он велик, как про него обычно думают.

Да и до этого можно было писать на Си++, лишь бы компилятор поддерживал. Есть проектик, тоже на АРМ, но стареньком ARM7TDMI работающем на 50 МГц, так вот там несколько мегабайт отменного говно-кода на Си++, и ничего - работает. Так что считаю, что на оверхед плюсов обращать внимание вообще не стоит.

А вот в остальном Си++ терпеть не могу. По сравнению с простым и лаконичным Си (хотя, недавно мое отношение к нему пошатнулось), Си++ представляет собой какую-то свалку различных механизмов и подходов, как говорится пытаясь и рыбку съесть и на хер сесть. Хотя, я бы не отказался от чего-нибудь типа С# для embedded применения, только без слишком уж "сахарных" конструкций.

[oleg110592]

имхо, скорее всего за С++ для микроконтроллеров будущее - по аналогии с PC где сейчас никто практически не пишет на чистом Си (разве что драйвера и пр. системное). Периферия микроконтроллеров становится все сложнее - фирме производящей микроконтроллеры остается написать библиотеку классов под свое железо и толпы программистов-ардуинщиков заполонят... И только истинные джедаи будут юзать чистый Си.
p.s. это так - бредовые фантазии
на авр уже народ Си++ пользуется: https://sites.google.com/site/vanyambau ... eka-ve_avr

[КРАМ]

по аналогии с PC где сейчас никто практически не пишет на чистом Си (разве что драйвера и пр. системное)

В аппаратурных приложениях написание "драйверов" и есть ОСНОВНАЯ ЗАДАЧА. Все остальное - тривиальный сервис и украшалки.
Ключевые параметры изделия обеспечиваются именно на уровне ядра РТОС.
Как бы не совершенствовались МК и не уменьшалась их цена, в конкурентной борьбе у эмбеддеров выиграет тот, кто сумеет выжать из МК по максимуму, обеспечив тем самым уникальность ТТХ конечного изделия.
Пользователи библиотек плюсов и шарпа будут лишь одними из толпы...

[coredumped]

К радости хомячков даже в ядре Linux появилась возможность писать дрова на плюсах. Мир сошел с ума, похоже
На плюсах, как я считаю, удобно писать всякие UI/GUI под ОС, особенно многооконные - тут ООП очень даже помогает.
Но делать классы для работы GPIO - это извращение. Опять же либы, нацарапанные на плюсах прячут механизмы работы с железом, что приводит к увеличению армии быдлокодеров. Это похлеще даже чем бездумное использование SPL для STM32. А потом народ недоумевает, почему на ARM с тактовой частотой 160МГц все работает не быстрее, чем на AVR

[Леонид Иванович]

Но делать классы для работы GPIO - это извращение.

Аргументируйте. Читаемость кода улучшается, а если не перегружать операторы, то оверхеда нет вообще - экземпляр класса создавать не нужно, а статические методы инлайнятся.

[Chettuser]

Вот вопрос в новой для меня области - для FPGA существует так называемая конфигурационная память. Как я понял она имеет протокол SPI. В связи с этим вопрос - почему применяется именно дорогущая память от производителя FPGA, а не любая доступная с SPI?