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

Мда, схванах...то това ми е единия проблем...На 19200 всичко е ОК, ама на 115200 получава някакви дефазирани неща. Обаче по тая логика не трябва ли преди всеки байт да пращам preamble (сигурно въпросите ми те дразнят )?

Ne, само пред първия. На RS232 най-добра работа върши 0xFF - 2 пъти. Направи си един тест - 1 000 000 предай едно съобщение от 100 различни байта и при приемане запомняй колко съобщения са сбъркани. Ако са повече от 5%, трябва да намалиш скоростта, да поставиш RC филтри в приемната част на схемата или да включиш ECC. Последното е най-ефективно, но на PIC на 115.2 kbps е леко казано голям зор. Ако не дай Боже объркаш къде е началото на съобщението, значи протокола ти не е много читав.

Бла...Играта много загрубя Ама ще взема да го направя както трябва, че да не се занимавам друг път. Засега така съм решил да го направя:
| preamble | | ID | | packet_size | | data | |chksum |
1 byte 2 bytes 1 byte n bytes 2 bytes

Ще видим дали ще стане...

Всъщност в приемащото устройство preamble байта не ме интересува какво съдържа, нали така?

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

Ами аз затова съм го пуснал на 115200 да мога да изчитам една CF карта 32MB, ама ще е кофти да я свалям цял ден. Все още обмислям цялата работа, щото на тоя PIC16 не му остава време да си поеме въздух (да не говорим за пакети от сорта на 256 байта - немислими са).

Всъщност, ако не е тайна, за какво става дума? 32MB да се прехвърлят на един път по сериен канал - това не е добра идея. Може би трябва да се преразгледа идеологията. Хората го правят по LAN.

Ами в тия 32MB се пишат разни "случки", които се случват на едни машини...Пише се час, дата, случка #. Между другото едва ли някога ще се наложи всичките 32 MB да се свалят (камо ли едновременно). На желязото имам един 24LC512, в който предварително си пиша случките. Като се напълни, го прехвърлям в CF-a. Като се има в предвид че случките стават бая често, а ПЦ-то се включва от един път в седмицата (а понякога и в месеца), инфото може да стане доста обемно. За LAN мислих още в началото, ама все не ми остава време да почета малко по-сериозно за TCP стековете и да си напиша някой.

Ахам правим data logging.

Там е и работата, че за доработки на желязото не може да става дума... Пък и толкова време съм го проектирал това желязо...малей. Аз мисля че на 115200 ще стане работата (е*ати къв съм оптимист ). Само се чудя как точно да организирам пакетите...Дали да си въртя буфер или да записвам всичко дето идва след ID-то, затова опирам до вашия опит..

И аз не знам. Пробвай и двата варианта и кажи кое е по-ефективно.

Бе твойто пак е лесно - 32МБ. Аз има същия проблем ама говорим за SD карта 128МБ. По сериен канал ще ми отнеме цяла вечност. Та мисля за USB. A най - оптималния вариант е информацията която записваш на карата да е в FAT формат и да си я четеш с готов четец. Лошото е че при мен даните пристигат с доста прилична скорост нон-стоп 24 часа и нямам време да менажирам файлове, камо ли FAT. A иначе ми излезе прижка на езика да ви рекламирам 18 серия на пиковете (на тия дето ползвате пикове де). Вземи един 18F452 имаш достатъчно рам за 2 флип-флоп буфера по 256 байта. Имаш два пъти повече мегахерци. Докато четеш флаша в единия буфер, по прекъсване пращаш другия през UART-a. И така не губиш почти никакво време. А цената му не е кой знае колко по висока от на 16F877.

Да бе, ти да не си рекламно лице на MICROCHIP Аз си поръчак два броя PIC18F452 вчера от Comet-а, така че ще ги видя...Но така или иначе проблема ми остава : желязото е вече готово. Още една новина - интерфейса е RS485, растоянието от Data-logger-а до PC-то е около 50-60м. Все пакк както вече казах няма да се налага да се прехвърлят всичките 32Мб през кабела (наи много 10, предполагам). Това е засега, аз си правя опитите тука, като гледам с по-чист и оптимизиран асемблерски код ще стане работата.

Е, добре стана работата: 1 000 000 пакета по 70 байта - 2% грешки на 115200 (кабела е 50 метра засега).