Хочу изучить 12 семейство. Причина выбора - очень простые применения 6 портов вполне хватит и есть возможность дёшево покупать именно этот тип контроллеров.
Опыт программирования на асме для 51 и тексасовских DSP имеется. Посмотрел систему команд и описание железа- вроде ничего сложного.

Си не знаю и изучать в ближайшее время не собираюсь.

Какой софт надо поставить? (есть mplab v6.20)
Какой программатор купить? (есть chip prog)
И если можно отвлечённо проект для этого контроллера для освоения софта и привыкания к мнемонике ассемблера.

ставьте новый - 8.33

без разницы. Удобней конечно ICSP, можно почти даром купить PICKit2

зачем ассемблер? ставьте Си (HT PICC). В комплекте с MPLAB есть бесплатная версия, для 675 ее вполне хватит. А ассемблер там такой же как у всего семейства Midrange (некоторые PIC12, большинство PIC16). Примеры и application notes можно найти на сайте микрочипа

Насчёт софта понял.
Насчёт программатора поищу. Просто можно ли для начала диповские корпуса шить в фитоновском чип проге???

Насчёт Си - скажем так - нас ассемблере я уже могу писать, положив на стол распечатку мнемоники, а Си надо изучать, чего я делать не буду, в том числе и из-за отсутствия времени. Тем более не уверен, что с килобайтом и 4мя мегагерцами это вообще получится.

Можно. Если надумаете шить фитоном внутрисхемно, придется или сделать/купить адаптер (просто буферы на двух 74126), или не нагружать ICSPDAT, ICSPCLK (GP0, GP1 для 675) менее, чем 10 к.

а ссылку на схему можно???

Тогда я бы посоветовал глянуть на cvasm16 (бывший spasm, когда-то его распространял и поддерживал Parallax, ныне обитает на www.tech-tools.com). Мнемоники подобны i51, писать действительно удобно (к "родному" микрочиповскому стилю я так и не смог привыкнуть, когда надо, пишу именно на cvasm). А для программирования я бы посоветовал обзавестись PICKIT2.

а симуляция???

Рискну показаться неоригинальным , но всё же. Из собственного опыта: я некоторое время назад рассуждал примерно так же. Мне справедливо заметили, что время, потраченное на изучение С, окупится затем временем на написание программ. В чём и убедился. Но дело хозяйское, как говорится...
И не сомневайтесь, с килобайтом и 4 мегагерцами получится вполне.

Таких полно в сети. Большинство, правда, для древнего pic1f84, но легко переносятся и на другие в силу своей простоты.
http://users.tpg.com.au/users/talking/

А нафига ? ;)
Впрочем, надо бы посмотреть, что там сейчас в пакете есть, никогда не интересовался... У Parallax был симулятор, но это было очень давно, худо-бедно эмулировал c84 (и то с растактовкой была плюха). В конце концов, можно, наверное, и в объектном коде прогнать, если уж приспичит. Я предпочитаю "вживую", с отладочным выводом на терминал либо на скоп...

сомневаюсь так как имел опыт на 51, когда программа написанная другим человеком на С, когда он внося изменения решил не разбираться в моей, а переписать её, мало того, что не влезла , так ещё и не успевала, Когда взяли с памятью побольше - успевать начала только после того, как он начал вставки асмовские делать. Это конечно вопрос достижения грани, но и контроллер берётся заведомо самый медленный и маленький и переход на другой врят-ли будет. Мои два захода попыток изучения си показали, что для меня это не постижимо, особенно учитывая что 5 последних лет я занимаюсь только ПЛИС. Кроме того что там есть звёздочки с нелогичным синтаксисом при косвенной адресации и что функция xilprint занимает места немеряно и нельзя делать все переменные глобальными в голове больше ничего не осталось.

В MPLAB прекрасный симулятор встроенный,
можно PRoreus 7.5(7.4) - тоже поддерживает симуляцию весьма удобно

http://phyton.ru/images/upload/file/downlo....html#AE-ISP-U1

С Си очень даже хорошо получится, а если взять PIC12F683 , то вообще замечательно.
Для Ваших простых нужд сложность у Си не больше, чем у асм.

Цитата(rv3dll(lex) @ Jun 25 2009, 09:32):
"Хочу изучить 12 семейство..."

Поддерживаю Ваше стремление. Сам многие проекты делаю на PIC12 (PIC12F675/PIC12F683). Там, где достаточно 6 ног - этому камню мало конкурентов по соотношению цена/качества/возможности. Когда ног не хватает - рекомендую присмотреться к серии PIC16F6xx (PIC16F676, PIC16F688) - практически тот же PIC12, только еще 6 дополнительных ног...

P.S. Вот уж где Си точно не нужен, так это на PIC12. Что называется: "Не пришей к ..."

Как категорично! Вам не нужен, так и скажите. Здесь, например.
Можно пойти дальше и асмом не пользоваться...
Такого рода заявления похожи на очередную провокацию битвы "С vs ASM" Не надо скандалов, употребите вместо слова "точно" лучше слово "ИМХО"...

Надеюсь "битвы" не будет . Хотя некоторые поклонники С пытаются на нем даже PIC10 программировать...
Но, Imho, эти попытки "пальбы из пушки по воробьям" всегда заканчиваются одним - "возьмем камень по больше...". По этому, так категорично ...

Я тоже делаю свои проекты на этих же 12-16 пиках. С год как вынужден был перейти на Си и получаю удовольствие от написания программ.
Пока мигаешь светодиодами, то асм, а как-то понадобилось усреднить 1024 значения с различным анализом данных(12 пик и не такое может) вот тут-то Си и спас.
Советую посмотреть http://vrtp.ru/index.php?act=ST&f=106&t=10583
Очень хорошо по шагам расписано создание проекта на Си.


Посмотрите про PIC10 http://wiki.pic24.ru/doku.php/osa/ref/appendix/3leds_pic10f
Как видите даже ОСРВ не чуждо PIC10.

Тоже не смолчу.
На сегодня единственно правильный путь - изучить "С", причем Hi-TECH - не лучший вариант (типа лучший из худших), а затем - если что-то не пролазит по быстродействию или требуемому размеру памяти - допиливать с использованием параллельно изучаемого ассемблера.
Но есть и другие варианты, например http://www.pmpcomp.fr/
Из плюсов - красиво интегрируется с MPLAB, реально работает и написан от души.
Из минусов - то что это Паскаль.

Ну вот, началось! Заметьте, уважаемые поклонники Си, чем вы обосновываете свой выбор - "не могу это написать на Asm", "получаю удовольствие от написание программ на С", "красиво интегрируется в MPLAB"...
Сейчас уже и "камень" в устройство стали выбирать по принципу - "удобно писать на C"...
Парочку таких проектов пришлось перерабатывать недавно - с целью снижения себестоимости устройства и расширения его функций. В результате, то что было написано на С и с трудом помещалось в PIC18, после переработки нормально уложилось в PIC12 и еще ряд функций удалось добавить.
Я ни кого не агитирую, даже наоборот. Если не умеете делать сложные задачи на Asm - дальше моргания светодиодов и усреднения чисел у Вас дело не идет, то переходите на С. Так проще и правильнее.
И мне меньше конкурентов.

кинь любой проект с конфигурацией железа. Для развития.

помимо родного, я еще пользую "PIC Simulator IDE"
(http://www.oshonsoft.com/downloads.html
и посмотрите соответствующую ветку на "Казус")
мне очень помогает разбираться с дизассемблированными хексами
и отлаживать свои алгоритмы ...

тоже, в основном, использую ассемблер, еще со времен
"больших" машин ...

Не верю, как говорил Станиславский. С, как и АСМ, всего лишь инструмент. И инструмент мощный. Одним удобством его выбор не определяется. А то, о чём Вы говорите, возможно лишь если предыдущий "писатель" абсолютно не умел им пользоваться. Да и то, скорее на вредительство похоже. Лионских ткачей... Слухи о раздутом и неэффективном коде, генерируемом компиляторами, сильно раздуты, уверяю Вас. Впрочем, тоже никого не агитирую...

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

Цитата(Herz): "Не верю..."

Чему тут не верить? Просто разработчик взял "камень побольше", и ни в чем себе не отказывал...
А то, что изделие серийное, и нужна минимальная себестоимость - для него был не агрумент...
Обычный подход таких разработчиков - можно сделать все на гораздо более дешевом процессоре, да возиться не охота. Возьмем "камень побольше", и cделаем все быстро и красиво на Си. А то, что изделие потом не продается - это уже не их дело...

Я то знаю, о чем пишу, а Вы, видать, не очень. Сформулирую по другому:
1. Какой смысл писАть программы без хотя бы минимальной возможности их повторного применения, причем не обязательно в той же линейке камней?
2. Какой смысл изголяться с математикой/арифметикой, если в "С" уже все оптимально работает?
3. Какой смысл в написании лишнего текста, если компилятор в рамках проекта не "уронит" ни размер, ни быстроту? Другое дело - отдельный кусок кода - который можно ручками довести до совершенства


- это особенно умиляет

Если нравится писать на асме, лучший выбор - это форт.

а никогда не приходилось без таймера при тактовой частоте 4 мегагерца сделать выход 1 мегагерц? на ассемблере просто каждая вторая команда инверсия порта. На Си ?

Не поверите, то же самое!

особенно если каждая первая это сложение хотя-бы 16 битных чисел, которое при компилляции заменится не одной ассемблерной командой)))

То есть, каждую команду в проекте перемежаете командой инверсии?
А ведь есть команды 2,3, и даже 5-6 тактовые в зависимости от архитектуры (у пика по-моему, ещё печальнее).
И что тогда?
А если 1 Мгц потребуется поменять на 0,5 ?
Страшно подумать...

Факт?
Знаете, неумелые действия пилота самолёта приведут, конечно, к более драматичным последствиям, чем велосипедиста. Тогда, ориентируясь на неумелых, будем лучше потихоньку...
Почему-то в такого рода сравнениях всегда приводятся истории с типичным сюжетом: криворукий и безответственный С-программист и ас-спасатель со сверкающим мечом АСМ-а в руках, отсекающий всё ненужное...

не забывай что опыта программирования на Си нет и преобратётся он не через 2 часа, а это равносильно сравнению пацана который уже может сделать мёртвую петлю на велосипеде, первый раз посаженного за руль автомобиля.



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

Цитата(Herz): "... криворукий и безответственный С-программист и ас-спасатель со сверкающим мечом АСМ-а в руках, отсекающий всё ненужное..."

Ну, положим, про безотвественных программистов я лично не писал.

Цитата(Pasha): "Я то знаю, о чем пишу, а Вы, видать, не очень. Сформулирую по другому:
1. Какой смысл писАть программы без хотя бы минимальной возможности их повторного применения, причем не обязательно в той же линейке камней?
2. Какой смысл изголяться с математикой/арифметикой, если в "С" уже все оптимально работает?
3. Какой смысл в написании лишнего текста, если компилятор в рамках проекта не "уронит" ни размер, ни быстроту? Другое дело - отдельный кусок кода - который можно ручками довести до совершенства"

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

А это как называется:

Ладно, спорить тут не о чем... Люди взрослые.

Цитата(Herz): "Ладно, спорить тут не о чем... Люди взрослые."

Конечно, не о чем. В споре "C vs ASM" истина не рождается. Кто прав - решает покупатель. А ему, как правило, глубоко "по барабану" на чем написано ПО. Он смотрит на конечную цену изделия.

О! Мир и Респект Вам!
По поводу перемежения кода - проблема такая есть: не всегда удается избежать ненужных ветвлений, ветви не балансируются итд. Тогда Си точно не поможет, вернее даже будет где-то так

Как правило, да. Но ведь и написание ПО денег стоит. В конечную цену входят и эти расходы. Хотя для "мелочи" программирование на АСМе действительно выйдет экономичнее. Учитывая, что за компиляторы, вообще-то, тоже платить надо.


ИМХО (да и не только), к этому скрещиванию стоит прибегать только в крайних случаях.

Я непонятно выразился.
Когда-то в 98-99 году делал на at90s1200 несложную штучку, в которой был подмешан программный ШИМ на 400кГц в половине программы с одной скважностью, в половине - с другой. Но алгоритм легко сбалансировался, поэтому сложностей не возникло. Си, разумеется, тогда серьезно не воспринимался

Что-то все про PIC&C. А ведь есть люди, для которых выбор типа микроконтроллера не первостепенно - какой лучше подходит тот и применяют.
Я имею ввиду не только пики и авр, а многие прочие. Вот здесь то без Си никак.

"Что-то все про PIC&C..."
А Вы название темы вспомните - PIC12F675.
Абстрактный вопрос - на каком языке лучше писать- практического cмысла не имеет...
Для серийных изделий, главное - стоимость комплектующих. Стоимость разработки ПО уже не критична. Чем больше серия, тем это более справедливо. Поэтому, если есть возможность применить более дешевый МК - нужно именно так и делать. Если из-за этого придется писАть не на Си, а на Аsm и вручную заниматься оптимизацией - именно так и надо делать. И потратить на это не 2 дня, а 2 недели, а может и 2 месяца. И пусть программа получится "одноразовая", непереносимая на другие МК и не подлежащая модернизации. Если в этом есть экономический смысл (прямая выгода) - именно так и надо делать.
Будет другая задача, другие условия и другие цели - будет и другой ответ на вопрос на каком языке и как писать. В каждом случае - свой. Всякие абстрактные рассуждения о преимуществах того или иного языка, не привязанные к условиям конкретной задачи - пустая трата времени.

например если хочешь снижать частоту / потребление до тех пор, пока устройство ещё работает!



Для меня естественно FPGA или CPLD а процессоры противоестественно (((



Задача стоит именно так, или почти так - а именно есть контроллер есть задачи - на каком языке в этот контроллер специалист с 10 летним стажем программирования на ассме и с 0 стажем программирования на си уместит больше логики??? на каком языке он более коррекно состыкует его с плис и всё это при условии, что другого контроллера не будет. Если Си программисты думают, что под ассемблер нет готовых блоков кода математики , то они глубоко ошиьаются

На мой взгляд - на pic12 pic16 лучше всё делать на асме , в pic18 - и так и сяк, но мне удобней на асме, в pic24 dspic33 - сильно сависит от задачи - если например usb или интернет - то однозначно С . Микрочиповский С позволяет хорошо делать функции на асме - встраеваемый асм не читабельный.
pic32 - пока асемблер не освоил, пробывал только на С.

По ассемблеру посмотрите здесь http://ikarab.narod.ru/index.html
По проектам лучше всего на сайте Микрочипа: там много апнотов почти на любые устройства с подробными описаниями и почти все на асме.

А на мой взгляд - лучше всё делать на С. И что, всё сначала? Надеялся, разобрались уже: действительно сильно зависит от задачи (и справедливо для любого МК). А ещё, как выясняется, сильно зависит от предпочтений программиста. Вот удобней ему - и всё тут, другой логики может и не быть...

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

Примерно полторагода назад начал программировать котроллелеры, сначала был PIC16F876A и асм. Вроде пока проекты были маленькие и можно было все держать в голове все было ок, но как только появились два уарта, память и часы внешние отладка стала напоминать китайскую пытку. Промаявшись несколько недель, решил написать на С. Сначала проработал Шпака, потом начал ваять маленькие примерчики из хелпа к компилятору. За полторы недели написал модбас устройство под себя и уарт програмный ( правда при помощи страших товарищей). Могу сказать ИМХО дял больших проектов токлько С, для маленьких годится и асм. Тут каждый выбирает для себя сам.
Также мне кажется надо выбирать инструменты для реализации проекта не только из критерия привычности, но и из соотношения скорости/цены.
Плюс знания АСМ ксати в том что он дает знание архитектуры контрллелара, для написания более компактного кода на С.

как это понять - чета ничего не понимаю

А что конкретно не понятно? По моему, все очевидно.

P.S. Какой PIC?

тот который в теме. Не понятко как мнемоника меняется компиллятором в смысле один регистр на другой и два банка переключаются как то не переключаемо???

хотя

#define Bank0 0x00
#define Bank1 0x80

Вообще-то вопрос ASM vs C - это вопрос в значительной мере религиозный если не конкретизирована задача. И периодически возникающий холивар на эту тему - тому доказательство. По-поводу простоты освоения embedded С. Посмотрите, сколько на форуме вопросов именно по специфическому на конкретном МК применению С (распределение переменных в нужной памяти, сложные обработчики превываний итп)
Вы сильно демонизируете сложность написания прог на ASM. Если мозги заточены под ASM, то скорость написания и отладки программ сопоставима (примеры с мегабайтами откомпилированного кода и мегабайтами многомерных массивов типа double не рассматриваем - это не для pic12). Основная же проблема ASM'a - это проблема с передачей проекта другому программисту. В данном топике это не проблема, равно как быстрый перенос кода на "все, что шевелится".Лучшим явлется тот инструмент, котрым хорошо владеешь. Мастер обыграет новичка в теннис даже взяв вместо ракетки сковородку.