Где можно подчерпнуть библиотеку для процессора stm32L030?

Раньше библиотеки можно было скачать с сайта st.com
сейчас их там нет. например библиотека stm32f10x standard peripheral library была тут, сейчас там "SORRY, PAGE NOT FOUND". Что то поменялось у ST? Теперь библиотек нет? Или они их в куб убрали?

О чем вы? Как же нельзя?
Задача: допустим надо 0 и 6 выствить в "0", а 1 и 7 выставить в 1.
решение:
GPIOA->BSRR = GPIO_BSRR_BR0 | GPIO_BSRR_BR6 | GPIO_BSRR_BS1 | GPIO_BSRR_BS7;

Вы не понимаете моего подхода (( Еще раз:
Pin.hpp написан и отлажен один раз, после этого отложен в общую библиотеку, закинут в отдельную SVN-базу, поставлен аттрибут "только для чтения", его не нужно править от проекта к проекту. Вообще.
А ваши initRedLed, ledRedOff, ledRedOn зависят от проекта, в котором используются. Теперь понятно?

В одном и том же коде на одном пине все это может висеть по очереди? Вы об этом?
Если да, тут я бы использовал только класс Pin. Хотя впервые слышу о чем-то подобном ...


Мне до лампочки сколько там битов меняется, на производительности никак не сказывается. Проверено. Экономия на спичках.


Я никогда не стану такие тяжелые вещи городить в прерывании, для этого у меня есть rtos, практически в каждом проекте.
Ногодрыг и другая активная деятельность производится в теле задачи, которая ждет неких событий. В данном случае его формирует прерывание. Остальной код не страдает и не тупит.



Наш разговор переходит в разряд "глухого со слепым". Предлагаю заканчивать с этим и переключиться на что-то другое ))

Это нельзя сделать, точнее у меня это не реализовано по причине невостребованности, в классе имеющем дело с отдельными пинами. Если будет острая необходимость, то в принципе можно это сделать в таком же стиле:

Но один из светодиодов уезжает на другой порт и все ломается...

Сообщение отредактировал Reflector - Apr 19 2017, 10:12

Ни фига вы не слышите... спички спички.... вам говорият - каждая спичка на счету. Вы опять "Мне до лампочки.... на производительности никак не сказывается".... тут народ считает каждый дизасемблерную строку... вы опять - мне до лампочки, это спички... У меня крутой овернинженеринг, остальный сущности .... "Не хочу, не буду".

и такое было. Но хотя бы просто только 1-Wire, нужно менять направление пина.
вот с этим я согласен

да, стиль такой же... но... лень скролить всю тему... на вскидку прокоментирую.. поправте, если я не прав...
led1 - это переменная, структура или класс. pinMask - это поля этой структуры. что делает ваш код
1)led1.pinMask | led2.pinMask
2)<< 16
3) | led3.pinMask
4) | led4.pinMask
5) led1.base()
6) BSRR = чему-то там
вам наверно проще/быстрее 4 раза вызвать led*.on/off();

что делает мой код
1) BSRR = чему-то там

есть такое.... но не всё так печально. будет так
1)GPIOA->BSRR = чему-то там
2)GPIOB->BSRR = чему-то там
всё ранво есть выгода. и при проектировании я учитываю эту особенность МК и стараюсь вешать на один порт.

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

Уходите в asm, коли выбрали проц, в который не влазит код.
Чесс слово, это уже похоже на нытьё ... тока без обид



Никаких проблем: прямо в коде вызываем соотв. метод, отвечающий за направление пина. В моем случае вместо

вызываем

ожидал tакой ответ.... просто объявите пин LedOpenDrain pin, меняете у него выход на вход.... и он уже не выход c ОК, а вход. Конечно работать будет. Но объект класса LedOpenDrain - есть входной пин. Как то уши режет.

Я же уже сказал, что для подобной задачи есть более "базовый" класс Pin, его как раз и нужно использовать для этой задачи
или пойти чуть дальше и создать от Pin класс-наследник, который будет реализовывать функционал двунаправленного пина более красиво. Тут уже все упирается в вашу фантазию.

Теперь понятно?

давно уже современные компиляторы сравнялись (или почти) с асмом. смысла нет. И зачем? Мне вполне комфортно в с/с++. В тесноте, да не в обиде.

Типа, съехал с темы ... Чтож, оно и к лучшему )))

Нет, все совсем не так. Как я ранее говорил, в моем классе нет переменных, они есть у Forger. Сам классс выглядит следующим образом:

Так что pinMask - это обычная константа и генерируемый код будет в точности как у тебя.


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

c какой темы? я уже всё сказал. сам же говоришь
зачем мне асм? я вижу в твоем коде сплошной оверинжененринг. я это уже говорил. то, что можно сделать бистро и просто - у тебя разрослось в классы и шаблоны... в сущности... ты считаешь - что это хорошо- твоё право. я тоже пользую ООП в МК. но использование ООП - не значит отказ от 0b00001000. Ты, в ущерб производительности и компактности пишешь классы, Да пожалуйста, пиши. Но ты при этом говоришь "Чо экономить на спичках, хватит ныть и идите в асм". Что-то мне про ООП доказываешь. что тут доказывать - там где надо я сделаю и классы, и шаблоны и паттрены. Но в некоторых случаях делаю прямую запись в регистры, в некоторых в какие-то булевые операции в которых удобно литералы b использовать.

Пока что в твоём подходе использовать ООП всюду, отвергая литералы, - я не вижу смысла и удобства. У тебя в майне 3 строчки - у меня в майне 3 строчки. У тебя всё в майне понятно и прозрачно, у меня в майне всё понятно и прозрачно. Я перенесу на другую платформу - поправлю дефайны, майн не буду трогать. ты перенесешь на др платформу - так же будешь писать новый Pin.hpp, майн не изменишь. Если платформа та же... ноги другие.. ты в дефайнах исправишь пин и порт, я в дефайне изменю пин и порт. О чем спор? В удобстве стиля? не вижу преимуществ. а вот в производительности - тут можно поспорить. Но для тебя это экономия на спичках... так что дальше можно не дискутировать

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

Ну что ж, еще раз Есть два класса: PinX и GpioX. Первый имеет дело с одним пином, второй с портом в целом, но пишет/читает только в область ограниченную маской. Теперь подумай сколько ног используется при динамической индикации и какой класс больше для этих целей подходит

Сообщение отредактировал Reflector - Apr 19 2017, 12:28

Я раньше писал код для работы с пинами (да и не только) по практически точно такому же принципу, что и вы, но ушел на нынешнее решение.
Поэтому я отлично вижу преимущества, скорее всего, потому, что я пробовал и так и сяк...

Короче. Я поделился своим опытом, показал примеры. Буду рад, если кому-то пригодится

Интересно, как это так? У тебя же вроде тоже нет общего базового класса.

А посмотреть на уровень выше?
Там есть pin.h, который включает нужный pin_xxx.h, в зависимости от типа контроллера. Для F1 другой вариант, для F0 третий.


Это всё замечательно, но как это относится к классу управления ножкой микроконтроллера?


Ну вот, например. Есть класс-АЦП на SPI. Он оформлен в виде шаблона, принимающего параметр - ножку CS. (Ссылка на SPI передаётся в конструктор). Очень удобно.
Я пишу в файле описания железа:



И потом использую. Разве не удобно?



Никакого ещё одного слоя, как вы видите из примера выше. Вместо вашего макроса adc_cs_on у меня в коде класса Adc будет CS:On();


Я уже ответил выше, но повторюсь. У меня включается файл pin.h, который в свою очередь включает нужный файл в зависимости от типа контроллера. Я дал ссылку на конкретную реализацию, чтобы люди не заблудились в репозитории. Но получил обратный эффект.

Что касаемо переносимости между контроллерами, то она тоже имеется (хотя и не полная). Для всех контроллеров, которые я использовал, я писал свой вариант pin.h.

А, и про это:

Насчёт хрени - я вас чем-то обидел? Откуда такие бурные эмоции?
А насчёт "не заработает даже на всех камнях F4" - буду благодарен за информацию о косяке.

Нет, у меня всего один класс и отдельно от него функция инициализации.


Это хорошо, но с дебагом все равно нужно что-то делать