Пиша си едно приложение за ембеддед линукс (кърнъла е 3.4, но ин 2.6.3x мисля е същата работа), пробвано и под Дебиан. То по същество си работи със сериен порт без хендшейк само вход, изход и е ок. Обаче никога не го бях ползвал за прехвърляне на повечко данни, например 200 kB. Да кажем, че на 115200 kbps тези 200 kB трябва да се източат в идеалния случай за ~17.7 sec. До тук добре, обаче реалността отива към 28-30 sec. Как ли не го въртях да го пиша, но нещо не успявам да сваля времето. След като пробвах на ПЦ и на ембеддед нещото останах учуден, но разлика няма. Не се получава някаква загуба на данни, явно буферите на драйвера поемат, аз успявам да извадя данните от тях преди да стане беля, абе - идилия. Да, ама скоростта на практика - ниска. Подозирам, че си пристигат с тая скорост, но с разстояние от ПЦ-то, което е по Windows (Terminal v1.8b, br@y++, няма как да ползвам друго в момента) . Въпросът е - Бозата ли ги пуска с разстояние по между байтовете, линукса ли ги буферира някак си или аз вероятно не правя нещо като хората? Ако някой сподели къде и как се реализират нещата ще ми е интересно... Иначе забучвам скопа и гледам какво излиза от ПЦ-то (Май не ми се работи, щом вместо да бодна сондите пускам тема... тц...)

А хардуерните буфери на COM порта ползваш ли, или цръцкаш символ по символ?
То ясно, че няма как да ти излезе теоретичната скорост - нали си иска зареждане регистри, данни....
Иначе си имаш 10 бита на байт/ ако не ползваш четност/. НО - не е непрекъснат поток!
Виж първо FIFO буферите.

//даже добра е скоростта - при теоретична около 17.8 кБ
// в чипа на Оксфорд многопортните платки ползват 128 байта буфер , а стандартния COM на PC -16

//т.е. стандартно на всеки 14(по дефолт) изпратени байта имаш прекъсване и обслужване, ново зареждане....няма как да е теоретичното - има и други процеси!

Мдаа, и мен на татък ме водеше интуицията, лошо, като цяло лошо. Надявах се на малко повече реално, но ... Както и да е, тия дни ще го закача към друго mcu и ще видя дали там ще е по-ефективно, мисля поне малко подобрение ще има спрямо пц-то, поне би трябвало, ако драйвера на другия линукс ползва дма-то отсреща (пак е ембеддед система).
Абе в тоя ред на мисли - какъв е най-удачния стандартен - разбирайте нещо, което масово има по мцу-тата - интерфейс за комуникация между две ембеддед системи? I2C не е, определено, UART-a ми идва бавен, SPI - уви, той е само в режим мастър под линукс, не ще да бъде слейв, CAN не му е идеята да е бърз (и не съм го ползвал, а и го няма наличен), USB няма от другата страна, а и ми се вижда екзотично решение, никакъв паралелен интерфейс не ми е наличен... и I2S е много кьопаво направен под линукс заради идеята му да се ползва за аудио и реално за други цели ще да ми се отели вола да го кандилкам - оставил съм го за краен случай. EBI-то и то не става, няма как да пусна толкова жица между платките. Нещо ми дойде бедна фантазията ...

Ако на 1 мегабит му викаш бавно, значи е бавно. Е ако сметнеш плявата не е 1 мегабит реално, но пак не е бавно.
Само за справка - точно днес си играх да пращам съдържанието на една 128 килобайтова I2C памет по CAN към PC и
като чета паметта байт по байт и като станат 8 ги пращам по CAN-а на PC-то на 250 килобита скорост и цялата памет се
преточваше за точно 59 секунди. По CAN-a пристигаха данни на всеки 3.6 милисекунди главно заради забавянето при четенето
на I2C паметта. Нещата могат да се оптимизират много, но нямах никакво време да си играя. Та смятай ако паметта се чете на
страници от по 256 байта и се праща пъм РС-то на скорост 1 мегабит колко време ще отеме цялото начинание.
Отделно аз до момента не познавам по-надежден и евтин интерфейс за комуникация между два контролера от CAN-а.

Любопитно ми е какво точно е MCU-то в конректната embedded система , която ти прави проблем ?
Не за друго, ами да видим реалните хардуерни възможности на uart-а му. От към буфериране , DMA и т.н.

Горе са ти дали предположение, аз може би по-скоро ще обобщя:
- драйвера е написан калпаво и не се възползва от възможностите на хардуера. -> тук има надежда
- буфера е само 1 байт и на всеки байт MCU-то прави прекъсване и линукса трябва да switch-ва context , за да обслужва не е чудно защо получаваш такова забавяне. (latency)

http://www.ru.j-npcs.org/usoft/WWW/HOWT ... tml#ss12.3 - писано много отдавна, но обяснява кратко, ясно и семпло проблема.

Чудно ми е да направя опит с едно iMX233-OLinuXino, което имам под ръка с 200Kb данни за колко време ще го прехвърли на скоростта, която ти ползваш по Application UART-a, виждайки че си има 16byte FIFO буфер на rx и на tx.
Защото като се замисля и аз под embedded линукс никога не съм прехвърлял голям обем данни наведнъж и съответно няма как да съм се сблъсквал с този проблем. Но не знам какво сравнение ще е това с твоята система, освен опит от любопитство.

едит:
По въпроса за интерфейс за комуникация м/у микроконтролери:

- според наличност
Аз лично виждам, че на най-малките микроконтролери винаги има поне i2c (uart, spi може да няма, но i2c има), което на 400kHz не е чак толкова бавно за твойте нужди. Проблема е обаче с дължината на шината.

- според скорост
SPI - семпъл, бърз, но отново на късо разстояние и да, няма spi slave подръжка официална все още в линукс ядрото.
За по-дълги разстояния , ако трябва да покриваш това е едно от първите интересни четива , които попада http://www.ti.com/lit/an/slyt441/slyt441.pdf .

Така че UART е по-скоро нещо като компромис между наличност, скорост и дължина на линията и се спираме на него по презумцията, че ако се наложи може да закачим лесно и бързо PC за диагностика. Но ако имаш конвертори определено пътя е между i2c , spi или can ( но с него не съм се занимавал по стечение на обстоятелства, обаче при 1Mbit и възможността да покрива големи разстояния май в скоро време ще му обърна сериозно внимание).

CAN-а е отличен fieldbus, няма спор. Overhead-a там обаче е по-сериозен (на 1мбит имаш около 8 байта на 120мкс, т.e. 60килобайта в секунда е максимума). Кофтито е че на PC-то му трябва хардуер за целта (адаптер към usb, pci или нещо подобно) - а тяхната цена никак не е ниска. И определено идеята му не е за стриймване на данни - имам предвид че примерно като влезе през USB-CAN адаптер има един закъснения и request-response става бавно.

Като алтернативи на каквото там правиш:
- RS422/485 ?
- Етернет ?

SPI, I2C, I2S и подобни ги забрави.
USB ще свърши работа, но казваш че нямаш контролер на микроконтролера? USB-UART от страната на микроконтролера (FTDI някакъв), или пък USB-FIFO пак на FTDI? Линка ще успее да прекара тия данни, ама помисли ти дали ще можеш да ги прибереш при теб. Така де, ако решиш USB смени контролера и слагай такъв с вграден USB device. За USB-то можеш да постигнеш близо 1мегабайт/с (на 12Мбит/с) при bulk трансфер. Ако ти трябва гарантиран стрийм (изохронен - примерно Х байта всяка милисекунда) скоростта е по-ниска. Ако скоростта ти е важна има вече и чипове с USB 2.0 HS (480мбит/с) контролери. Има го и CY7C68013A, но цената е дебела, и трябва да има с какво да го посрещнеш (бърз микроконтролер).
Етернет също може да е твоето решение, но предполагам и него го нямаш в контролера?

От едната страна е at91sam9g10, а от другата страна ще е някакво DSP до колкото ми е известно (поне със сигурност знам, че там няма USB). Не съм дълбал да видя как са направени драйверите на UART-а, но като имаш предвид, че в теста at91 приема (!) данните -> няма как да ужасно зле написан поради липса на буфер - щеше да има загуба на данни, по-скоро така си пристигат. Идеята не е да работи с ПЦ, а помежду at91 и DSP-то. То тогава всъщност ще си проличи до колко се доближавам до теоретичната скорост. Но дори и теоретичната скорост ме дразни много. Трябва ми нещо по-бързичко. Етернет нямам и няма да слагам екстра чипове на платката само за да прекарам някакви 200кБ данни на има няма 20 см за относително малко време.

scout_3pm, пробвай, ако ти остане време да закачиш това олинуксино към ПЦ (под Боза) и пробвай да налееш някакви данни за някакво време да видим какво ще стане, любопитно ми е?

чакай сега, много бързо отписа spi. вярно че е проектиран основно за комуникация вътре в платката, но лесно можеш да го изкараш и навън. сложи един бърз 4-битов (даже еднопосеочен ти стига, само да не объркаш посоката на MISO ) буфер на шината и ще вдигаш до към 8 мегабита в секунда, гарантирано. не знам обаче дали ще можеш да ги обработваш, но това ще си ти е проблем на софтуера, не на жицата

Ако се прекара още една interrupt жица, подобно на Ethernet и Wireless модулите няма ли да стане?
+1 глас за SPI от мен.

Сега за сега SPI е отпаднал, най-малкото защото по някакви прични от другата страна девайса не може да работи като слейв, аз също очевидно не мога.
Обаче сега нещо друго ме дразни, освен скоростта - гледам си аз колонките използвана памет от едно мое приложение, което е ... елементарно е: има си 3 приложния, които стартира с popen на някакъв интервал от време по разни признаци - т.е. може да стартира нито едно, може и трите едно временно, и като ги стартира ги пуска в отделни thread-ове. Взимам си резултата от изпълнението на приложението при pclose и това е. Нищо особенно, thread-овете са DETACHED и не ги чакам да се приберат вкъщи Работи, часове наред работи, никакви проблеми. Обаче гледам аз: DRS колонката - има-няма 25000, гледам RSS - има-няма 600. Чеша се по тила и не разбирам какво съм сложил толкова вътре, та да настовява за толкова голям DRS - най-много имам един буфер 256 байта и една структура, която надали надхвърля 192 байта +/-, цялото приложение е 5.4 кБ. И какво, само от шернатите библиотеки на thread-овете ли да ми иска такъв DRS ?! Някой може ли да сподели къде да търся кучето, не съм чак толкова вещ във виртуалната памет, която евентуално би искало приложението?

А защо ти трябва да ползваш вграден bus в ядрото? Направи си един битбанг в приложението с някакъв твой сериен/паралелен синхронен интерфейс според колко пинове са ти останали свободни - има си начин да мапнеш регистрите на разните контролери дирекнто в адресното пространство на приложението ти. Единствения проблем е че тогава ще трябва да си ангажираш процесора да клати пиновете, ама ако ти е паралелен интерфейса би трябвало да не тежи чак толкова.

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

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

готов си да се забиеш с някакъв безумен хардуер за да избегнеш написването на 10-редова бит-банг функция?? ти си знаеш най-добре...

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

head_up По-късно или утре ще пробвам Olinuxino-то , гледам че и твоето е ARM926EJ-S, така че ще има някакво сходство. Но в Ref. Manual-a на at91sam9g10, частта за UART, никъде не видях да пише , че има буфер / FIFO / на Rx или Tx. Сякаш е наистина само 1 shift register и като се напълни трябва да има interrupt и да се взима Странно, за ARM9. Въпреки че то това си е периферия, ядрото си е ядро.