Если ктонибуть этим занимался поделитесть опытом, ну или ощущенями
Собираюсь скоро этим занятся, а пока учусь.. [Ответ]

пишу под avr'ки. вполне прилично
pic и прочие "недопроцы" нелюблю по причине бедности комманд и убогости архитектуры, если будут вопросы или заказы на схемы с avr'овскими камешками - милости прошу стучатся ко мне ) [Ответ]

peace_man, поверь, никто тебя писать учить не будет. Разбираться должен сам, а подсказки просить если уж в тупик совсем встал.

ЗЫ: Какой тип контроллеров выбрал? [Ответ]

Сообщение от :
peace_man, поверь, никто тебя писать учить не будет

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

если не выбрал еще какие контроллеры кодить будешь - выбирай avr. из доступных - реально классные камни и встроеной периферии дочерта и програмить их просто и отладчики/эмуляторы путевые есть [Ответ]

Дерусов Николай, вот ты и будешь учить. [Ответ]

Дерусов Николай, Привет есть вопросы по Attiny2313.Напиши свой телефон. [Ответ]

стучи лучше в асю 293/660/233. по телефону лениво.
ps: пишу я на ассемблере, с Си не приставать!!

2Leo
буду краток - триста баксов [Ответ]

Сообщение от Дерусов Николай:
2Leo
буду краток - триста баксов

Эт не мне - эт peace_manу нада.

Шурик2, пиши уж на форум. Мож чем и помогу. Кстати да, тоже пишу на ассемблере, с различными Сями не приставать. [Ответ]

Ну... раз превратили тему во флудильну, то и я свои 5 копеек вставлю. Пишу на STL(Стандарт IEC 61131-3)
Ещё LAD немного и почти все языки попадающие под стандарт - по чуть-чуть(как раз сообразно их возможностям) [Ответ]

Сообщение от XPEH_BAM:
Ну... раз превратили тему во флудильну, то и я свои 5 копеек вставлю.

А я вот на ворде пишу( иногда даже получается ).
P.S. Закрывайте нафиг тему, а то щас начнется....

Тут обсуждать то нечего PIC + ассемблер спасет мир [Ответ]

dr.ON, на Пиках сам делай. А нормальные люди на Atmel, Altera и Xilinx собирают (в зависимости от задач). [Ответ]

аааа... кидайте в меня камнями, шрязными носками, гнилыми помидорами! Я пишу на С! [Ответ]

-=Женек=-, ну всё.... ты попал. [Ответ]

Сообщение от Leo:
Эт не мне - эт peace_manу нада.

Шурик2, пиши уж на форум. Мож чем и помогу. Кстати да, тоже пишу на ассемблере, с различными Сями не приставать.

Есть прошивка для AT90S2313 с кварцем на 4 мега надо ее подкоректировать для Attiny2313 (выставить фьюзы) чтобы включить внутреннтй генератор на 4 мега. [Ответ]

Сообщение от :
peace_man, поверь, никто тебя писать учить не будет.

Я это сразу понял. Ну что ж пропробуем..

Сообщение от :
ЗЫ: Какой тип контроллеров выбрал?

Пока никакой. Просто такая фигня. Могут устроить по знакомству в одну видную организацию. Там как я понял все нормально с разработкой и ее оплатой. Но там трансляторы под С++ заточины. Я в школе паскаль изучал(Делфи сам освоил). Вот сейчас трахую мозги с С++.... В институте в курсовая у меня была - на МК51 написал прошивку...

Сообщение от :
буду краток - триста баксов

Пасиб конечно, за 300 зеленый я и сам выучусь! Благо время пока есть...

Сообщение от :
Тут обсуждать то нечего PIC + ассемблер спасет мир

Ну как тебе сказать.... Для телекоммуникационных систем... Pic... незнаю.... У нас лабы были по ассембелеру (на К580 - страшная вешь!). Вводили в ручную машинные коды, благо в 16-ричной системе. Отладка - п...ц! Все таки С я думаю по современней...
В общем, мне на этом форуме начинает нравиться... [Ответ]

Тут учиться на словах не получится. Ассемблер + паяльник и в бой!
P.S. Пишу для TMS. [Ответ]

peace_man,

Учить может и не будут, а показать дорогу не сложно.

На Торенте в разделе “Программирование” можно взять программу отладчика для микроконтроллеров семейства AVR. (интегрированная среда разработки для процессоров фирмы ATMEL) http://www.torrents.vsi.ru/viewtopic.php?t=20874 .
Внутри среды находятся описания процессоров, команды ассемблера, язык С.
Пробовать силы можно сразу после скачивания.
Для зашивки программ нужны программаторы (самодельные или приобретенные) У меня в эксплуатации STK 500 – вещь очень удобная, поддерживает почти все процессоры и все способы программирования, правда может программировать только DIP корпуса, для других корпусов нужны переходники, это не проблема – можно изготовить или купить такие переходники (мезонинные платы). В основном использую STK500 в режиме последовательного программирования и программирую процессоры, установленные уже на целевую плату.
Цена такого программатора около 100 $. На форумах читал, что некоторые получают его по зарубежным каталогам за 80 $ и менее.
Что бы совсем жилось хорошо, нужна русскоязычная литература, например, “Микроконтроллеры AVR семейств Tiny и Mega фирмы ATMEL” А. В. Евстифеев.
В фирме ЭФО покупал отладчик - книга давалась бесплатно. www.efo.ru

Это те самые “удочки” для самостоятельного промысла рыбы. УДАЧИ!

По поводу языка программирования ассемблер или С? Это не взаимоисключающие, а дополняющие языки. В С встроены подпрограммы значительно облегчающие программирование некоторых приложений, но отладка проводится на ассемблере. [Ответ]

Сообщение от peace_man:

Сообщение от dr.ON:
Тут обсуждать то нечего PIC + ассемблер спасет мир

Ну как тебе сказать.... Для телекоммуникационных систем... Pic... незнаю.... У нас лабы были по ассембелеру (на К580 - страшная вешь!). Вводили в ручную машинные коды, благо в 16-ричной системе. Отладка - п...ц! Все таки С я думаю по современней...

Эй Эй Эй!
Насчет пиков это я пошутил, дабы развязать "религиозную войну PIC vs AVR", но чтото неразвязалась.

Теперь насчет языков программирования.
По моему мнению( человек который и на ассемблере и на С писал) лучше изучить С.
Доводы простые:
1) платформонезависимый язык( почти)
2) разовьется абстрактное логическое мышление, не привязанное к конкретному ядру, такчто переход на новое ядро будет безболезненный.( В наше время важно, т.к. AVR и т.д. лет через пять уже никому не будет нужен, ARM и т.д. уже давно продвигается) (вот это я загнул ) [Ответ]

Сообщение от dr.ON:
дабы развязать "религиозную войну PIC vs AVR"

PIC-фанатов не осталось. Не с кем биться :-)

Краткий курс:
http://avr123.nm.ru/01.htm

Если что по проще - рекомендую писать на сях под CodeVisionAVR

и главное:
Изображения
  [Ответ]

Не люблю я высокий уровень... Главная ошибка программиста на С+- - то, что он выбрал С+- в качестве языка программирования. [Ответ]

Сообщение от XPEH_BAM:
Не люблю я высокий уровень...

А куда щас без него?!

А насчет ассемблера, тут дело такое.

Через несколько лет будет так:
1) бывалый( крутой спец по асму) на бздючном AVR"е пыжится три месяца
2) прыщавый студент на каком нибудь визуальном "алгоритм билдере" за выходные делает тоже самое, но под более мощьный проц

Внимание! Теперь вопрос: КОГО ПРЕДПОЧТЕТ РАБОТОДАТЕЛЬ?!
Темболее если учесть, что уже сейчас цена AVR mega64 = ARM аналог( чтото типа МК AT 91SAM7S64: 64 кБ Flash, 16 кБ SRAM, 4-канальный 16-битный ШИМ, FULL speed USB;....) [Ответ]

что на сях что на асме под камни писать по времени примерно столькоже, только на сях замахаешся глюки вылавливать!
реальный пример: у меня глючила совместная работа двух камней (я начинал все это на Си писать) и все из-за того что я так и не смог определить в каких случаях какой кусок программы за сколько тактов выполняется, плюнул на недоСи и ушел на ассм. на ассме я вижу что одна комманда=1такт. просто пальцем отсчитал нужное количество и поставил переход в подпрограмму связи в нужном месте. (писал задающий генератор для теслы, два камня, один контролирует интерфейс с юзером, второй занимается синтезом сигнала)

ps: прыщавый студент, может в кодинге посоревнуемся? только на нетривиальных задачах. чтоб многопроцессорность была, связь между кристаллами в реальном времени, при этом чтобы камни на разных частотах работали. один кристалл чтоб занимался дисплеем и клавной, второй ну скажем чегонить считал основываясь на данных с клавы первого и туда же выводя результаты, а третий камень держал связь с компов по компорту и выводил туда состояние всех переменных второго камня во время его работы, ну и частоты камней 2,6 и 7,5мгц скажем. задача тупая абсолютно, но совершенно нетривиальная. и на низком уровне сделать это без глюков будет на порядок быстрее.

не спорю что всякие визуальные редакторы для примитивных задачь будут проще, но чтото действительно серьезное писать удобнее на низком уровне. [Ответ]

Сообщение от Дерусов Николай:
не спорю что всякие визуальные редакторы для примитивных задачь будут проще, но чтото действительно серьезное писать удобнее на низком уровне.

Может и удобнее( хотя врядли), а вот в скорости разработки полный пролет!

P.S. чето крутая задачка.
один контроллер клаву с дисплеем обслуживает, другой связь с компом держит( и втоже время с другими, нафиг он нужен?). Эти все задачи делаются в фоновом режиме у основного процессора.
А такты щитать несовременно, т.к. производительность камней растет не по дням, а по часам. В результате чего прошивку постоянно придется переделывать по новые камни.
Да еще, в скоростных камнях производительность нелинейная, так что так временные синхронизации неделаются. Если действительно чтото критическое по времени, используй прерывания от таймеров. [Ответ]

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

здрассьте ) приплыли ) ARM-камни имеют 1комманда=1такт. зависимость тут идеально линейная. я говорю только о AMR камнях.
синхронизация по времени? предлагаешь с таймера сигнал завести и прерывания юзать? нет уж, спасибо. во первых это сложнее, а во вторых есть программы, которые нельзя прерывать!

Сообщение от :
Эти все задачи делаются в фоновом режиме у основного процессора.

какой блин фоновый режим? в чем? или ты хочешь сказать что в камне аппаратно поддерживается какойнить хитровымудренный дисплей который я поставлю в схему?

поясню почему надо распараллеливать было: один камень у меня занимается интерфейсными делами, а другой сигнал синтезирует, причем он следит за синхронизацией с цепи обратной связи, корректирует длительность ипульса и непосредственно делает сигнал на четырех независимых выходах. использование прерывания (как ты предлагаешь) означает останов синтезации частоты, что приведет к взрыву силовой части стоимостью под 300$!!

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

как видишь не все можно решить просто и легко. есть задачи которые требуют выдумывания новых алгоритмов и банального подсчета тактов глазами. [Ответ]

Сообщение от dr.ON:
КОГО ПРЕДПОЧТЕТ РАБОТОДАТЕЛЬ?!

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

Сообщение от dr.ON:
Может и удобнее( хотя врядли), а вот в скорости разработки полный пролет!

Могу поспорить, что любая задача, мало-мальски отличная от простого мигания светодиодами на портах, на асме будет разрабатываться как минимум столько же времени, что и на каком-нибудь сраном "визуале", а реально будет сделана даже быстрее, потому что фактически при кодинге на асме риск возникновения необъяснимых глюков стремится к нулю.

Сообщение от dr.ON:
P.S. чето крутая задачка.

На самом деле задачка (относительно реальных) даже сильно упрощённая. Делал фактически то же самое, только ещё и с преобразованием интерфейсов.

Сообщение от dr.ON:
Эти все задачи делаются в фоновом режиме у основного процессора.

А ты этта... вообще хоть понимаешь, о чём разговор-то идёт??? Хватит свои "знания" показывать, а то со смеху умру нафиг...
Короче, давай так, даю тебе задачку, с которой физически по вычислительной мощи может справиться один кристалл, но физически на одном кристалле невыполнимую (не из-за того, что портов не хватит ). Если уместишь всё в одном камне, тебе приз... ну, скажем, баксов 200.

Сообщение от dr.ON:
А такты щитать несовременно

Мдя... уже писать нормально не могу живот болит...

Сообщение от dr.ON:
Да еще, в скоростных камнях производительность нелинейная, так что так временные синхронизации неделаются

Аффтар, жги исчо!!!! Ты такие камни-то в живую видел, где "производительность нелинейная" (какой оборот красивый ).

Сообщение от dr.ON:
Если действительно чтото критическое по времени, используй прерывания от таймеров.

Да ну? А если прерывания запрещены? Ну не может основная программа отвлекаться на прерывания... что тогда? [Ответ]

Дерусов Николай, блин... на полминуты опередил. [Ответ]

Сообщение от :
Да ну? А если прерывания запрещены? Ну не может основная программа отвлекаться на прерывания... что тогда?

а вот тогда Си программер сядет в долгие раздумья и вылавливания нестыковок в шинах сигналов в один/два такта и прочие глюки несинхронности, а "несовременный" ассмовец просто пальцем на экране посчитает такты и сделает корректировку банальными NOPами

Сообщение от :
Могу поспорить, что любая задача, мало-мальски отличная от простого мигания светодиодами на портах, на асме будет разрабатываться как минимум столько же времени, что и на каком-нибудь сраном "визуале", а реально будет сделана даже быстрее, потому что фактически при кодинге на асме риск возникновения необъяснимых глюков стремится к нулю.

согласен полностью. лично по аське челу помогал вылавливать глюк Си, из-за которого он мучался неделю:
писалась прога, которая по мимо всего прочего делала PORTB=0x10. причем выполняла она это за три такта как позже выяснилось по средством просматривания дизассембированного результата работы этого сраного Си.
а скомпиливалась перед прошивкой прога эта на другом компиляторе, что там с ним было не так я незнаю, но выполнял он те же PORTB=0x10 за два такта!
к чему это привело? к тому что не работал LCD экран, которому как раз одного такта задержки и нехватало после инициализации и перед подачей на его порт 0x10.
бились в кровь, пока плюнув на все я не почитал дизассемблерку результатов работы компилера и вручную не посчитал задержки.
(этот глюк был в драйвере инициализации и управления двухстрочным ЛСД экранчиком) [Ответ]

Сообщение от peace_man:
Если ктонибуть этим занимался поделитесть опытом, ну или ощущенями
Собираюсь скоро этим занятся, а пока учусь..

Человек помощи попросил, а вы пиписками меряться начали... [Ответ]

Сообщение от :
Если действительно чтото критическое по времени, используй прерывания от таймеров.

уважаемый, вы вообще програмили? что-нить кроме светодиодов?

вот представь ситуевину:
камень получил прерывание от кнопки и обрабатывает его, а во время обработки (до того как он вернется из прерывания и флаг прерывания будет сброшен) приходит то самое "критически важное". что будет? а то что камень его проигнорирует нахрен. у amr'ках нету иерархии прерываний и пока не закончилось одно - новое не начнется.
или например камень занят вот этим: засылает в порт 1, ожидает 20 тактов и шлет в порт 0. ну надо. формирует он этим сигнал для какого-нить важного аппарата. и во время отсчета 20тактов придет прерывания от интерфейса. что будет? правильно! задержка составит на 20 тактов а хрензнаетсколько. и в результате на важном аппарате может быть все что угодно, вплоть до атомной войны.

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

Сообщение от :
Человек помощи попросил, а вы пиписками меряться начали...

опытом поделиться неполучится, это не пирог. а ощущениями - мы ими и делимся [Ответ]

SVN, ну так человек до сих пор так и не сказал, в чём конкретно ему надо помочь...

Это всё равно, что сказать: "я хочу устроиться в авиакомпанию пилотом, но не умею водить самолёт. Расскажите, как это правильно делается."
Аналогия чувствуется? [Ответ]