Така ... нещо ми заби ламбовия комп, сигурно защото последните 3 дни творя докъм 4 ... та ето какво не мога да измисля.

Имам N на брой у-ва, едно от тях ми е мастър, другите са слейв. Едно от нещата които синхоринизирам е мигането на едни светодиоди. Светодиодите мигат на следният принцип, имам таймер който ми генерира периоди от 1 мс, на всяка мс влизам и инкрементвам променливите, които пък определят честотата на мигане на всеки светодиод, като се достигне определен брой го инвертирам и т.н. .. то не е точно и светодиод но да приемем че е светодиод.
Така, мастъра мига същите светодиоди. Когато у-вото работи като слейв периода не с еопределя от него си а от мастъра, това е решено без съществено изместване на времето, всеки път когато мастъра инкементира брояч, слейва също инкрементира неговия с константно закъснение от няколко us която в случая не оказва влияние, ако се запуснат едновременно никога не се разминават.

Така синхорнизирането с еизисква от това че различните у-ва от време на време си сменят начина на мигане според разни събития, и след известно време трябва да се синклнат с мастъра. освен предаванеот на тактов импулс имам и 485 на произволан скорост, но предпочитам да го държа под 19200 от други съображения.

Това което измислих е в момента на синхронизиране да предавам два пакета, първият маркерен, след края на предаването изчаквам точен брой тактови импулси и предавам втори потвърждаващ пакет. Пакетите са с еднаква големина. Идеята ми беше като знам че между двата пакета имам применро 10 такта, а от друга страна слейва мери от края на първия пакет до края на втория пакет ми се получават две променливи X и Y, като X е броя импулси между пакетите, а Y ми е от края на първия до края на втория. Така ако направя 2*Y-X би следвало да имам точното време от първия пакет до края на втория, а Y-X да ми дава продължителността на един пакет.

Съответно във втория предавам текущите стойности на променливите от мастъра, и в слейва ги коригирам въз основа времето за предаване на пакета, записвам ги и всичко пее ... да ама не пее

Сега има някои неща които очевидно създават проблем, първо времето на такта е доста голямо, 1 ms т.е. не меря много точно, обаче разминаване ми се получава и при доста големи стойности на променливата при която превключвам, в моемнта тествам с 200, т.е. 200 мс. Не съм слагал репери и да гледам със скопа колко е разминаването но е доста, може би 20-30 мс, което не мога да си го обесня със ниската честота на такта, респективно точност на измерване на пакета. от друга страна времената които измервам за пакета са доста близки до теоретичните на база баутрейт и брой битове.

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

.... айде едно уточнение .... работещият ми код все така си работи, само дето точно флага на канала който следя вместо са го проверявам с 0x01 го проверявам с 0x01<<1 ... т.е. го синквам по съвсем друг канал .... така, след тази дребна корекция в безгрешният код синкването на тези двете се оправи.

Сега идва по интересната част, но все така приемам идеи и по горният въпрос ... да не говорим че току що видях как синка ги разсинхронизира .. т.е. кода е още по безгрешен ..чудно колко грешки може да се направят на 10 реда

Та да продължим, това не са единични светодиоди а светодиодни ленти, адресируеми, всяка лента се опреснява напълно на някакъв период, от 1 до 250 мс, зависи от режима на светене. Това не е интересната част, по интересната са по сложните ефекти които се менят на всеки такт. Примерно най-простото два цвята които които се изместват един друг или пък движеща се точка .. та трябва да се синхронизират и тези цветове.

Тук имах две идеи, първата да предам след 50 цикъла канал 0 започва от адрес 0 в посока нагоре, и там каквито са цветовете и т.н. ... и съответно в слейва си мислех да сметна колко съм напред или назад от този момент и да го забързам или забавя за да си навакса естетсвено, е в края ще има някакво леко прескачане но това е допустимо, сигурно няма и да се вижда.

Втората ми идея е по проста, издва от начина който вече написах за другите режими. Два синк импулса и т.н. както и да е, мастера предава текущото положение на ефекта, т.е. посока + стъпка 65, и другите ала бализми, цветове и т.н. и тъй като не ги вадя от таблици а ги генерирам в релано време мислех да "плейна" на бърз ход съответния брой цикли + корекцията в закъсненеито на данните и да започна от тази точка.

В този вариант ще иам със сигурност примигване, но в крайна сметка този синк целта е да върне слейвовете най-вече от друг режим, т.е. те така илииначе светят различно, а когато са били в този режим разликата е незабележима, най-много ефекта да е мръднал 1-2 светодиода на някъде което на лента със 180 светодиода зад дифузер и пикасо няма да забележи. Реално тези ефекти са по некритични от мигащите, при мигащите лесно е да забележеш че ендото си мени рязко цвета няккви милисекунди преди другото, а при това неможеш, някакви цветове се движат нагоре на долу, дори един до друг ще е трудно, да не говорим че +/- 0.5 светодиода никога не е изключено да има чисто механично разминаване от монтажа на лентите.

Та ако някой има хрумвания ... моето мислене е винаги е твърде ТТЛ ....за днес ще приключвам защото освен този тъп шифт кой зане какво друго не виждам .. като с еима в предвид че уж няколко пъти проверявах точно това, дали приетите флагове съвпадат с предадените и уж съвпадаха ...

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

Доколкото схванах - имаш нужда от 1-2 дни почивка, а и задачата да отлежи малко .
На 485, ако ограничиш малко възможните байтове и да речем байтове 0x80 ..0xff се предават само като единични синхронизиращи байтове( или пък имаш УАРТ с 9-ти бит, който не използваш)... Ако хардуера позволява - би могъл доста точно да определиш с колко се разминават тактовете.

В слейва ще трябва някакъв тригер, който се сетва от стартовия бит.
Сетването задейства някакъв кепчер на системния таймер. Като приемеш байта - ако е синхронизиращ, изчиташ кепчъра и го съпоставяш с минималното инфо, което носи приетия байт. Вече можеш да ресетнеш тригера и да подготвиш кепчъра за ново синхронизиране. Тригерът може да стане и софтуерно, ако кепчърът има достатъчно контроли и имаш време за обслужване на всяко мигаване на кепчъра.
Предаването на синхронизиращ байт не бива да е заложено като задължително събитие- ако няма обмен, тогава се предава синхробайт. Ще е трудно точното начало на предаване на синхробайта. Явно много ще зависи от наличния хардуер на мастера.

Ами не знам как съм го описал по горе но точно така е в момента. Порта е 9 битов, знам точно кога ми е началото на пакета. Тогава започвам да меря времето. Че сега меря по бавен таймер е така, но това нв променя принципа тъй като спрямо честотата на сигнала който синхронизирам таймера е ок.
Не искам да управлявам централизирано, в смисъш да казвам всеки път светни, изгаси и т.н. това е много комуникация, 3 канала, всеки по 180, ако им предавам и цвета който е 3 байта стават 2к и като се прави ма всяка мс стават 2МБ порта не може да се наклочи толкова, дори да не глвдам най-лошият случай пак си е доста.
Затова идеята е те вътрешно да си въртят рефреша и от време на време да се синкват.
То след корекцията на грешката с битоветв вече работи, но ми е интересно чисто като метод нещо различно.Така или иначе сега ще пооправя кода, първоначално се подведох по тъпата котайска документация и го написах без прекъсвания за да могат да се спазят времената, оказа се че време има предостатъчно, изнесох някои неща в првкъсване но и още може да се оптимизира.

Така и не схванах точните параметри на задачата, ама продължавам да мисля .
Ако УАРТ приемника е с най-приоритетно прекъсване и , синхробайта ще се обработи с
някаква точност(без допълнителни таймери и кепчъри), която може и да не е, може и да е достатъчна . Синхробайта само казва "Ресет на таминга" . Мастерът го предава ,когато може. Особеното е ,че мастерът слуша какво предава , и като приеме своя си синхробайта - също ресетва таймерите.

Каква е последователността на пакетите между устройствата, примерно: маркер -> данни-> данни->данни... или маркер->данни->маркер->данни или нещо друго?
От прочетеното имам две съмнения- или някоя променлива се препълва (нулира и започва отначало) или някои данни съвпадат с маркера (синхробайта) и се започва отначало.

Така че може и да е пакет за синхронизация, а не отделен байт.
При условие, че УАРТА е с най висок приоритет, всички слейв ще се ресетват едновременно по последния байт на пакета- с някакъв джитер , зависещ от конкретната инструкция, която изпълняват.
Мастерът може и да не слуша - прекъсването по предаване ще ресетне таймерите с някакво
отклонение от слейвовете, но може да бъде изчислено/измерено и съответно вкарано в кода.

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

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

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

Ами първото което ми хрумва е по тази диференциална линия да не излъчваш прости тактови пулсове, а да излъчваш някакъв твой времеви код. Представи си, че едно физическо време от 10 секунди (това е само пример, може да е повече или по-малко) го разделяш на порцийки с номера от 0 до 3999. Мастъра излъчва непрекъснато тайм-кодовете, които съответстват на вътрешния му таймер за псевдо-време, а слейвовете се синхронизират периодично. Колко често да се синхронизира всеки слейв - ще си определиш експериментално, но всеки слейв преди да започне да изпълнява задачи - трябва да се е синхронизирал.

Понеже линията е диференциална - идеално ще и пасне Манчестър кодиране на тайм-кода.

Другото, което ми хрумва е да има едно у-во, което само да бълва тайм-код, а всички слейвове И МАСТЪРА да се синхронизират по тайм-кода, който си хванат.

Не знам дали е дългите изречения но и на мен ми е трудно да разбера точно постановката, някоя картинка или диаграма щеше да е полезна.
Доколкото разбрах или имаш, или искаш да постигнеш глобална синхронизация между всички нодове (мастъра и слейвовете). Имаш фронтовете на RS485 които използваш като синхроимпулси и това ти дава прецизното време. Остава ти да прецениш кой "кадър" от "филмчето" сега е на ред, и може би на коя линия си, условно казано.
Това го гледахме при PTP и IEEE1588 - там една от постановките е мастърския фрейм да съдържа (започва с) таймстамп в абсолютно време, например ms или us от пускането на тока. Ако примерно са 16 бита в мкс ще имаш макс 65мс което трябва да ти е по-дълго от периода на повтаряне на анимацията (дължината на клипчето). В посочения пример с 16 бита мкс не стига доникъде, така че може би трябва да ползваш 24-32бита или да влошиш резолюцията, примерно на 1мс което пък трябва да съобразиш с честотата на повторение на мастърския timestamp фрейм (който може да си е нормален data frame с допълнителното поле за време).
По този начин слейвовете ще получат число, по което могат да се ориентиран на каква фаза (офсет) в тяхното си клипче да пеят.
Това работи в системи където има:
- синхронна комуникация - дефиниран е цикъл, примерно 1 или 10мс, и се пращат периодични пакети (start of cycle например)
- всички нодове синхронно приемат този broadcast и знаят какъв е смисълът на времето (а този смисъл е "този цикъл започва при мастърски часовник = 12345мс")
- имаш някакъв хардкоднат или гъвкав (протоколен) начин да задаваш дължина на клипчета, офсети на клипчетата въртени от всеки слейв
Доколкото разбрах самите "клипчета" са заредени в нодовете (може би и при инициализация на power on) и не се подават в реално време през rs485? Сигурно си имаш друг механизъм да ги "претакаш" от мастъра до слейвовете?

Не е ясно описана задачката. Тоя клок дето върви по всички нодове изглежда се ползва като клок за цикъла 1 милисекунда - примерно 100кХц му дава 10мкс грешка между два нода. А проблемът изглежда - така го разбрах - че задачите анимират в по-дълги цикли - достигащи 200 и повече милисекунди и не успява да нулира едновременно всички нодове с точност под 1 милис. Всъщност Тони казва ,че го е сборил и ние сега се упражняваме.
Ако това изложение е коректно - бих махнал бързия клок 100кХз и бих го земенил с бавен клок 200милискунди.

Ами донякъде си прав, първоначално идеята на този бърз клок изоно не беше да е клок а да е sync, и ще взема да се върна към този първоначален замисъл, и не на 200 ms а на повечко дори, 10 с примерно. Няма някаква основателна причина да има разсинхронизация освен комуникацията но и тя не е тъй като на фона на клока на процесора битрейта е нисък и едва ли по някакъв начин промен също така сравнително дългите цикли на рефреш на анимацията /1 мс/. Реално точно така започнах да го пиша, и докато вдигах флага си казах, добре де, аз що не пусна направо такт тука ... стори ми се добра идея и го направих така.
Синка по пакет има всички недостатъци на комуникацията, винаги има някава неопределеност.
За цялата постановка, може би като не съм спал мисля объркано, то и като съм спал пак така, явно не съм се изразил много добре.
Реално проблема е решен, но това не ми пречи да го пренапиша, аз обичам да питам и почти винаги приемам чуждо мение ако е логично и ефективно, дори и ако преди това съм спорил и твърдял че не може така, та не е просто разгрявака на мозъка, ако нещо изглежда по добро, надеждно или дори по красиво бих го приложил.

Та да се опитам да обесня отново с повече подробноси. Имаме 4 канала адресируеми ленти, всяка със по 180 светодиода да речем, каналите може и да са 3, едва ли има значение. Така за всеки канал има една цветова схема която казва при какво състояние на дивайса кой канал как свети, примерно канал едно може да е целият червен, канал 2 да му се сменят два цвята, канал 3 да е някаква движеща се приливка и така нататък. Цветовата схема също така казва колко често се опресняват тези канали, веднъж в секунда или 2- пъти, или 200 пъти. Също така се казва длаи режима е мигащ или не и други подобни.
Всички параметри на тези състояния са записани в цветовите схеми, начален, краен цвят, допълнителни цветове и т.н. абе като по преливките на фотошопа примерно настройките.
Логиката ми за да пестя процесорно време нужно за други неща е да не рефрешвам всичко постоянно, това не са динамични ленти, веднъж заредени те си стоя на цвета, т.е. едноцветните или колко ще цветно но не променящи цвета си могат да се рефрешват веднъж на секунда, тези които мигат или си сменят цвета могат да се рефрешват с времето на мигане или на смяна. Тези които се рефрешват най-често са тези които са анимирани, като те се рефрешват с честотата на самата анимация, т.е. примерно имаме анимация движеща се точка, ако отив аи се връща до края на лентата за 1 сек и лентата е 180 светодиода имаме 360 рефреша в секунда. Нищо от тов ане се смята то идва с цветовите схеми.
Имам таймер който ми прави интервал 1 мс, който го изпзолвам и за други системни времена, не че нямам още таймери, таймери да искаш 6 таймера, още един на PCA и 4 групу таймери с кепчъри ... но както казах мисленето мие строго ТТЛ, ако може да се свърши с еидн защо да изпозлвам втори
Та всяка 1 мс влизам и проверявам дали е достигнато време за рефреш на съответният канал на база цветовата схема. Ако е достигнато викам съответната функция според схемата която ъпдейтва буфера на канала и след това го предавам към лентат.
Самото предаване е бързо, 180 *3*8*1.25 , което е 4-5 mс май, т.е. сега виждам че не е толквоа бързо колкто си мислех, но така или иначе за текущите тестове не оказва влияние тъй като тествам нещо с много ниска честота на рефрешване. Означава, че ще трябва или да лимитирма дължината на лентата или макс. честота на рефреш, както и да се опитам да оптимизирам предаването на данните да става едновременно на 3-те канала.

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

В моемнта тактовията ми сигнал, както вече стана ясно е централизиран, а синхро пакета са всъщност два пакета, първи който подготвя слейва при който слейва започва да мери едно време, и втори който дава реалните позиции на анимациите, както и променливите определящи времето за рефреш а също така и колко началото на този пакет е изместен спрямо края на предният.

При това слейва може да орпеделеи колко е самият пакет, и с колко да компенсира.

Ето че подобни дискусии са полезни по много начини, не се бях замислил че при 180 светодиода, оригинално бяха 120, горе долу съм на границата, 15 ms са теоретични 60 Hz, цветовите схеми повечето са между 40-50 hz на анимациите.
Ще си поиграя да направя адресирането едновременно по 3-те или 4-те канала. Реално бях го направил но едните ленти се пънеха, явно им излизаше 0-та от спецификацията, и тъй като нямах кой зане какъв зор просто ги разделих да са 3 последователни, и от там и отделните времена за рефреш.
Ако го драсна на асемблер ще стане и 3-те наведнъж да адресирам. Това е дреболия ...