Здравейте и весели празници на всички.
В последната седмица реших да изпробвам способностите на платкa с този процесор - по целта е да семплирам на 5 MHz 16 битово ( това в момента се прави от някакво DSP , но то прави на база самплите малко обработката и вади много ограничена информация по FTDI чип, а сега мислим да правим по-сериозна обработка в нормално ПЦ като пратим по етхернет записаните данни , за може би към 50% дути цайкъл и някакъв толеранс към изпуснати пакети трябва да стане).
АРМ-а е на 400МХз ядро с 133MHz AHB и 66MHz APB, в тестовете пускам Таймер 0 за DMA източник и PWM-то му за външен АЦП клок, таймера с 4 цикъла период и PWM-то с 50% дути цайкъл, за смяна на честотата променям прескалера му и получавам между 66/1 и 66/256 МХз, ДМА е в режим autoreloa handshake singletransfer, синхронизирана по APB и като сменям DMA dest и DMA count мога да постигна произволна последователност Х-сампъла семплирам на едно място в рамта - У-сампъла на друго и да се нагодя към останалата част от системата без да завися от закъснения на прекъсвания и подобни неща (понеже най-вероятно семплираните данни трябва да са през точно време). За тестовете съм вързал вместо АЦП един PIC18f1220 - PWM изхода от АРМ таймера му е се ползва като външен тактов генератор, а ПИК-а през 4 инструкции си инкрементира порта който чета през порт на АРМ - очаквам през 16 цикъла промяна в прочетената от АРМ стойност, понеже съм свързал само 2 ПИК пина периода е 64 пвм цикъла - всичко изглежда уж добре - до към 1 МХз честота на ПВМ изглежда всичко наред ( семплирам по 1024 самъпа с пауза 1024 за теста което е кратно на промяната на ПИК-порта и визуализирам на екрана хванатите данни - не шават напред назад и са синхронни - предполагам няма пропуски ).

Обаче ако вдигна малко над 1.2 МХз честотата работата се скапва - записаните сампли вече не са синхронни и картината на екрана играе напред назад горе долу на рандом (не е само житер има си отместване), на по-висока честота много повече. Предполагам тук там се изпускат сампли понеже ДМА не успява да се обслужи до следващото превъртане на таймера и новия DMA-req, та се чудя дали просто системата толкова си може или правя нещо тъпо и грешно. ПИК-а не трябвало да има проблеми с входната честота, АРМ програмата по време на ДМА-то рисува екран и принти дебуг по серийния порт не е да седи кротко, но не знам до колко това влияе, в приоритетите на ДМА-то ЛЦД ДМА е с по-голям приоритет дали би имало ефект ако спра ЛЦД-то ? Друго нещо с по-голям приоритет е SDRAM refresh който така и не мога да разбера за колко време заема шината, и все пак мислех, че честотите ми са достатъчно високи да докарам 5 МХз семплиране... Въпреки че да си призная не ми стана най-ясно от процесорния пдф и диаграмите на ДМА трансфери точно колко цикъла ДМА-тата си пречат... Хмм сега като гледам в хандшейк режим има 2 цикъла допълнително спрямо деманд режима може би си струва да се пробва...
Ще се радвам на някое мнение по ситуацията, чудех се и дали има смисъл ако ползвам Boot Internal SRAM (4KB) за ДМА дестинеъшън да не би трансферите до SDRAM-та да са по-бавни или да си пречат с нещо (уж според ДМА диаграмите само 1 цикъл на ползвания ДМА клок е необходим за четене и писане, дали наистина е така или е показано само схематично?), SRAM-та освен в боотлоадера май не се ползва за нищо (аз определено не я ползвам изрично, не знам за останалата част от ОС-а)...

Ъ!?
имай милост към момчетата от службите. как да преведат този тежък жаргон на вътрешния министър?

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

Проблема не ти е превключването на кирилица/латиница, ами употребата на английски думи написани на кирилица, stava sashtata shliokavica kato da ti pisha balgaski tekst na latinica. Така както си го написал малко хора ще се зачетат в текста ти. Вземи го форматирай малко, абзаци, празни редове, за да е четимо

Колега, ако искаш съвет, ще трябва да сложим малко "background" инфо за четящите - няма кой да се хване да чете документацията на самсунгера за да ти намери проблем(и). Аз съм го борил малко това животно, но не на толкова ниско ниво. Като инфо мога да ти предложа да погледнеш сорсовета на драйверите в линукса. Там са решени доста проблеми и е сравнително четимо.
Относно ДМА-то можеш да провериш дежурните неща - имаш ли няколко буфера, къде се чупи трансфера - когато трябва да започне ново ДМА, или по средата на трансфер. Казваш че ПИК смогва - как си синхронизирал външната шина на S3C-то с данните от ПИК-а - имаш ли нещо като READ сигнал, по какви фронтове сменяш данните от ПИК-а, това съвпада ли с очакванията на АРМ-а.
Как се чупят данните - липсва ти цели пасажи, има повтаряне на байтове, има пропуск на байтове?

Ако ползваш "bare metal" система или micrium, можеш да помислиш за ползване на TCM паметите - те са доста по-бързи. Иначе относно другите ДМА и влиянието им - ами спри ги и виж дали получаваш верни данни без тях ...

Ако постнеш скица на схемата между арм-а и пик-а може да излязат други въпроси.
Предполагам знаеш че ДМА контролера си е стандартен ARM primecell (PL080), или поне е базиран на него. Има регистри за идентификация и по тях можеш да го хванеш кой е. Оттам можеш да получиш доста инфо и бележки на сайта на ARM.

На теория, 5МХз не е кой знае колко, но това са си доста данни. Дори като вземеш предвид че при 32бита шина падат 4 пъти, не се сещам за много други периферии (външни за S3C-то) устройства, които да ги ползват. Може би Ethernet контролерите да са подходящ пример.
А като се замисля че искаш да предаваш 5Мбайта/с по етернета (през DM9000 предполагам), се сещам че мисията става невъзможна (за тая система). Той май се клокеше на макс 20МХз периферна шина. Ако само ще взимаш данни от ADC и (без обработка) ще ги мяташ по етернет, за какво ти е този АРМ9? Нещо с FPGA ще се справи по-добре, макар че пак си е рисковано да очакваш тия скорости от 100M етернет (реално в LAN имам предвид). Естествено, говорим за UDP или собствен протокол, през TCP няма да стане. Проблемът на S3C-то е че няма вграден етернет, което иска да имаш буфери (в SDRAM или TCM), от които да се пращат към DM9000. Тия буфери да се пълнят от АЦП-то, ама това значи че постоянно трябва да делиш достъпа към SDRAM между DM9000 и ADC-то. Става много прехвърляне. Ако приемем че е на 100МХз SDRAM бъса, значи би трябвало в тази точка да нямаш проблем, стига да се подсигуриш че няма твърде много превключвания по страниците. Което е трудно ако искаш да върви и още нещо на тая система (ЛЦД например). Пак идва въпросът че софтуера ти трябва да тича от друго място, я кеш, я TCM. GCC-то може да "заключва" определен код да стои винаги в кеша, или да го линкне към TCM-a.
Ако сметнеш големината на пакетите на етернета (1,5Кбайта) и го приемеш за база, защото етернет чипа ще ги праща на по толкова (макар да има 4К вътрешен SRAM), можеш да сметнеш че един такъв буфер се пълни за около 300мкс на 5MHz. Ако пуснеш ДМА-то да мушка направо в СРАМ-a на DM-a, ще е по-добре.

За проба можеш да провериш дали самсунгера може да хвърля толкова данни по етернета въобще - в смисъл, с празни пакети или фиксирани данни, дали ще му стигне силата да прави това упражнение - мисля си, че още тука ще издъхне ... Ако съм прав, изборът ти е да минеш на друга платформа, или FPGA, или нещо с вграден ethernet, по възможност гигабитов ... (ако тия 5Мхз семплуване са изискване имам предвид, ако приложението е "доколкото може да изкара" е друга тема). Сега, дали ще намериш нещо с удобството на готовите платки с S3C2440, не вярвам. А и не ми идва на ума нещо в момента.

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

За конкретния случай не знам как седят нещата, но знам че 10 мбайта (5*16) стрим са си доста сериозен трансфер. Като му сложиш опаковката на TCP/IP и евентуално грешки.... Много трансфер е това, ей. Много е щото е стрим, иначе на хартия всички се фукат на 100мбита. Ама отделни пакети и баба знае. Като се стигне до стрим и нещата стават наистина дебели.

Малко странично, ако не е тайна от коя сфера на живота се налага подобно преобразуване? Че ми стана интересно, що са ти толкоз много битове с толкоз много честота.

Мерси за отговора, сега таман се сблъсквам с етхернет ограничението (преди да спра ЛЦД-то исках да пусна мрежата да има как да гледам какво се случва) и да и там има проблеми, аз хубаво си смятам, че по принцип 100мбпс етхернета на УДП би трябвало да държи 5МБ в секунда без проблем, ама от тази система (да с ДМ9000 съм) повече от 1МБ май не може да се изкара, гледам как като вдигам семплиращата броя изпращани пакети нараства до към 450/секунда и после си пада и ми се качват оверрун флаговете на софтуерните ФИФО-та... явно да се ползва тази платка за тази цел не е добра идея, а иначе идеята беше я да ползваме без ЛЦД заради вътрешните ацп-та за следене на някои напрежение (където няколко измервания в сек стигат), пвм-тата и може би серийните портове за минимално количество данни , минимално натоварване. А ако кажа , че ползвам виндовс ЦЕ за тези тестове съвсем се закопавам ...
А иначе става дума за радар с горе-долу непрекуснато излъчване ( може би в порядъка на стотици микросекунди продължителности на излъчването и пауза , не съм най-запознат с тази част на текущата система), битовете трябват заради динамичния обхват предполагам, а честотата заради краткото време на получаване на отражението, въпреки че единственото което мога да обясня със сигурност е - битовете и честотата трябват понеже така е било направено ...

Ясно. Интересна разработка ще да е.

Аз си мисля, че никой 100мбита едернет не може да се справи с такъв стрим (10мбайта) към ПЦ. Честно казано незнам дали и гигабитския ще може, не заради самия интерфейс, а заради съпътстващата инфраструктура (шините към него и писането в паметта). Все си мисля, че откъм желязото ще го измислиш някак си. Щото нещата са ти известни и точно дефинирани като времеви процеси. Ще го намамиш. Но откъм ПЦ-то.... мъка.

На практика такива стрим трансфери в масово ПЦ се правят само за видео. И то под една или друга форма директно минава през паралелна шина (PCI).

Те вероятно и поради тази причина, при досегашния ви вариант обработката е качена на желязото. Точно щото натъпкването на такъв стрим в компютър под боза (пък и под който и да е масов ОС) си е .......

И така стига с толкова тестове с АРМ-а, явно почва да ме запушва и етхернет контролера (или драйвера за него) и няма смисъл да го мъча - безперспективна работа, 1 мегабайт в секунда не мога да наближа, къде са 5, пък да не говорим за верността на данните..., може би щеше да е получи малко по-добре ако не бях под ВинЦЕ тук и нямаше толкова ненужни копирания от драйвер в драйвер, но едва ли достатъчно...
За етхернета по принцип обаче не съм съгласен, преди малко за теста пуснат от едното към другото ПЦ през 100мбпс хъб едни записани пакети на двадесеторна скорост, УДП 1514 байта, като само полезните данни трябва да са били към 9.5 мегабайта в секунда (е не стига десет) виндвоса дава между 75 и 80% Network utilization, нямаше изпуснати пакети сякаш (или са били под 1 на 10000), може да пусна на гигабит мрежа ако не ме домързи да разбутвам кабелите. И това на 5+ годишен лаптоп, другото ПЦ още по-старо, а имаше скайп, е всичко сечеше ненормално разбира се и едва го спрях ама не съм правил за 20х натоварване системата ...

А замислял ли си се за някаква компресия на данните преди предаване и декомпресия след получаване?
Със "стандартни" алгоритми без загуба на информация ще го докараш до към 2:1.

За конкретните ви данни - може да измислите и нещо по-нестандартно при което да предавате само разликите между отделните отчети или др. щуротия, при което още да смъкнете тряфика ...

Компресия в реално време ще е зор (бая ЦПУ ще иде), но класики като u-Law може да се пробват. Ако 8 бита са достатъчни, че да се слезе на 5Мбаита/с има шанс да се измисли нещо. Но не и под CE - не че е лоша ОС за тоя хардуер, но ако се пише "на голо" или под микриума може да се направят доста хитринки и оптимизации че да се намалят копиранията от пусто в празно.
Гигабит с джъмбо фреймове ще трябва да успее, но пак едва ли ще е много стандартно решението.

тя компресията също иска мускули. ако няма специално желязо в системата, няма как да стане в реално време.

като прочетох по-внимателно ми се струва че е по-добре да минете на CPLD (sequencer, state mchine, но без МАС), DP статична памет и направо някакво 100/PHY. по стандартен етернет наистина ще е предизвикателство да прекарате 10+ мегабайта стрийм, дори да сте сами в трамвая и никой да не ви се бута. проблема на стандартен контролер/процесор е, че по принцип не е мислен за синхронна работа. а при вас най-важното е това. с всичките му кешове, опреснявание, DMA-та става такава каша, че не само ще брадясате докато го натъманите, ами и ще ви побелеят брадите. за проба - пусни един таймер да излиза навън, остави да работи опресняване, дисплей и още 2 прекъсвания и премери джитера.

другото ми наблюдение, е че самсунзите са относително лесни за успиване. дъхни на платката с 50W ВЧ излъчване и ще решиш дали да го ползвате за вашите си цели.

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

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

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

То работата е , че моята работа беше да пробвам ще стане ли така - явно няма да стане ... че ще го обмислим по работа с колегите и началството как е и как е било реализирано преди (не от мен) и тогава ще помислим. По приницп с ФПГА сме рализирали една друга система (тази на която паствах скрееншота), само че колегата там е зает и с много други неща (не само технически) и гледахме дали може да избегнем да го занимаваме с това , а иначе компетенцията ми е по-скоро по прости ПИК-ове (16,18), норМални ПЦ-та, покрай тях и АРМ-ове та не смея да се наема да разработвам нещо коренно различно без никаква основа ...

Може да се вдигне реалната скорост на Ethernet, ако вместо TCP се ползва UDP. Потвърждението на получените пакети трябва да става софтуерно от приемнатa страна. Също по UDP. Трябва да се експериментира и с големината на пакета. По принцип по-дълги пакети означава по-голям капацитет на канала, но от една граница нагоре това не е вярно. Границата зависи от стековете в двете страни и от качеството на физическия интерфейс ( % грешки ).