Если внимательно посмотреть диаграмму, AIRDRAG входит в ENERGY FOR MOVING VEHICLE.
Стоит добавить, что в отсутствии рекуперации энергии при торможении, появится добавка затрат энергии на разгон. Вот только для грузовиков равномерно ползущих по автострадам эта составляющая не так велика.
Не только в ошибках дело. Опечатку в адресе или битовом поле вы найдете быстро. Да и я давно их уже не встречал.
Например, у Stellaris не все аппаратные возможности реализуются через SPL.
А про примеры, я в связке SPL + LwIP ловил ошибку утечки памяти, которая приводила к вылету через неделю (частота опросов была не высока). До первого вылета даже не проверял использование памяти. Всего ушло около 2 недель на поиски. Пример был с сайта ST.
Не вижу больших преимуществ. Все-таки, инициализация периферии выполняется один раз (бывают, конечно исключения), а потом идет работа с основной программой. Зачем изучать библиотеки сторонних разработчиков, которые не дают ощутимых плюсов?
Да и либы для работы с внешней периферией обычно делаются с использованием библиотек производителя.
STM32 стали популярны до появления STM32F4. Я думаю, что важную роль играет цена и доступность в России.
Цена отладочной платы очень важна при изучении. Ни кто не захочет без серьезных на то причин покупать плату за 500$, а свою делать не каждый рискнет (да и цена выйдет не малой).
1) Не согласен с вашей категоричностью.
Я считаю, что на первых порах важно помнить про то, что мы работаем со спецрегистрами. Магические числа, лично мне, в этом помогают.
До знакомства с библиотеками я делал немного иначе:
#define RCCAHB1_ENR (*(unsigned long*)0x40023830)
#define RCCAHB1_PORTD 0x8
//Enable port D clocking
RCCAHB1_ENR |= RCCAHB1_PORTD;
Как вы, наверное, знаете в большинстве начальных программ для МК быстро конфигурируется периферия, и дальше уже используются дефайны для работы с определенными регистрами (даже без использования библиотек). И этих регистров не так много. Так вот, используя определения, люди часто забывают о том, что на самом деле происходит с их коде. На курсах программирования МК часто встречались случаи, когда студенты делали записи:
А по прошествии недели спрашивали: «Какой хэддер нужно подключить, чтобы заработала функция EnableLED1?».
Выносить что-либо в макросы стоит только когда вы на 100% уверены, что знаете как это работает.
Все выше сказанное только мое мнение, а не руководство к действию. Каждый сам решает как ему оформлять код. По этому поводу написано миллионы страниц текста.
2) По поводу:
RCC->AHB1ENR |= RCC_AHB1ENR_IOPDEN
Есть несколько соображений:
1. Нужно немного разобраться с библиотекой, покопаться в примерах и т.д. Если пытаться все делать сразу — будет каша в голове (ИМХО). Я предпочитаю начать с документов.
2. Я стараюсь описать принцип программирования МК на примре STM32, а не описать библиотеку и возможности STM32. У TI, например, библиотека устроена совершенно иначе.
3 Ваш пример не показателен. Часто встречается ошибка — путаница с GPIO_PinSource8 и GPIO_Pin_8.
4. Не стимулирует. Вот пример который компилируется но не cработает:
RCC->AHB1ENR |= RCC_AHB1Periph_SRAM1;
После 3 инициализаций периферии люди автоматически начинают экстраполировать методы инициализации. Это не верно. Главный посыл такой: сначала документация — затем программирование.
Для этого я специально указал, что лучше использовать F2 или F4:
Если у вас есть в наличии любая другая плата на базе STM32F2xx/STM32F4xx, вы сможете работать с ней.
Вообще говоря, складывается впечатление, что на F1 ST «обкатывали» технологии и накапливали проблемы и баги. F2 сильно отличается от F1, а вот последующие уже очень похожи.
К сожалению, невозможно было выбрать один универсальный МК. Также не вижу смысла писать обязательные требования по какой-то определенной отладочной плате.
Моей задачей было объяснить принцип, по которому стоит начинать писать программу, а не перечислить конкретные регистры. Может быть получилось не очень хорошо.
На счет магических чисел я тоже вас поддерживаю, но считаю, на первых шагах код должен выглядеть именно так. Отчасти из-за того, что при желании воспользоваться «готовым» куском кода вам придется лезть в описание регистров МК.
В дальнейшем, конечно же, в своих постах я уйду от прямого ковыряния в регистрах и буду пользоваться библиотекой.
Стоит добавить, что в отсутствии рекуперации энергии при торможении, появится добавка затрат энергии на разгон. Вот только для грузовиков равномерно ползущих по автострадам эта составляющая не так велика.
Например, у Stellaris не все аппаратные возможности реализуются через SPL.
А про примеры, я в связке SPL + LwIP ловил ошибку утечки памяти, которая приводила к вылету через неделю (частота опросов была не высока). До первого вылета даже не проверял использование памяти. Всего ушло около 2 недель на поиски. Пример был с сайта ST.
Да и либы для работы с внешней периферией обычно делаются с использованием библиотек производителя.
Цена отладочной платы очень важна при изучении. Ни кто не захочет без серьезных на то причин покупать плату за 500$, а свою делать не каждый рискнет (да и цена выйдет не малой).
cn0086.info/%E5%B7%A5%E5%85%B7%E5%88%B6%E4%BD%9C/repaire-j-link
www.ebay.com/sch/i.html?_from=R40&_trksid=m570.l2736&_nkw=j-link
В данном случае разницы нет.
Хитрости с указателями. Можно почитать тут.
publib.boulder.ibm.com/infocenter/comphelp/v101v121/index.jsp?topic=/com.ibm.xlcpp101.aix.doc/language_ref/cv_qualifiers.html
В первом примере как-то не понадобилось. Но вот когда дойдем до считывания данных из регистров — вот тогда затронем этот вопрос.
Да и клонов от дружелюбных нам соседей предостаточно.
Я считаю, что на первых порах важно помнить про то, что мы работаем со спецрегистрами. Магические числа, лично мне, в этом помогают.
До знакомства с библиотеками я делал немного иначе:
Как вы, наверное, знаете в большинстве начальных программ для МК быстро конфигурируется периферия, и дальше уже используются дефайны для работы с определенными регистрами (даже без использования библиотек). И этих регистров не так много. Так вот, используя определения, люди часто забывают о том, что на самом деле происходит с их коде. На курсах программирования МК часто встречались случаи, когда студенты делали записи:
А по прошествии недели спрашивали: «Какой хэддер нужно подключить, чтобы заработала функция EnableLED1?».
Выносить что-либо в макросы стоит только когда вы на 100% уверены, что знаете как это работает.
Все выше сказанное только мое мнение, а не руководство к действию. Каждый сам решает как ему оформлять код. По этому поводу написано миллионы страниц текста.
2) По поводу:
Есть несколько соображений:
1. Нужно немного разобраться с библиотекой, покопаться в примерах и т.д. Если пытаться все делать сразу — будет каша в голове (ИМХО). Я предпочитаю начать с документов.
2. Я стараюсь описать принцип программирования МК на примре STM32, а не описать библиотеку и возможности STM32. У TI, например, библиотека устроена совершенно иначе.
3 Ваш пример не показателен. Часто встречается ошибка — путаница с GPIO_PinSource8 и GPIO_Pin_8.
4. Не стимулирует. Вот пример который компилируется но не cработает:
После 3 инициализаций периферии люди автоматически начинают экстраполировать методы инициализации. Это не верно. Главный посыл такой: сначала документация — затем программирование.
Очень помогает в работе.
Иногда примеры для среды разработки делают совершенно другие люди.
Вообще говоря, складывается впечатление, что на F1 ST «обкатывали» технологии и накапливали проблемы и баги. F2 сильно отличается от F1, а вот последующие уже очень похожи.
К сожалению, невозможно было выбрать один универсальный МК. Также не вижу смысла писать обязательные требования по какой-то определенной отладочной плате.
Моей задачей было объяснить принцип, по которому стоит начинать писать программу, а не перечислить конкретные регистры. Может быть получилось не очень хорошо.
На счет магических чисел я тоже вас поддерживаю, но считаю, на первых шагах код должен выглядеть именно так. Отчасти из-за того, что при желании воспользоваться «готовым» куском кода вам придется лезть в описание регистров МК.
В дальнейшем, конечно же, в своих постах я уйду от прямого ковыряния в регистрах и буду пользоваться библиотекой.