Значит в принципе не имеет особого значения поставлю я 10uF электролит или 0.1uF?

в принципе надо такие как написано в даташите на Вашу микросхему - или бОльшие, но уж никак не меньшие, хотя пробівать можно - будет работать та и ладно

Спасибо за пояснения. С аппаратной частью разобрался. Есть вопрос по работе с GCC. У нее есть функция printf(), где-то читал что для ее работы нужно дописать еще функции getch() и putch() и подключить библиотеку stdio.h, если не так поправьте или поясните почему так?

Просто помотрите примеры WinAVR в папке
C:\WinAVR\doc\avr-libc\examples

и руководство по библиотекам GCC WinAVR ПОЛНОЕ в папке
C:\WinAVR\doc\avr-libc

И советую прочитать задачу-упражнение 5 "применение UART AVR USART ATmega" в - Учебный курс по AVR начинающим с нуля - в моей домашней страничке - кнопка www под этим сообщением.

Уважаемый ikarab читал я Ваш разрушающий мозг курс, и уже на первой странице меня стошнило, сколько Вам платят за раскрутку?

GCC - это не только WinAVR, для тех кто не знает, это вообще целая религия:)), и вообще WinAVR - это урезанное и адаптированное под форточку ответвление от GCC библиотек Linux'a, коим я и пользуюсь. Если есть что сказать по делу говорите, а лишний раз PR'ить свой сайт - для этого есть спец. раздел - ссылки, вам сюда http://radiokot.ru/links

это так.
stdio.h подключает всякие printf и т.п.
дописывать, точнее, определять собственные реализации, надо для функций ввода и вывода символа, как они будут конкретно называться - все равно (т.е. не обязательно getch и putch). это нужно потому, что базовая реализация avr-libc не содержит средств работы с конкретной аппаратурой - это задача программиста. то есть вы можете определить ввод символа с модуля USART, а вывод символа - на LCD-дисплей (или ЖКИ), можете обе реализовать в ориентации на USART, а можете - на что хотите то есть такой подход дает большую гибкость.

То есть, подключая stdio.h в GCC, и, используя USART, необходимо просто дописать эти функции, ориентированные именно на него:и?

Еще встречал функцию printf_P();, но при ее применении надо писать так: printf_P(PSTR("собснно _текст")); и подключать помимо stdio.h еще и pgmspace.h. В чем их отличие и какая лучше? Насколько мне известно, там что-то с занимаемой, при их использовании, памятью связанно.

дописать эти функции недостаточно - следует еще проинициализировать потоки ввода-вывода, чтобы они "узнали" о ваших функциях. ну и конечно, сам USART проинициализировать...

printf_P(), как и ряд других функций с суффиксом _Р, работают со строками, находящимися во FLASH, а не в ОЗУ - вот и вся разница. в чем выгода? FLASH всяко больше, чем ОЗУ, и строковые константы, которыми всегда являются строки-форматы, разумнее хранить в сегменте кода...

Эм... А как?

Эммм...Выскажусь и я......помоему для 99% задач вполне достаточно было бы поверхностно изучить CodeVisionAVR и пользоваться его примитивами и либами!
Там уже всё реализовано и реализовано неплохо. Да код не всегда оптимален, Да генератор начального кода очень интересный но для НАЧАЛА.....помоему там есть всё! Даже возможность переназначать своими обработчиками функции стандартного ввода-вывода, зато по умолчанию они уже прекрасно работают с последовательным!
Да и вообще с уартом не всё так просто...
Надо сразу решить что с уарта ловить будем - строки или отдельные символы....если символы - лучше было бы реализовать буферизированный приём по прерыванию...Потом я же сомневалюсь как-то очень сильно что Ваш МК ничем больше кроме как висеть ожидая символа с уарта заниматься не будет? наверняка чтото делаться будет! И как делать это чтото? если по обработчику прерывания - возникает проблема отсутствия очереди прерываний у авр стека прерываний нет увы...поэтому и много не наработаешь в прерывании - надо цыклиться в основном цикле и проверять есть ли чтото в буффере приёма - если есть - запустить обработку приёма уарт данных, есть ли флаг переполнения таймера - тож чегототам сделать и так далее....целая система уже сразу городится

clawham, ваши опасения напрасны. ничего страшного в ожидании ввода пользователя нет. придумайте навскидку задачи, где это критически важно? просто для примера - обсудить

VenomXP, спрашиваете КАК? а не пробовали читать документацию avr-libc? или, на худой конец, возьмите примерчик, который совсем недавно я выкладывал для примера работы с вводом строк (в другой теме, конечно - поищите, это было не более 2 недель тому назад) и поглядите, как происходит настройка ввода-вывода...

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

Ну или как у меня - обновление раз в пол секунды термометров, + контроль за напряжением питания + расчет от температур необходимости запустить таймер включения или таймер выключения компрессора, потом собственно проверка буффера ком-порта, если не пустой - отработаем его пока есть свободное время(задержка в 500 милисекунд на завершение преобразования температуры) ну и так по циклу
а если небуферизированно...как тогда?
да если каждый символ кидать через задержку из компьютера или...ну я даж не представляю как БЕЗ этого
Ведь если кинуть пару символов подряд на скорости удвоения 230000 бит/с то к моменту чтения у вас в регистре приёмном уже окажется кусок нового символа. А так прерывание клац по факту прихода и следующий такт уже читает регистр приёмный, вот да.. потом обработчику прерывания понадобятся ещё 8 тактов - сохранить результат в буффер и инкрементировать счетчик записи но...в это время спокойно себе приниматься начал второй символ...который снова сгенерит прерывание по завершении и так далее....

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

Случайно не это ли:http://radiokot.ru/forum/viewtopic.php?p=242764#242764?

пока что на примере моего несчастного устройства которое вот этим занимается выявлено то что чтобы там нибыло а с буффером гораздо проще и глюков сразу мраз - и нет, + многопоточность!
Да...у нас нету ДМА в камне...но его можно организовать системой прерываний в принципе и так неплохо
сейчас вот думаю как на ББ сделать подобие мютекса - чтоб блокировать возможность передачи из нескольких потоков вообще пока не прийдёт разрешение из кома.
но мютексы мониторы ЛОКи всё не помогает...нельзя подтверждать блокировку...а мне надо сто раз заблокировать один РАЗблокировать и потоки, ожидающие очереди должны полететь...
у меня в Компе 3 потока...1 поток - читалка последовательника
2 поток - вывод всякой статистики в текстовом формате в ком прт
3 потом вывод картинки вращяющегося куба
вот 2 и 3 потоки должны останавливатья пока нету разрешения от первого и....потом ещё ждать если какой-то из них первее запустился поставив снова блокировку в начале и сняв потом....приколы как в МК по типу while(!CanTransmit) ; не канают - проц загружается и фоновый поток чтения не отрабатывает

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

Ога, спасибо за материал. Изучаю. Еще маленький вопросик, можно ли упростить функцию printf_P(PSTR("bla_bla")); до такой BuBoD("bla_bla"); путем введения такого #define BuBoD(x) printf_P(PSTR(x)) ? Для простых математических операций это проходило, но здесь же строка.

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

У меня вот какой вопрос назрел - кто реально видел материнки у которых есть скорость ком-порта выше 128000 ?
меня это задирать начинает...115200 конечно быстро но.....контроллер то может отработать и 2 мегабита а не каких-то жалких 115200 бит/с
Может какие-то дрова можно поставить или так ПЛ2303 в юсб втыкнуть?

Кстати.. такие навороты нужны когда пишеш программку которая будет как бы сервером, а к ней уже другой программкой подключаются сотни и тысячи клиентов(шутка конечно но 2-3-4 могут быть)
и вот каждый из них чётатам хочет сделать один - посмотреть просто архив графиков температур, второму интересно напряжение сети, состояние аккумулятора резервного, ктото хочет посмотреть включен ли свет-холодильник-кондиционер, холодит ли кондиционер, закрыта ли дверь....
каждый то работает в своём отдельном потоке - это сокеты по другому никак....+ ещё поток основной программы 20 раз в секунду шмалит в ком порт ленту из 48*84 бита по таймеру тоже кстати сволочной таймер - отдельный поток + ещё есть аварийный поток в программе если комп перегружается - например когда инет пропадает
вот и получается масса хрени летает по КОМу в мк и из мк...вот и получается такое требование к синхронизации потоков в ББ и мк....
самое убийственное это конечно перерисовка графического жк экранчика....на скорости 115200 это просто изврат а большего не позволяет развить мамка....ни моя ни та что на серваке....(((
и не стоит ещё забывать что МК сам по таймеру раз в 500 милисек выдаёт в ком порт не что иное как результат замеров температур(а у меня их уже 9 штук) + раз в 100 мсек выкидывается в порт состояние нажатий кнопок и состояние нажатий кнопок на пультике ИК RC5 + всякие там флаги типа повторения удержания и т.д. - в мк на это всё отдельные подпрограммки мониторящие каждый цикл есть ли что передавать и если есть - не арновато ли в общем целая система получилась...
и вроде всё просто и вроде не нагрузочно...но если не в попад кидаться в ком порт получаются бяки....подвисоны и так далее....

Я недавно писал кому-то диплом по похожей теме - запись данных из пика в мускулевскую базу.
Имхо, любая современная материнка поддерживает 256 килобод.
Когда используешь класс сериал порт (пишу на вижуале), то класс начинает материться на скорость выше этой.
Если интересно, то выложу исходники.

ЗЫ. Только что проверил, прекрасно ком-порт работает на 256000 бод.
"В консерватории что-то менять надо"(С) М.М.Жванецкий

я пишу в вижуал студие на с#
создать объект сериан с скоростью выше 128000 невозможно - матерится и не создаёт
а на скриншоте параметры порта - там и вправду 128000 не более
панятное дело читал я на свой винбонд даташит у него до мегабита сериалка работать должна по идее.... потому хотелось бы ваш исходник - или хотябы готовую прогу - посмотреть сможет ли она проинициализироваться на 230400...если да то...наверное на плюсах напишу длл для серийника а в шарпе уже её юзатиь буду как импортированную функцию...

завтра возьму кабель от самсунга - там пл2303 помоему и 512 разрешал, я когда-то х100 х600 перепрошивал юзал этот кабель и помоему там скоростя были и под мегабит только телефон уже не успевал