Уже год пишу на АСМе для AVR, для повышения квалификации, хочу освоить и С.
какие могут быть рекомендации, если в данный момент уровень знаний о С никакой
подскажите какие книги лучше читать, может есть какие нибудь экспресс методики по освоению языка.

для начала Керниган и Ритчи.
http://khpi-iip.mipk.kharkiv.edu/library/pgm/kr/
а дальше уже сам, разбираясь в чужих кодах и примерах

Спасибо, к сведению принял!
в общем старанье и труд... ну и как завещал великий Ленин =)

а еще меня волнует очень-очень глупый вопрос - есть какая-нибудь разница м/у С, С+ и С++?

Может, C#, а не C+? Есть, конечно. Начинайте спокойно с C, потом придет понимание, нужно ли Вам остальное.

душевное спокойствие востановлено )

Самая лучшая экспресс-методика - побыстрее начать что-то колупать руками и попутно решать возникающие вопросы.
А читать надо начинать с первоисточников, а не самоучителей типа "С++ за полчаса"

Можно было и раньше, в
http://electronix.ru/forum/index.php?showtopic=20372&hl=

там есть ссылка на

Название: Программирование на языке C для AVR и PIC микроконтроллеров
Автор: Ю.А. Шпак
Издательство: МК-Пресс
Год: 2006
Страниц: 400
Формат: djvu
Размер: 9.20 Мб

Хм-м... написание софта на ассемблере будет по-сложнее сишных упражнений.

Написание "моргалки светодиодом" на ASM, впрочем как и на Си, не есть ни исскуство ни упражнение для ума. Поскольку, к сожалению, очень часто писание на АСМ останаливается
на уровне "очень продвинутая моргалка светодиодом", то.... Я бы совершенно не гнул пальцы по поводу "сишных упражнений" . Оборотная сторона ASM писания - на любом языке можно писать и пишут , как на ASM, только это ЖОПА, хотя очень многие остановившиеся в развитии на ASM этого не понимают. Для понимания, ну как минимум, надо все-же надо начать занисматься "сишными упражнениями", да и C++ тоже.

При написании программ на ASM много времени уходит на сам ASM.
Тем не менее. Подобный софт при правильном расположении комментариев - вполне читаем и сопровождаем. Тому пример - мнемокод PLC, на котором ваяет свою нетленку достаточно большое количество разнообразного по уровню интеллекта и опыту народа во всем мире. Могли бы и там сделать нечто, похожее на С. Однако ж по сей день никто ничего в этом направлении не делал и не собирается. Так что есть люди, считающие, что ASM - вовсе не ЖОПА, а несколько иной орган.
С при правильном к нему отношении - язык самодокументируемый, требующий минимума комментариев. Не говоря уже о С++, позволяющему пользоваться отработанными чужими решениями, не вникая особо в их "внутренности". Модифицировать их под собственные нужды. Ну и т. д.
Так, что здесь, ПМСМ, все определяется только поставленной задачей.

До тех пор, пока обширные комментарии соответствут текущей реальности а не предыдущей. Особенно хорошо смотрятся "правильные" комментарии к ошибочному коду. Комментарии не есть панацея, для ASM особенно.

Перечитайте внимательно написанное мной. Там нет этого слова по отношению к ASM.

Я и имел в виду не сам ASM, как таковой, а текст на ЯВУ в стиле ASM. Прошу прощения за нечеткость изложения.

Посмотрите тексты программ на IL или LD для PLC от SIEMENS, к примеру. Все достаточно хорошо структурировано.
Система сама предлагает расположить комментарии в нужных местах. А то, о чем Вы говорите, пресекается системой контроля версий.
Более того, там есть средства, позволяющие закрепить отработанные решения в виде различных функциональных блоков.
На мой взгляд, проблема все-таки лежит не в ASM или С, а в неком уровне абстрагирования самой программы от внешней среды.
По ряду причин программист не хочет отходить от "железа" и пишет "в стиле ASM". В некотрых случаях, типа PLC, это просто не нужно.
Ассоциации здесь достаточно примитивны - датчик -> вход -> булева переменная. Т. е. аналог "ногодрыжества" в гипертрофированной форме.
Более того, само железо уникально, технические решения не требуют повторения. В следующем проекте все будет по-другому.
ЯВУ в этом случае просто вреден, ПМСМ, опять же.
С другой стороны, все люди разные. Кто-то может абстрагироваться от внешней конкретики, а кто-то нет. Чисто физически... Просто не дано свыше.
Точно так же, как кто-то не может опуститься до уровня отдельных битиков.
На мой взгляд, тот или иной стиль определяется сочетанием кучи факторов, начиная от самой задачи и заканчивая чертами характера конкретного индивидуума.

Так сложилось, что жисть заставила в очередной раз открывать учебник, начал сегодня листать Н.П. Деменков "Языки программирования промышленных контроллеров". Нахожусь пока в смятении и недоумении, особенно глядя на LD , у них что там, интерпретатор в ПЛК сидит?
Возможно, нужно было начать свою ветку, но пока воздержусь. Уж простите, что не совсем по теме топика.

Таки да.
Что ещё хуже - этот LD крепко сидит в мозгах тех кто делает и применяет такие PLC, никакими С-с_чем_угодно его оттудова не выбьешь - упираются, всяк на своём стоит...

Это проблемы не языка, а развития технологии компиляции и оптимизации. А текст на ЯВУ в стиле АСМ  не всегда вреден. Например: использование битовых полей вместо битовых масок порождает зависимость от правила выделения бит. Ессно, для структур имеющих дело с вводом/выводом, такое неприемлемо.

Есть ветка про nano-PLC на AVR, народ голову ломал, как же линковать функциональные блоки в финальную прошивку на целевом контроллере. 
http://electronix.ru/forum/index.php?showtopic=40070

Неприемлимо только не знать языка и инструмента. А именно незнание и того и другого, и является отличительной чертой пишуших на языках высокого уровня, как на ASM. После чего и обильно рассказывающих глупости об ограничении свободы самовыражения, глюках компиляторов, тормозах....

Мм_да; // , похоже тоже придется психологический перелом испытывать (потому как исходники имеющегося оборудования на LD написаны), покруче чем переход с асм на Си будет .
Я так прикинул, что те задачи, к-рые решаются в имеющимся оборудовании с помощью ПЛК, можно решить обычным восьмибитником, и на проядка два дешевле, разве что HMI панели купить придется.
ГЫ, любопытный фрагмент из вышеупомянутой книги, т.е. стандарт, это вовсе и не стандарт, а рекомендации.

Это, ПМСМ, как раз и связано с неким периодом адптации в новой среде.
Появляются новые возможности, новые типы данных, другая структура программы и данных.
Естесственно, все сразу получиться не может. Отсюда и желание - назад, в пампасы.
А свободы самовыражения на ЯВУ, естесственно, больше. Глюков компиляторов С пока не наблюдал.
Оверхед есть, но даже для МСС18 им можно пренебречь в угоду возможности отойти от железа и мыслить в терминах задачи, как таковой.
Впрочем, это мое частное мнение.


Здесь несколько иной подход. Лестничные схемы (LD) предназначены для работы исключительно с булевыми переменными. На это же и ориентирована и псевдоархитектура PLC. Она достаточно примитивна, но в этом ее основной +. С обычным восьмибитником будет сложновато, особенно, когда дело дойдет до плавающей арифметики или синусов с косинусами.
Здесь надо просто осознать, что вся автоматика сводится к манипуляции с битиками. На С в этом случае получались бы маловразумительные длинные условия и было бы некрасиво.
Кроме этого, такой способ программирования на самом деле облегчает отладку длинных логических выражений.

Ну не знаю , пока что у меня к этим ПЛК какая то внутренняя неприязнь, буду прообрвать бороться . Пока что вижу: контроллер от Omron, пара блоков расширения, и бомбить 32х битным RISC ядром по пятку релюх и столькИм же датчикам, рука бы не поднЯлась, ктому же, "плавучкой" там и не пахнет. Есть там еще ModBus, но то так, чтобы оператор с панели частотнику частоту зАдал, я бы нашим операторам лучше всего пару кнопок вывел Пуск/Стоп, а то и вообще- одну .

Я бы для осознания процесса порекомендовал бы сначала поиграться с так называемымы "реле" в виде ZEN от того же OMRONа или LOGO от SIEMENS. Для ZENов существует симулятор. Так что можно и виртуально все это сделать...
А что касается 32-битного ядра, то в данном случае это уже не важно... Есть варианты PLC и на AVR.

Я бы посоветовал поискать , в дополнение к K&R Герберт Шилдт (Herbert Schildt) The Complete Reference (Полный справочник по С).
Оцифровал Воробьёв П.А. http://lord-n.narod.ru/download/books/wall..._po_C/about.htm

Я думаю, на уровне функциональных блоков можно поставить водораздел между 8 битниками и 32-х, и пускай 8-битники живут в PLC. Кстати, 43мкс на ATMEGA88/20МГц - бенчевое время для вычисления плавучего кубического сплайна. Тоже не много с учетом 100мкс типичного времени реакции. С тригонометрией и экспонентами дела похуже, конечно


Огласите их поименно, плз

К сожалению, пока что железа доступного для обучения и "лабораторных работ" нет. Имеется тут некий зоопарк из работающих Омронов, Сименс и Мцубиши, еще Дельта с татчскрином скоро приедет,- не знаю пока, что со всем этим делать... наверное с асм на Си проще перейти, а главное, во всех этих примочках нарушен принцип KISS, который как бы, стараюсь блюсти..
ЗЫ, топикстартеру- начните с ассемблероподобного стиля, Си к этому располагает, ну а потом уже потихоньку( или как пойдет) перейдете на высший пилотаж, и пусть меня zltigo не ругает (он потом подскажет), не все ж горшки сходу обжигают

Здесь это уже было как -то.
По моим данным вот это AVR.
Можно и попроще - это точно AVR, весь верхний ряд.
А можно и совсем просто - тут AVR и PIC.
Софт по последней ссылке опробован на PIC16F877. На удивление, все работает. Правда, память быстро заканчивается.
Можно и еще чего-нибудь добавить...