Два, три дни си бях дал почивка, защото... както се казва ме беше обзела "Творческа безисходица" . След работа пак ще направя някой друг опит. За сега нещата не изглеждат добре. Започнаха да свършват идеите. Сега съм написал програмката да ми дава следващите 3 байта (block_length, block_cnt, block_title) след задължителните 3 байта (0x55,0x01,0x8A). Имам чувството, че бъркам някъде тук:
int kw1281_get_id_device ()
{
int i, cnt;
char text[5][16];
cnt = 0;

do
{
block_length = kw1281_get_byte();
block_cnt = kw1281_get_byte();
block_title = kw1281_get_byte();

printf(lcd_putc,"\n%X", block_length);
printf(lcd_putc,"%s", ",");
printf(lcd_putc,"%X", block_cnt);
printf(lcd_putc,"%s", ",");
printf(lcd_putc,"%X", block_title);

if (block_title == 0xF6)
{
for (i=1; i<=block_length-3; i++)
{
text[cnt][i-1] =kw1281_get_byte();
//lcd_gotoxy(i,2);
//printf(lcd_putc,"\%c", text[cnt][i-1]);
}
getc();
cnt++;
kw1281_send_ack();
}
else
getc(); //* Край на блок, когато block_title не е равен на 0xF6 (няма ascii данни)
} while (block_title == 0xF6);
}
Тук правя проверка за аски данните и някъде тук зациклям и това е причината въобще да не стигна до следващата функция за визуализиране на данните.

Според мен махни всички 'printf(lcd_put....' и вържи един светодиод към Rx и Tx. Така най-добре ще видиш дали имаш комуникация и дали ти върви софта. За индикация по-добре си вържи още няколко светодиода към ПИК-а - най-добре така се дебъгва. Тези обръщения към ЛЦД-то може да ти отнемат пове4е време отколкото си мислиш и да не можеш да отговориш на ЕКУ-то навреме. Направи го съвсем простичко, без излишен код, така 4е да подкараш комуникацията стабилно.

Това, което казваш е много добра идея. Ще вържа по един светодиод към Rx и Tx и ще махна всички "printf(lcd_put...." Тогава ще направя проверка пак на същите байтове и ако са верни ще засветвам по още един светодиод. Наистина това ще отнеме значително по-малко време отколкото да показвам на дисплея.
Вчера проведох няколко експеримента и разбрах, защо невлиза в функцията за визуализация. След трите задължителни байта, които показа вярно, следващите три нямаха нищо общо с реалността. На дисплея за block_length, block_cnt, block_title показа 0x55, 0x01, 0x8A. Учуди ме защо показа отново първите три байта но 1 и 2ри байт бяха разменени. Сякаш ми се рестартира комуникацията и започва отначало. Прочетените байтове бяха 0x55, 0x8A, 0x01, 0x55, 0x01, 0x8A. Първите три са верни, но за дължината на блока, брояча и името на следващия блок полуяавам това. Нещо май комуникацията се рестартира, но дори да е така байтовете защо са разменени. Оттам нататък е ясно защо нямам нищо на дисплея. Вижда се че още в началото нещо се бъгва. А не би трябвало да е така защото ето това е проверката за първите три байта:
void kw1281_ecu_sync ()
{
//int ecu[3] = {0x55,0x01,0x8A}, i;
int ecu[3], i;

for (i=0; i<=2; i++){
ecu[i] = getc();
}
if ((ecu[0] == 0x55) && (ecu[1] == 0x01) && (ecu[2] == 0x8A))
{
putc (0xFF-ecu[2]);
getc();
printf(lcd_putc,"\fConnection.. OK!");
Delay_ms(200);
printf(lcd_putc,"\f%X", ecu[0]);
printf(lcd_putc,"%s", ",");
printf(lcd_putc,"%X", ecu[1]);
printf(lcd_putc,"%s", ",");
printf(lcd_putc,"%X", ecu[2]);
}
else
printf(lcd_putc,"\fNO Connection...");
}
Както виждаш веднага му пращам разликата от 0xFF и той веднага би трябвало да ми отговори 0x0F, 0x01, 0xF6,вместо 0x55, 0x01, 0x8A. Изобразяването го правя по-надолу и не би трябвало да има забавяне. За хардуера също съм сигурен че правилно съм го вързал, зашото получавам, първите три байта верни следователно чета правилно. Нещо се рестартира явно, но незнам защо. Хайде днес пак ще правя опити

За такава малка програма защо не минеш на ASM там поне може да преброиш за кои инструкции колко време ти отнема и ако има нужда от повече си правиш някакво закъснение и всичко ще много прецизно.

Благодаря за идеята plameniv, но май ще се окаже друго. От тестовете и опитите, които направих версиите са две.
1. Функцията FORCE_SW във версия 3.249 на компилатора не работи добре
2. Стара ревизия на PIC16F877 (Не знам дали има по-нова?)
Направих програмката, така както nickich ме посъветва и сложих светодиоди за диагностика. Направих така, че когато получа първите 3 байта (0x55,0x01,0x8A) и те са верни да светва светодиод на Port B1, а когато получа 2те 3 байта (0x0F, 0x01, 0xF6) да светва светодиод закачен на B2. Оказа се, че на симулация на Proteus всичко това работи перфектно, щом програмирам чипа и тествам абсолютно същата програмка на пинове б1 и б2 не се получава единица и светодиодите не светят, а байтовете съм симулирал че са верни. От тук стигам до извода, че нещо чипа не е наред или е ревизия която не работи с FORCE_SW.
Когато махна FORCE_SW на пин б1 и б2 се появява единица, с тази разлика, че вече не мога да събудя ЕКУто, защото когато не е включена тази опция в инициализирането на серииният канал не мога да използувам пинове ц6 и ц7 като обикновенни пинове. Оттук пък стигам до извода, че нещо тази функция не работи коректно св тази версия на компилатора. Така си обяснявам и сегашният проблем. Като не работи коректно тази функция, се получава следното. Тя прави така, че да ползувам пинове с6 и с7 като обикновени входове/изходи (затова успявам да събудя ЕКУто), но тъй като не работи коректно след събуждането не ми превключва комуникацията на 9600 и затова получавам такива странни байтове. Това е само предположение, разбира се.
Въпросът ми е към всички: Някой ползувал ли е функцията FORCE_SW и в коя версия на компилатора работи добре?
Сега след работа мисля да купя PIC16F877A. Дали това е подобрена версия от PIC16F877? Възможно ли е да ползувам стара ревизия и затова да имам такива проблеми? Тези пикове съм ги копувал преди 5-6години.

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

А що не пробваш да вържеш ПИК-а към ПЦ-то и да си напишеш една програмка (примерно ехо (да ти връща полученото)) и с един терминал да пращаш АСКИта и да гледаш дали ще ги получиш. Може да си оставиш функцията за събождане на ЕКУ в началото и да жидиш дали ще ти мига диода.... примерно....

Мисля че ефекта ще е същия.
Проблема си е точно в неясните закъснения, преди седмица си правих програма за RFID и дисплей , оказа се че всичките проблеми при четенето на кода идва от неточно изчисление на закъсненията
Когато ги сметнах както трябва и всико запя
Не е лошо да се помисли първо да се изчита целия код и едва след това да се извежда на дисплей , извеждането на дисплея си е с доста операции и има много глеми закъснения.
А за самото закъснение си има проста и точна реализация с таймер, нагласяваш си делителя предварително на колко да дели зареждаш таймера и го чакаш да вдигне бита на прекъсването.

DLY
BCF INTCON, 2
MOVLW ..........
MOVWF TMR0
Time...
BTFSS INTCON, 2
GOTO Time...
RETURN

@plameniv, май си прав! ...все пак нали се полу4ават първите байтове...

Виж този пример :
http://trip.on.ufanet.ru/soft.html

plameniv, благодаря за примера, но той едва ли ще ми ппомогне в моя случай . Благодаря ти за помощта. Все повече започвам да се убеждавам, че проблемът е в тази функция FORCE_SW. Махна ли я всичко е ОК. Управлявам си всеки пин от портовете както искам, сложа ли я става мазало. Нещо не работи както би трябвало или аз нещо не я ползвам както трябва. Потърсих и в другите форуми и много хора се оплакват. Проблемът идва оттам, че искам да ползвам пинове С6 и С7 като обикновенни пинове и веднага след това да ги ползвам като приемник и предавател в хардуерен Усарт. Тази функция би трябвало да прави това превключване, но нещо не го прави. Ако някой е ползувал тази функция нека да пише. Тук е проблемът според мен, в превключването от единия режим в другия като хардуерен модул. Дано някой да има опит с използването на тази функция, защото тук ще си и остана . Махнал съм от програмата всички printf(..... и за диагностика превключвам само пинове. Без тази функция всичко е наред, сложа ли я става боза. За съжаление трябва да работя с тези пинове и се налафа да ползвам това превключване от 5 бода в 9600.

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

А защо след като събудиш ЕКУ-то просто не преинициализираш контролера и тези пинове да са ти UART ве4е. Няколко инструкции са.

Здравейте!
Следя темата почти от самото начало. Интересна ми е. Та по същество. Имал съм си ядове при преконфигурирането на UART модул по време на работа. Става въпрос за MSP, но това не е важно в случая... Според мен е по-добре, ако е възможно UART модула да се използва без да се преконфигурира, т.е. съответните изводи на порт С да са само за UART-a. Ако това е невъзможно, пробвай да ресетираш самия модул. Не успях да намеря откъде става при PIC-овете, но в моя случай имаше как и това определно помогна.

Също зависи в какво състояние са пиновете преди да ги инициализираш като HW USART.
Защото за HW USART се изисква да ги направиш входове и при положние , че са били изходи преди това може (без да искаш*) да генерираш стартбит и да се приеме един 0xFF или 0x00 байт.

*- взависимост от състоянието им