[Forger 17]

34 minutes ago, AlexandrY said:

Автоматизация генерации сорсов - вот показатель.

Да, показатель очевидный: читать такие "сорцы" обычный человек нормально уже не сможет  Молчу уже про отладку по таким "сырцам" 

Популярный пример - куб: особо править нагенерённый код напрямую нормально уже нельзя, но и разбираться в этой "каше" - тоже занятие не каждого 

[AlexandrY 3]

3 hours ago, Forger said:

Да, показатель очевидный: читать такие "сорцы" обычный человек нормально уже не сможет  Молчу уже про отладку по таким "сырцам" 

Популярный пример - куб: особо править нагенерённый код напрямую нормально уже нельзя, но и разбираться в этой "каше" - тоже занятие не каждого 

Разницу то почувствуйте. Одно дело свои скрипты и другое дело чужие закрытые тулсы. 
Сорсы нагенеренные своими скриптами смотреть для анализа нет особой причины.
  

[Forger 17]

17 minutes ago, AlexandrY said:

Сорсы нагенеренные своими скриптами смотреть для анализа нет особой причины.
  

Честно говоря, еще не приходилось городить скрипты для своих исходников. Как-то нужды не было 

Поэтому трудно судить 

 

[Сергей Борщ 119]

20 часов назад, Forger сказал:

Популярный пример - куб: особо править нагенерённый код напрямую нормально уже нельзя, но и разбираться в этой "каше" - тоже занятие не каждого 

Дам контрпример: ассемблерный выхлоп компилятора C/C++ править напрямую нормально уже нельзя (не имеет смысла), но разбираться в этой "каше" - не представляет сложностей для обладающего знаниями чуть выше начальных.

[Forger 17]

38 minutes ago, Сергей Борщ said:

Дам контрпример: ассемблерный выхлоп компилятора C/C++ править напрямую нормально уже нельзя (не имеет смысла), но разбираться в этой "каше" - не представляет сложностей для обладающего знаниями чуть выше начальных.

• Неравноценное сравнение: бесплатный куб, годящийся максимум для пилотных и демо-проектов, vs полноценный коммерческий компилятор.
• Компилятор (даже бесплатный gcc) с почти 100% вероятностью дает на выходе правильный код без багов, куб, увы, не может похвастать таким результатом
• Ходить по ассемблерному коду - занятие вынужденное и довольно редкое (по крайней мере у меня), а вот ходить по C-коду, накомпиленному кубом, придется по-любому, и довольно часто.

 

[AlexandrY 3]

46 minutes ago, Forger said:

• Неравноценное сравнение: бесплатный куб, годящийся максимум для пилотных и демо-проектов, vs полноценный коммерческий компилятор.

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

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

[Forger 17]

26 minutes ago, AlexandrY said:

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

Судя по свежему mbed у меня сложилось впечатление, что те очень упорно пытаются соорудить что-то подобное arduino - снижают "порог вхождения", чуть ли не до уровня учеников начальной школы 

Из любопытства не удержался и покопался в сырцах .... очень быстро пришёл  

[haker_fox 60]

On 11/28/2018 at 10:01 PM, Forger said:

то применяю эту схему уже несколько лет и весьма доволен

Извините, что спустя столько времени спрашиваю, но... есть ли способ в ваших драйверах настроенные пины объеденить в порт? Например, PA7, PB3, PC0 для трёхбитного параллельного порта?

 

Решали ли вы задачи, когда физически пины были "раскиданы" по разным микросхемам (hc595, pca9534, микроконтроллер), и их нужно было собрать в один параллельный порт? Не спрашивайте, зачем это нужно)))) просто в моей практике так недавно получилось.

 

Предполагается ли вообще какая-то абстракция касательно физического расположения пинов? Т.е., теоретически, часть пинов может быть расположена хоть за сотню километров на другом МК, прикрученному к текущему МК с помощью сети.

[jcxz 185]

37 минут назад, haker_fox сказал:

Предполагается ли вообще какая-то абстракция касательно физического расположения пинов? Т.е., теоретически, часть пинов может быть расположена хоть за сотню километров на другом МК, прикрученному к текущему МК с помощью сети.

Ну а в чём проблема? Написали драйвер вашего девайса (параллельный порт) с API с необходимым набором функций (установка состояний линий параллельного порта, чтение этих линий и т.п.) и работайте с этим портом через это API. А внутри драйвера уже делаете передачу куда и чего нужно.

[Forger 17]

1 hour ago, haker_fox said:

Извините, что спустя столько времени спрашиваю, но... есть ли способ в ваших драйверах настроенные пины объеденить в порт? Например, PA7, PB3, PC0 для трёхбитного параллельного порта?

Нет, мне эта возможность не нужна, т.к. очень сильно ухудшает читаемость кода.

Ногодрыг (какой-нить программный SPI) визуально читать проще, когда каждый пин дергается отдельно, а не группой.

Другими словами: незначительное ускорение при групповом ногдрыге против раздельного значительно проигрывает в читаемости кода. Для меня лично читаемость и простота кода - на первом плане..

Исключение составляет обращение ко всему порту (16 бит), но такие ситуации практически никогда у меня не бывают, т. е. программный параллельный ногодрыг нигде не использую. А вот медленный последовательный (типа SPI) - очень часто.

С другой стороны ничто не мешает расширить функционал класса Pin своим новым, инкапсулирующим в себе сразу несколько пинов, но это у меня делается иначе (подробности ниже).

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

		
	Hardware::DigitalOutputPin<PC14> 	pinLOAD;
	Hardware::DigitalOutputPin<PC13> 	pinCLK;
	Hardware::DigitalOutputPin<PB15> 	pinDIN;

.....
      
	// Update Leds Registers
	pinDIN.setToHigh();
	for (auto ledIndex = 0; ledIndex < kBacklightAmount; ++ledIndex)
	{
		pinCLK.setToLow();
		if (((1UL << ledIndex) & ledsValue) == 0)
			pinDIN.setToLow();
		else
			pinDIN.setToHigh();
		pinCLK.setToHigh();
	}
                             
	pinLOAD.setToHigh();
	pinLOAD.setToLow();
                             
                             

 

Quote

 

Решали ли вы задачи, когда физически пины были "раскиданы" по разным микросхемам (hc595, pca9534, микроконтроллер), и их нужно было собрать в один параллельный порт? Не спрашивайте, зачем это нужно)))) просто в моей практике так недавно получилось.

Нет, такой необходимости никогда не было, и решаю это иначе: у меня управление всякими внешними микросхемами (и устройствами) строго изолировано от других программных модулей проекта.

Общение между модулями строго описано через некие "интерфейсы" (по аналогии как у Qt: слоты/сигналы), на базе делегатов (увы в плюсах они не встроены, как в C#, поэтому используются соотв. шаблоны, но компилятор обязан поддерживать как минимум C++11 ).

Поясню: если какому-то модулю нужно узнать напряжение некого внешнего АЦП, то этот модуль обращается к тому, кто целиком "владеет" этим АЦП.

По факту это выглядит это довольно абстрактно - просто один модуль запрашивает у другого, скажем, "напряжение питания" - getBatteryVoltage().

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

 

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

Поэтому мне никогда не приходится изолировать, например, USART мьютексами - все очень просто: у него всегда только ОДИН владелец. Нет конкурентного доступа - нет проблем ;)

 

Подведу итог: каждый физический интерфейс, порт, пин, микросхема и т. д. у меня закреплены за своими модулями (в соотв. секциях private), которые целиком за них отвечают. Общение между модулями через делегатов (интерфейсы signal/slot).

Для изоляции сложной реализации модулей от "посторонних" используется что-то типа паттерна "фасад", синглтонов нет, глобальных объектов нет. Полный порядок и нирвана 

 

Quote

 

Предполагается ли вообще какая-то абстракция касательно физического расположения пинов? Т.е., теоретически, часть пинов может быть расположена хоть за сотню километров на другом МК, прикрученному к текущему МК с помощью сети.

Нет, это строго запрещено. Экземпляры все пинов (интерфейсов, периферийных узлов) находятся в секции private соотв. класса. НИКТО, кроме владельца, не может к ним обращаться напрямую. В этом весь смысл!

Иначе в проекте начнется полный бардак и баги на абсолютно ровном месте 

[Forger 17]

47 minutes ago, jcxz said:

Ну а в чём проблема? Написали драйвер вашего девайса (параллельный порт) с API с необходимым набором функций (установка состояний линий параллельного порта, чтение этих линий и т.п.) и работайте с этим портом через это API. А внутри драйвера уже делаете передачу куда и чего нужно.

Это, кстати, один из самых очевидных примеров инкапсуляции ;)

[ViKo 1]

34 минуты назад, Forger сказал:

Нет, мне эта возможность не нужна, т.к. очень сильно ухудшает читаемость кода.

Ногодрыг (какой-нить программный SPI) визуально читать проще, когда каждый пин дергается отдельно, а не группой.

Другими словами: незначительное ускорение при групповом ногдрыге против раздельного значительно проигрывает в читаемости кода. Для меня лично читаемость и простота кода - на первом плане..

Для STM32 - элементарно, если для одного порта.
 

#define GPIO_LOW_HIGH(Port, Mask_Low, Mask_High)        \
    GPIO##Port->BSRR = (Mask_Low) << 16 | (Mask_High)

 

[Forger 17]

21 minutes ago, ViKo said:

 

#define GPIO_LOW_HIGH(Port, Mask_Low, Mask_High)        \
    GPIO##Port->BSRR = (Mask_Low) << 16 | (Mask_High)

 

Хрен редьки не слаще - то же самое прекрасно делается прямым обращением к соотв. регистрам прямо в коде.

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

 

 

 

 

[ViKo 1]

Потому и назвал так, как идут параметры. И лезть никуда не надо.

[Forger 17]

13 minutes ago, ViKo said:

Потому и назвал так, как идут параметры. И лезть никуда не надо.

 

Уж извините за прямоту, но "GPIO_LOW_HIGH" вообще ни как не говорит от том, какие параметры ожидает, ну ни разу ))

Хотя, уверен, что для вас это как раз очевидно 

 

У меня же все функции (и макросы, если есть) имеют максимум два входных параметра, да и то крайне редко. А тут аж три!!! Имхо - перебор 

Поэтому тому, у кого голова ни разу не энциклопедия (как у меня), в таком случае все равно придется лезть в мануалы или реализацию макроса