Два UART в Си-style

[di_halt]

В общем есть мега 128. Хочется сделать бодягу примерно такого вида:

С первого уарта гонится сигнал на второй, со второго на первый. Крест накрест, короче. Причем сделать это на СИшных функциях вроде scanf и printf. Чтобы был форматированный вывод и такой же форматированный ввод.

В чем затык: Когда запускается scanf то он стоит и ждет данных. При этом естественно второй порт тоже не работет. Как их распараллелить? Или для сканфа и прочих навороченных функций это невозможно в принципе и надо на прерываниях вручную посимвольно буффера наполнять, а уже основной процедурой их обрабатывать и гнать на выход. Как бы вы решили эту проблему?

На асме я бы раскидал их по обработчикам прерываний от RX для уарта, а тут как?

С высокими языками никогда дела не имел, а тут решил освоить хотя бы Си. Вот и балуюсь. Для общего развития и потенциального роста.

[urry]

На асме я бы раскидал их по обработчикам прерываний от RX для уарта, а тут как?

Точно так же

[di_halt]

Сообщение от di_halt

На асме я бы раскидал их по обработчикам прерываний от RX для уарта, а тут как?

Точно так же

То есть придется забыть про встроенные сишные функции и самому заново изобретать велосипед?

[GLVlad]

int main()
{ char c;


uartInit();
uartSetBaudRate(0, 9600);
uartSetBaudRate(1, 9600);

__asm("sei");

// uartSendByte(1, 'S');
// uartSendByte(1, 'T');
// uartSendByte(1, 'A');
// uartSendByte(1, 'R');
// uartSendByte(1, 'T');
// uartSendByte(1, '\r');
// uartSendByte(1, '\n');


while (1)
{
if(uartReceiveByte(0,(u08 *)&c))
{
uartSendByte(1, c);
}

if(uartReceiveByte(1,(u08 *)&c))
{
uartSendByte(0, c);
}
}

return 0;
}

Пользовал функции из библиотеки AVRLIB

[urry]

Преимущество си - имхо, конечно - в возможности структурирования данных, более читабельном тексте и в огромном количестве готовых исходников - так что велосипед изобретать не придется. Что касаемо функций, которые встроены в компилятор - подходить нужно осторожно и вдумчиво .
Пример - только по моему любимому хайтеку - реализация и2с обмена написана с ошибкой, функция задержки неправильно работает на частотах больше 12 мегагерц тактовой, обмен по уарту - тоже без слез не взглянешь - постоянный опрос и отсутствие реакции на ошибку обмена.
Но это не значит, что компилятор плохой или на си серьезные вещи написать невозможно - существуют форумы (прежде всего по конкретному компилятору), где эти вещи уже описаны, как и средства борьбы с ними. Вот сначала туда,а в инете примеры - как люди делают...

[di_halt]

int main()
{ char c;

...

Пользовал функции из библиотеки AVRLIB

Да это то понятно, только также я и на ассемблере сделаю с теми же затратами усилий и времени, ну будет на 10 строк длинней.

Оно ведь посимвольно, а я хотел использовать мощь Сишного форматированного ввода вывода.

[tempora]

Оно ведь посимвольно, а я хотел использовать мощь Сишного форматированного ввода вывода.

А как может scanf угадать формат строки, если она еще не принята? Так-что, первоначальная идея:

...надо на прерываниях вручную посимвольно буффера наполнять, а уже основной процедурой их обрабатывать и гнать на выход.

почти правильная - только никто не обязывает в основной процедуре делать обработку - наполняем буфер, пока не придет конец строки, а как пришел - обработка. Тут скорее другим местом отзовется - принтэфы и сканэфы писаны "на все случаи жизни", от чего их код довольно большой и, следовательно, медленный, по сравнению с собственной процедурой, которая "знает" заранее, какой у строки формат. В общем - мыслишь правильно, но как-то... застенчиво. Смелее надо быть - ресурс перезаписи у меги не такой уж и маленький.

[di_halt]

[quote="tempora"]

А как может scanf угадать формат строки, если она еще не принята?

Ну разумеется не сможет, но я мыслил то как. Ведь сканф в любом случае куда то данные пихает для предварительного анализа? И вот если его в этот момент прервать, все данные сохранить, и кинуться обнюхивать другой порт, но не запрещая прерывания, чтобы следующий же символ прервал нас снова и вернул обратно. И тогда символ тут, пока он принимается, кидаемся принимать символ там, потом обратно... Правда тут может стека нехватит, причем конкретно так, или возникнут косяки с недовыполнением операций изза резкого прерывания. ))))) Это если в классической реализации. Но может какие извращенные методики есть.

Про то что они слоноподобные и тормозные я уже убедился когда глянул асмовские листенги. Столько дерьма, аж в голове не укладывется. Но для меня сейчас главное не столько практическое решение (задача то ближе к экспериментам!), сколько методология решения похожих проблем.

[tempora]

Ведь сканф в любом случае куда то данные пихает для предварительного анализа? И вот если его в этот момент прервать, все данные сохранить, и кинуться обнюхивать другой порт, ...

Для того, чтобы эти данные сохранить, нужно еще знать, где они лежат, а чтобы без проблем приостановить работу процедуры и вызвать некое другое место в коде, нужно быть уверенным либо в том, что код, работающий в это время, не вызовет сканэф снова, либо в том, что сканэф - реентерабельна. Все это возможно только при одном условии - сканэф должна быть твоей процедурой.

Про то что они слоноподобные и тормозные я уже убедился ... Столько дерьма, аж в голове не укладывется.

Правильно - я ж говорю, они написаны в расчете на общий случай; мало ли кому какое дерьмо в пути понадобится - нужно запастись всяким! Еще спасибо, что есть варианты - с целочисленным дерьмом, с плавающим дерьмом - хоть от чего-то можно отказаться, если известно, что оно точно не понадобится.

Но для меня сейчас главное ... методология решения похожих проблем.

Так ведь ты ее правильно вычислил, методологию-то - берешь управление на себя (а иначе - нафига ты нужен(?), контроллер бы все сам сделал, если бы таким вумным был ), а сканэф вызываешь для того, для чего она была написана, и не более того.
Если представить себе сканэф твоей мечты (и еще чьей-нибудь - не одному же тебе масленица) - с вызовом callback'а по случаю ожидания символа, с вызовом callback'а после получения символа, с вызовом callback'а по получении escape-последовательности, по таймауту, по делению на ноль, по получении недопустимого символа, по случаю возврата кода ошибки из callback'а, по выходу за границы буфера, во выходу преобразованной величины за границы, по неисправности в канале вывода, в канале ввода, по провалу питалова, ожидающей ввода с USART'а, с USB'ей, из блютуса, из черта лысого, бла-бла-бла... то имя у такой сканэфы несколько изменится, и не ты будешь вызывать её, а она - тебя, как всякая нормальная операционная система.
В общем, сдается мне, что ты мудришь лишь из-за нерешительности - шли её нафик и бери мэ-ка за рога.

[di_halt]

В общем, сдается мне, что ты мудришь лишь из-за нерешительности - шли её нафик и бери мэ-ка за рога.

Да лень мне просто, ведь хочется чтобы все, сразу и само ))) А так выходит что Си это те же яйца только сбоку.