pic12f675, c чего начать. Опции

[rv3dll(lex)]

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

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

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

[Herz]

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

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

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

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

[rv3dll(lex)]

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

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

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

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

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

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

Причина редактирования: Излишнее цитирование.

[jam]

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

[Herz]

На мой взгляд - на pic12 pic16 лучше всё делать на асме , в pic18 - и так и сяк, но мне удобней на асме, в pic24 dspic33 - сильно сависит от задачи

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

[vvs157]

А на мой взгляд - лучше всё делать на С. И что, всё сначала?

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

[Herz]

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

Ещё раз. Я не собираюсь рубится на этой религиозной войне. Религиозные войны - самые бессмысленные, но и самые длительные и кровопролитные.
Понятно, что если мастера устраивает его инструмент, агитировать его "за советскую власть" ни к чему. Однако пару моментов, на которые пытаюсь обратить внимание очередной раз. Так же некорректно сравнивать мастера с новичком (что любят делать почему-то именно сторонники ASM-а), как и ракетку со сковородой. И второе: не знаю, что такое "мозги заточенные под ASM", ведь ASM, в отличие от С, на каждой платформе разный. И проблемы возникают не столько при передаче проекта другому программисту (с другой заточкой мозгов ?) , сколько при переносе программы на другое железо, буде таковое потребуется.