Не четете момчета. У(С)АРТА на пика за приемане е "прозрачен" за потребителя освен настройването му. Грижа се изисква при предаване.

Това което писах по-горе ще го напиша пак : УАРТ-а автоматично си засича, семплира и т.н. RX пина. След пристигане на 1 байт той ГЕНЕРИРА ПРЕКЪСВАНЕ и нищо друго. След пристигане на 3 байта дига флаг за препълване на фифото. Може и да се полва флага за прекъсване ама е неудачен вариант. Затова се прави рутина за обслужването му, желателно с висок приоритет. Така когато пристигне байт, се гарантира прочитането му от буфера своевременно и поддържането на фифо буфера Празен. От там нататък как ще си организираш данните е въпрос на вкус.

С други думи : ти трябва да приемаш постоянно, а не само когато си в някакъв режим на приемане. Готовите функции за изпращане ОК. ама за приемане какво готово ти трябва ?

Трябва ти :
1. да настроиш съответния инткон
2. да си напишеш съответното обслужване на прекъсването - там имаш : 2.1. прочитане на байта и 2.2. нулиране на флага. Другото както казах въпрос на вкус

Хора, какви прекъсвания, какви 5 лева? Видях, че става дума за 2400 бода. Имам бутлоудър за пик на 8MHz, baudrate 38400, без прекъсвания, приемането и предаването е пушка.
Барнах си един УСАРТ драйвер, който може да работи както в polling mode, така и с прекъсвания по отделно за Rx и Tx каналите. В случая полинг режима е повече от достатъчен, затова ще дам едно overview
Мога да ползвам Rx-а с буфер (кръгов) или да викам колбек (callback) за всеки получен байт. Лично аз предпочитам второто.
При Тx винаги имам буфер независимо от полинг/прекъсване.
Кода ще е нещо от сорта:


За набързо - толкова. Надявам се, че схващаш идеята.

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

Не, просто програмата му работи или само в приемане или само в предаване. И когато работи в предаване неможе да приема. Тва да полваш флага за прекъсване по RX е много тъпо. Що ли? Ами има няколко причини : 1. Защото си генерира прекъсване. 2. Защото с прекъсване софта ще обработва приемане само когато действително такова възникне. 3. Защото е глупаво каквото и да е външно събитие да се чака от програмата - те и затова си имат ПРЕКЪСВАНИЯ.

Няма абсолютно никакво значение дали е на 2400 или на 115000. В случая въпроса даже може да се каже, че е принципен, защото един ден ще се окаже че нещо не работи. И ще се окаже, че не работи заради лош код.

Едит:
Завърза се мохабет
RCIF сам по себе си не генерира прекъсване. Това е индикация за приет байт. Всеки си преценява дали ще го полва или ще предизвиква прекъсване - според ситуацията. И не случайно казах, че такъв подход съм ползвал при бутлоудър, просто защото имам достатъчно време и си спестявам грозни goto инструкции. Просто предложих и друга гледна точка. По-добре е младока да си отвори очите навреме за кооперативния мултитаскинг . Да няма после въпроси от рода на "имам 5 бутона за дебаунс, ама нямам толкова таймери" Щото прекъсванията изкушават, и в ситуация с много активни прекъсвания в даден момент, риска от тотална мазня нараства експоненциално.
В конкретния случай няма никакво значение кой подход ще избере.

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

@ Cekins:
Обработката в интеръпт безусловно трябва да е максимално бърза. Това е закон.
Бутоните бяха просто пример, и колкото и да е елементарен, някой бройлер може здраво да се омотае (примери във форума - колкото щеш).
Това, което искам да кажа е - да не се следват сляпо разни постулати, а да се мисли повече върху конкретната ситуация. Трябва да се знаят различните подходи, щото някой път няма да може по обичайния начин...

@Автора на темата:
Ако мислиш да се занимаваш и занапред с програмиране, постарай се и покажи структурирано мислене. Архитектура демек. Особено щом е дипломна работа. Разбий задачите по 'кутийки' - кое ще е апликейшън, кое - линк леъри (ако трябва), кое драйвери и т.н. Задачата ти е подходяща и могат да се получат хубави диаграми Разчертай събитията по време - особено комуникациите. Ей такива неща.

Определено ме замотахте още повече, аз наистина за пръв път се занимавам с програмиране на PIC и определено има доста неща които не са ми ясни. Чета и се опитвам да ги разбера, но понякога не е достатъчно.
Сега ще постна само main() функциите на двете платки както са в момента, така ще можете да видите какво точно правя и евентуално да кажете къде е грешката. Те по принцип са еднакви с разликата, че в единия main викам първо usart() и после kbd() а в другия обратно.
Основните функции с които работя в момента са usart() и kbd(), там някъде е проблема предполагам.......
Значи да уточня, че допреди натискане на '*' си работи предаването от едната към другата платка...........нещо се обърква след натискане на '*'...
Това е засега, ще чакам отзиви...........

Благодаря