Здрасти,

Бора са тук с едни истории, от които малко вдявам. Надявам се на вашата помощ.
Казусът е такъв: имам UART който предава данни със скорост 921600 baud rate, имам и АЦП, което искам да пусна да работи примерно с 10 kHz. Проблемът ми е че UART изпраща много грешни съобщения.
Мисля си да направя проверка на получения пакет и ако не покрива критериите да го поискам наново. Пускам АЦП-то го с ДМА и когато трансферът е готов генерирам прекъсване в което "вдигам флаг" (може и да бъркам термина, във функцията на прекъсването давам на една променлива стойност 1 и в безкрайния цикъл проверявам дали е 1). С контролерчето добавям header и checksum-> изпращам съобщението но какво следва? Значи приемникът трябва да го провери и да изпрати обратно съобщение с потвърждение или такова за грешка, следователно трябва да чакам, а после да проверя какъв тип съобщение е отговорът и да изпратя отново същото съобщение, а през това време АЦП-то бълва нови. Някакъв буфер, примерно нещо като ФИФО ли трябва да се ползва? Как подхождате към проблемът с грешките при трансфер на данни? Бихте ли предложили друга връзка с ПЦ която е стабилна?

Благодаря.

USB? Иначе първо трябва да си сметнеш дали добавянето на протокол ще ти позволи физически да пращаш всички семпли.

Благодаря! Намерих туториал за USB на ControllersTeach. Ще го пробвам.

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

Програмирал съм го с CMSIS. Процесорът е СТМ32Ф401РЕ. Има разни прекъсвания, при завършен трансфер на данни от АЦП-т по ДМА, после при завъшен трансфер на данни от ДМА към UART. Разстоянието е около метър. Исках по-голяма скорост на трансфер за да наваксам на честотите на пробовземането, но май-май няма да стане с UART въобще. Все пак се чудих как точно се осигурява трасфер без грешки.

Е ако семплираш на 10k дори и 16 бита да в резултата имаш огромен резерв по битрейт, може д минеш на по-ниска скорост.
Твоят пакет може да е съвсем прост, ако предаваш два бай-та, спокойно може да минеш с 5 байта пакет, дори с 4. Отделно смия сериен порт има чексума ако си я сетнал която също може да се използва за верификация.

Първоначалния сетъп беше всичките 16 канала х uint16-t, защото в 8 битова променлива няма място. Сега не знам дали може да се използва 12 битова променлива, но това са 32 байта на проба или 320 000 байта за честота на дискретизация от 10 kHz, която честота е сравнително ниска. Думата е 8 битова, така че има допълнително разделяне, преформулиране, като добавим и към това добавянето на хедър и чексъм, както и това с чакането за отговор и брой вторични изпращания при лоши данни, става един, може би значителен и неопределен период. Това време не знам как да третирам.

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

Проблемът е, като при повечето лаици, многослоен Боря го с нова система. Планирам да купя външно ацп с по-малко канали, но пък с по-добра честота на пробовземане, на развойна платка, примерно това: EVAL-AD7606BBCHIPS така че да избегна много от автобусите с които се срещам, като пропусна работата по апаратната част. Ще опитам да го подкарам с по-бързо Нуклео примерно NUCLEO-H753ZI така че да има възможност да извърша някои от сметките директно на бордчето, вместо да пращам на компютъра и накрая ще опитам да ползвам USB с Bulk Transfer. За да прехвърля данни на компютъра. Има и още една причина да търся нова апаратна част и това че в момента, показанията на един микрофон влияят на другите, както и става някакво натрупване защото като включа някои микрофони и показанията на всички се вдигат на 1500-2000.

Мързи ме да гледам конкретните чепове и платки, затова малко наизуст ще кажа нещата, които ми се набиват в очите.
Първо УАРТ в подобно приложение е като сам да си просиш боя. Не знам дали наистина ползваш УАРТ или бъркаш понятията, но при УАРТ характерното е, че е асинхронен интерфейс - демек нямаш клок. И за да работи трябва клоците на двете страни да са що-годе еднакви. При 8-бит трансфери подобен баудрейт може и да бачка, но 16-битови трансфери изискванията към клоците стават по-сериозни. Идеята е че от старт бита до стопа са много битове и грешката се натрупва, а и ако имаш и хвърчащи жици сигналите почват да се кривят и прозореца за семплиране се стеснява. Демек дрифта между клоците си е критичен. А ако пък STM-чето го пуснеш с PLL и с включен spread spectrum... ще съм много изненадан ако изобщо тръгне комуникация.
Сега повечето АЦП-та си имат клок, а пък повечето UART-и на тоя проц са USART. Да не говорим че отделно има и SPI, така че горещо препоръчвам да ползваш синхронен интерфейс (демек с клок). Тогава 1Мбит/с няма да ти е проблем, даже и 50 Мбпс няма да са проблем, стига да не е по хвъчащи жици.

Второто нещо, е че това всъщност не са чак толкова много данни за Ф4. Спокойно може да вкаращ някаква обработка и да си ги пакетираш ако ще ги пращаш към РС. Най-елементарното е да ги кодираш с различна дължина. В смисъл, предполага се че си филтрирал сигнала и той е с по-ниска честота от честота на дискретизация и ако това е така разликата между две последователни измервания трябва да е малка. Демек като ги пакетираш може първия семпъл да го представяш като абсолютна стойност, а останалите като разлика от предишния. Има и много други начини на компресия, разбира се. Мисълта ми е, F4 може да се справи с подобни и по-сложни обработки. Η7 ще е овъркил, освен ако не му ползваш 16-битовите АЦП-та.

Почнах да го чета преди доста време това USB ... но нямам шанс. Сега правя така . Настройвам си къстъм хид в Cube на STM, имам няколко дискриптора (нищо страшно-структура) които ползвам.
Задавам си дължината на дискриптора, броя байтове за приемане и предаване, имаш слаба функция за прекъсванията, приемането и предаването на пакета, и се подкарва сравнително лесно. От към страната на компютъра е по гадно ... аз съм с най-лесното ,ползвам компонент на Борланд. И така , сега ми е много по лесно, всяко модулче вече е с USB-C няма да мислиш за кабели ...

Здрасти, Миро. Задавам ръчно baud rate на предавателя и приемника. Нямам синхронизация, трябва да е UART, в блок диаграмата модулчето е USART2, но не синхронизирам часовниците. Вероятно не ползвам тази функционалност. За да избегна хвърчащите жици, ползвах връзката през СТ-линк и кабелът за свързване с USB към компа. За съжаление още не съм се сблъсквал с " PLL и spread spectrum", така че вероятно не ги ползвам. Комуникация има. Върви с доста грешки.
Благодаря за ценните съвети, особено за архивирането! СПИ иска някакъв преобразувател за да се свръже с компютъра, взех едно УМ232Х но не успях да го накарам да предаде нещо. H7 има USB и DSP функционалности с които искам да се запозная.

Благодаря, ще го пробвам. В момента нямам контролерче с УСБ модул, но ще изнамеря някое в с коро време.

Не ме разбираш какво се опитвам да ти кажа, понеже не правиш разлика между синхронен и асинхронен интерфейс.
UART е асинхронен, защото предавателя има негов си клок по който изкарва данните, а приемникът "семплира" тия данни по собствения си клок. Всъщност самото семплиране става с 8х или 16х клок, но по-лесно се обяснява с 4х. Щото може да разделиш времето на 4 четвъртинки. През първата и последната четвърт сигналът обикновено се променя и не е добра идея да гледаш какво е нивото. В идеалния случай гледаш между 2 и 3-тата четвърт. Там някъде ти е "прозорецът" в който по жицата сигнала е стабилен.
Та как става работата - да кажем че се очаква комуникация на 1Мхц (за по-лесно смятане). Ти имаш 4 пъти по-висок клок, т.е. 4МХц или през 250нс четеш. Нормално линията е с високо ниво и чакаш да падне (това е старт бита). Когато видиш че е паднал, знаеш че си някъде в първата четвърт на старт бита (поне се надяваш да си там), пропускаш 5 клока (остващите 3 от старт бита и първите 2 четвъртинки на първия бит) и четеш първия бит. И така на всеки 4 клока четеш 1 бит... И си получаваш данните.
Сега къде е проблемът. Значи в повечето случаи клок източниците са с +/- 5% точност. Нека АДЦ клока ти да е с -5% а пък проца ти да е с +5%. Това ще рече че на всеки един бит от комуникацията имаш 10% разминаване. АЦП-то почва да предава старт бит, проца вижда и почва да тактува. Само че проца тактува с 10% по-бавно. В края на старта имаш 10% в края на първия бит 20%, а след 10-я бит грешката ти вече е 100%, демек където проца си мисли че трябва да чете 10-я бит АЦП-то всъщност е на 11-я бит. Естествено комуникацията се насира.
За да не се размината трябва грешката която се натрупва да не е повече от половин бит тайм. А натрупването ти е един старт + 16 данни + 1 стоп. За по-сигурно закръгляме нагоре, демек в рамките на 20 бита не бива да имаш повече от половин бит грешка. Или с други думи двата клока трябва да са еднакви като честота с точност 1/40. Това не е невъзможно, ама трябва кварцовете ти да не са +/-5% ами с +/- 1%, само така разлика в двете честоти ще е под 1/40 (2.5%).
И това в целия температурен диапазон, целия диапазон на захранващи напрежение и т.н. В твоя случай надали имаш 1% точност, съответно разчиташ на късмет да ти се паднат два еднакви кварца... Което е несериозно

А за spread spectrum-a.... Това е един бит в регистрите на ПЛЛ-а и по подразбиране обикновено е включен. А някои STM (мисля F207) имаха бъг и не се изключваха и затова беше зор подкарването на етернети. Но по принцип искам да кажа, че обикновено се пуска и причината да се пуска е, че всеки проц/платка излъчва на работните си честоти. И може да не минеш изпитания (ако се изпитвате). Но като се пусне джуркането на ПЛЛ-а това кара работната честота да танцува лекичко напред-назад. Пак излъчваш същото като енергия, ама тая енергия е разпределена в един по-широк честотен диапазон. А за изпитанията е важно да нямаш една конкретна честота над нормата. Не е проблем да излъчваш в много честоти под нормата. Но в твоя случай проблемът е, че няма да имаш един фиксиран баудрейт, а нещо което ще танцува около тоя баудрейт. Така дори да си подбрал кварцовете абсолютно еднакви пак ще ти се разминат честотите.
Всичките тия проблеми изчезват ако вържеш и клока по който се предават данните. Тогава и предаването и приемането стават по тоя клок и ги няма тия драми. От страна на проца и USART и SPI ти поддържат работа с клок, предполагам и АЦП-то също, тъй че е грехота да се мъчиш с асинхронни интерфейси.

Сигурно аз не съм догледал нещо, ама оставам с впечатлението, че никъде не е казано, че връзката АЦП-МЦУ е асинхронен интерфейс. Аз го разбирам като АЦП-МЦУ е SPI/I2C, а МЦУ-Комп вече е UART.
Ако все пак наистина става дума за асинхронен интерфейс м/у микроконтролера и АЦП-то, тогава Миро е обяснил защо такова решение не е за препоръчване.

Колегата VPavlov е споменал, че ползва вграденото АЦП и се кани да ползва външно.

@VPavlov - по празниците ще се "збавлявам" с нещо аналогично. Ще пиша какво съм постигнал.

Благодаря за разясненията! Ще проуча как става синхронизирано. Да си призная не съм правил УАРТ със синхронизиране още по-малко с компютър.

Новия план е така: ADC->SPI->Nucleo->USB->Pc
Тоя път ще опитам с HAL, защото имам чувството че се задълбавам много надълбоко, а основната цел остава без внимание. Вярно че АЦП-то контролирам с часовник, така че да мога да определям честотата на пробовзимане. Успях да накарам контролерчето да я чете от получена по УАРТ команда и да я сменя в движение.