Ако не ти трябва недей да усложняваш много нещата - като слушам как искаш да имаш преносим код между процесори (в което няма нищо лошо де) за да го постигнеш ще трябва да вкараш някакъв допълнителен слой който да вкара абстракция т.е. да направи по общи/еднакви особенностите/разликите между различните процесори/архитектури. А почнеш ли да го правиш това комай ще е по ефективно да позлваш някой готов RTOS в който вече са го решили този проблем. В някои RTOS-ове можеш да имаш освен ISR и DSR който позволява малко по олабена обработка на прекъсванията, даже и в отделни нишки, така че да ти съвсем широко около врата да заключваш разни мутекси и т.н. Това има смисъл ако ще правиш нещо дългосрочно и с екип в който трябва да имаш заменяемост на програмистите - ако ще си правиш всичко сам, не си вкарвай таралеж в гащите с излишно усложняване в началото а си еволюирай кода с времето като се появи съответно нужда - то щом питаш може и да си вече на този момент

Горното ме заинтригува, та да питам. Най-общо, при писане на език от по-високо ниво, какъвто е Си, преминаването от един контролер на друг не е ли свързано най-вече с управление на периферията им. Тоест, оправя се инициализацията на периферията, кое по какъв начин се сетва, достъп до нея, и в общи линии с това да се изчерпват нещата?

Миро май по добре ще ти отговори, но ще опитам и аз пък да видим дали ще ми се получи. Та, ако е за архитектура способна да търкаля цял ОС като линукс там всичко ти идва кажи речи на готово само, че не е в реално време а си има латентност заради ОС, прекъсвания, процеси, приоритети, драйвери, между процесни комуникации (пайпове и прочее) и т.н. Но пък от друга страна почти всичко ти е унифицирано, имаш POSIX който прави нещата да изглежда (почти) еднакви на всякаква архитектура - х86, АРМ, МИПС, ПоверПЦ и т.н.
Когато обаче говорим за микроконтролер имаш много ограничения и понякога не може да си позволиш разхищението да добавяш мегабайти код за да направиш примерно POSIX съвместимост т.е. започваш да правиш някакви компромиси и си изграждаш твой си API с който да се опиташ да обхванеш колкото може повече варианти без да го усложняваше прекалено защото иначе се връщаш пак към многото мегабайти. И тук въпроса опира до това къде ще дръпнеш чертата по отношение на големина на кода и между плаформена съвместимост - по малко съвместимост обикновенно означава да си по близко до даден архитектура отклкото до друга, по малко код и т.н. разбира се винаги го има варианта някой да разпише тонове код без да добави кой знав какво повече като функционалност.
Мисля, че основните разлики се свеждат до разликите в хардуера - един ще ти прави прекъсвания, и ще чака процесора да свърши всичко, друг ще има DMA с което ще можеш да спестиш част от работата и да получаваш/изпращаш някакви данни направо в/от буфери в паметта - колкото и да са близки двете все пак може да се отрази на API-то което си направил и преминаването от единия на другия вариант да става тегаво т.е. да си иска писане за да портнеш до нова авхитектура. Ако си копал достатъчно дълго време в една посока с времето би трябвало да си си изградил твой си код, да си имаш любими процесори, да си си стиковал нещата и всичко да върви гладко. С всяка архитектура която добавяш ще става все по изчистено. Аз лично съм против да се пише код без да има реална нужда от него към момента само защото може би по нататък във времето ще потрябва от което следва, че във времето понякога сроковете те притискат и нямаш капацитета бързо да дописваш каквото трябва т.е. щеш не щеш трябва да ползваш чужд код и библиотеки, което пък от своя страна повлича да се съобразяваш със стандарти за да минимизираш времето за внедряване на нови библиотеки. При другият вариант е малко хазарт - ако си късметлия и си подредиш нещата както трябва в началото, направиш си хубав архитектура и т.н. ще ти е лесно да разширяваш - но това си е доста рисковано защото никога няма да си сигурен дали не си тръгнал някъде на криво - трябва си и много опит и доста късмет. Т.е. да ти се отговори еднозначно на въпроса е трудно защото не е ясно как искаш да си изграждаш продуктите във времето - аз вдигнах ръце от контролери и ртос и в момента се занимавам само с embeded linux - очаквам цената на система която търкаля цял ос и има няколко стотин мегабайта да падне под $1 (в момента е между $5-$10) и да пиша всичко на node.js - така скалирам от нещо дребно до облак кажи речи с една платформа - но това си е мое субективно мнение и много хора не са съгласни - времето ще покаже. То и нуждите са различни де - колкото и да падат цените ще си има пазар и употреба PIC-льовци още дълги години ...

Ицо, да езиците от "високо" ниво помагат, но не са панацея. По-горе на въпрос за С цитирахте IAR и XC16 вместо някой от С стандартите. Това само по себе си говори, че теорията е едно, а на практика понякога е по-различно.
Особеностите на компилаторите обаче не са чак такъв проблем когато сменяш джелязо. Много по-важно е самия софтуер, кой и как го е писал. Ако се спазва някакъв HAL прехвърлянето е по-леко. Понякога дори и HAL-a не те спасява. Аз съм имал случаи дето логиката следва възможностите на конкретното джелязо и беше неизползваема без тотална преработка.

Което всъщност не е изолиран случай, а по - скоро масовия такъв. Защото за да се изтиска максимално периферията, често се налага и логика от по-горни леъри да е напасната към нея.
Отделно, че масово хората, които пишат за контролери са своего рода вълци единаци. Не всички, но е масово явление. И пишат кода на принципа - и сам война е воин. Свикнали са с дадено желязо и гонейки срокове, производителност, цена и т.н. зарязват абстракцията. Защото абстракцията си изисква много време и мислене. И много опит. И винаги си в дилемата - колко да пожертваш, заради нея и къде да спреш. Защото и уливането в абстракции също не е добре....На мен лично това ми е едно от най-сложните неща при граденето на архитектурата на нов проект. Обикновенно тези дето сме тръгнали като железари, доста по-трудно се справяме с тая работа.

Мда... всичко е въпрос на компромис и цена. А и зависи кой плаща цената. Ако е друг, няма проблем с уливането. Но ако сам си пишеш кода ти идва малко на нагорнище да поддържаш хиляди варианти. Оставяш само вариантите дето ползваш или има вероятност да ползваш.


Точно за контролерите не е така. Иска да се познаваш джелезата. Не става само с абстрактно мислене.
Разбира се най-добре и двете, но това е голяма рядкост. Аз често ми се налага да разглеждам чужди библиотечки и се кефя като видя нещо писано от някой дето разбира и от програмиране и от джелезария. Но пък ми се плачи като видя нещо дето няма нито едното нито другото

Ами то в големите фирми си има такива хора дето изначало само чертаят концепции и софтуерни архитектури. Без самите те да пишат софтуер, само бълват документи. И после всички ги следват, няма хъката, няма мъката. Тези хора ако са опитни са адски ценни, защото като заложиш куцо скеле и после се почва едно натаманяване...

В малките фирми, обикновенно всичко се напасва в движение... и нещата най-често са единствени и неповторими

освен ако не пренапишеш 3-4 пъти докато ти се изчисти концепцията, но в това няма нищо лошо, ако развиваш един продукт ако ти трябва камила много по добре да си купиш камила отколкото да се чудиш как да маскираш магарето като камила, а то всъщност преди да стане магаре е било куче ... със сигурност не е загуба на време. Друг проблем е когато нещо с ее правило много, много отдавна, и като се е правило си знаел 1/100 от това което знаеш сега, говоря за специфики, обаче с цел легаси буташ години наред код и структура които едва ли са най-ефективните от към перформънс и от към писане. Това е супер голям проблем, и дори да тръгваш да направиш нещо уж ново, не успяваш щото никой не му се рискува с нещо съвсем ново, и така понякога дори елементарни оптимизации и подобрения отнемат години докато се имплементират, и въпроса не е дали се знае как, дали може или има ли кой, а колко е рисково, кога ще стане и на каква цена, говоря не цена разработка а какво може да изгубиш.

Затова не се пишат неща, които не знаеш - има един принцип в програмирането - Single responsibility. Свежда се до това да намериш начин написания от теб код да има една единствена причина за промяна, т.е. да покрива само един аспект от нещо си. Ако има например комуникационен протокол трябва да го опишеш в API което се занимава само с подредбата на данните (сериализация и десериализация) и да не се занимава с транспорта.
Примерно правиш Modbus - не бива да правиш никакви приемания за транспорта по който ще върви - т.е. на практика не може да разчиташ на никакво, дори абстрактно API. Т.е. казваш - сега пиша функциите които при подаване на аргументи регистър, адрес, ... формират и попълват пакет в правилния ред. Което значи:
- не алоцираш ти пакета - не е твоя работа (single responsibility) - декларираш че го искаш като аргумент (поинтър и size примерно)
- не викаш транспорта - не е твоя работа (single responsibility) - ще върнеш попълнен буфера с каквото се иска от теб, а дали и как ще бъде изпратен не е твоя работа (може да е тест който няма да праща е ще сравнява с тест вектори, може да искат да разпечатат данните, ...)
- не търсиш примерно името "Цилиндър 5" на кой адрес по RS485 е - не е твоя работа (single responsibility)
Което значи че твоето API ще получава аргументи:
- адрес
- регистър
- ...
- пойнтър и размер на буфер в който да сложи подготвения пакет
Като резултат пълниш буфера и връщаш OK или грешка.
Ако след време излезе нуждата от речник "име" към "адрес" той ще се намира преди теб в call graph-а и се очаква някой да го е повикал преди да вика теб, да е намерил че на "Цилиндър 5" отговаря адрес 8 и теб да те повикат пак с адрес 8.
По този начин за теб има само една причина да има нужда от пипане на кода - да се смени спецификацията на Modbus протокола или каквото е там RFC примерно.
Това позволява останалите около теб да правят каквото си искат, защото няма скрити зависимости.
Ако беше решил да алоцираш вътрешно пакета щеше да улесниш някой студент който почва при теб да не го мисли, но ще загубиш възможността да сложиш този пакет в някаква бърза вътрешна РАМ зона, или дори да го наместиш във фифото на етернет контролера... (zero copy стек).
Ако все пак решиш че искаш да е в хийпа никой не те спира да сложиш алоциране преди викането на сериализатора - но по-важното е че API-то не задължава и не налага някакъв стил на ползване.
За студентите може да се направи обща функция която първо алоцира, после сериализира, после дъмпва в лог и накрая праща по "default" COM1 примерно - но това не значи че трябва в една функция да наблъскаме всичко.
Много сладко се получава тестването на такива функции - по подобние на крипто функциите има входниданни и очакван изход - тест вектори. Извърташ ги (в случая всички възможни адреси, всички възможни регистри, валиден и фалшив буфер и размер...) и имаш гаранция за работата на кода. Качваш го на svn/git и забравяш за поддръжката му.

А малките фирми не че им е по-сложна ситуацията, а по-скоро е по-свободна и минава оправданието "така е по-ефективно", "няма друг начин" и т.н. Това ако си сам програмист ще мине, но е малко засрамващо да извадиш един омазан код пред дузина колеги и да се правиш че всичко е наред.

Гичо, то от разстоянието на времето, опита и след като си настъпил повечето мотики е лесно да кажеш това е грешно направено, трябваше да се направи ето така. Да ама когато нещо е започнато да се прави преди 20 години, да не кажа 30, нещата хич не са такива. По онова време дори и литература да намериш не е било лесно, казвам било защото аз по това време съм си играл с 16-ката в службата на баща ми. Имаме неща правени началото на 90-те, нито някой е предполагал до къде ще се стигне, нито е мислил за всички тия неща които сега са известни. И с времето постоянно развиваш и никога няма време за тотално пренаписване. Преди 13-4 години имаше такъв момент когато доста неща можеха да се оправят, сигурно и много са оправени, но така или иначе и сега все още е далеч от съвременните стандарти и добри практики. и както казах не е от незнание, от нежелание на хората, ама като трябва да генерираш продукт нямаш голям избор, затова малко по-малко на ден по лъжичка, където и когато се отвори възможност.

Да бе, да, всички имаме мнение как трябва да се пише

Ама като опре до самото писане, нещо май не ни се отдава?

Не - някой нямат и мнение и карат по инерция, други търсят да изградят такова, трети сигурно намират своето и го защитават. Всеки си избира - и идеята ми беше че работейки самостоятелно имаш предимството (или недостатъка) да избираш сам. Което води до търсения от различен вид:
- търсене на оправдание - така е отдавна, винаги така сме го правили, мен така са ме учили, то работи навсякъде по света, ти знаеш ли колко код трябва да променя ако тръгнем в тая посока? (което обикновено се свежда до "ти знаеш ли колко код трябва да изтрия за да махна изкуствените придатъци дето са ме хранили последните 20 години?"....)
- това като ми създава главоболия сега да го оставя ли (клиента ще се обади ако има нещо), да го заобиколя ли (още един слой измислена "абстракция"), да го пренапиша ли, да взема да помисля ли, да проверя някой има ли идея по въпроса (което косвено изисква призная поне пред себе си че може и да има и по-умни или поне по-опитни глави по света)
Докато в по-големите екипи/корпорации нещата са по-скоро наложени - само че и тук не е задължително да се знае кой вариант е наложен. Има места където те натискат да не променяш нищо, да следващ концепции отпреди 30 години с аргумента "да не би да се счупи". Има и обратното - да те поощряват да изчистваш и подобряваш. В големите фирми това вече не е твое лично решение, а такова на мениджъра или изобщо слоя "отгоре". Което пак може да е лично мнение, но не винаги съвпада с твоето. В тази ситуация ако има разминаване имаш избор - сменяш фирмата. При one man show процеса си решаваш самостоятелно и сам си теглиш товара.
Интересното в че в ембедед често го играем "консервативни", а недолюбваните веб/фул стек програмисти са по-отворени към нови идеи. При тях може би има повече свобода от гледна точка на това как се деплойва софтуера им и лесното, невидимо за клиента, мигриране - което идва от доброто разделение на фронт и бек енд. То при тях е по-скоро наложено, докато при нас се иска усилие да се сложи границата - и съответно масово липсва тоя напън.

Гичо като казах, че сме силни на философстване имах предвид и себе си (щото някои тук ме имат за капацитет някакъв ).
То аз наистина мога да изпиша набързо поне 10 страници кое как трябва да бъде, но истината е че вече месец тъпча на едно и също място с една библиотечка и не мога да я напиша. Пробвам да копирам от разни подобни, ама не ми харесва и променям и те така се моткам сума си и време...
В интерес на истината библиотечката е на шибана тема, така че мога да се оправдая. Но то винаги има шибани проблеми, както казва един приятел тя ако работата беше лесна на нас ли ще се падне. Та мисълта ми е, че винаги има непредвидими неща. И никакви теории не помагат. Даже по-скоро пречат, щото софтуерните концепции общо взето се свеждат до "как не бива да се прави" и рядко ти дават отговор "как да го направя аджеба"....

+1

Мда.. и мамата . това в кръга на шегата, иначе Миро е абсолютно прав. Аз пък хич не съм експерт в софтуерните концепции, затова и гледам да си стоя с малките контролерчета и доколкото мога да се уча от тези дето са се поизучили, за другото си има професионалисти, и това че си изчел 100 книги, и уж всичко ти е ясно често не помага.