Свежие обсуждения
Микроконтроллеры

Ликбез по программированию PIC

1 66 99

picmaniac:
Хорошо, что одно другому особо не мешает.

Позвольте не согласиться. Параллельно осваивать эти две вещи (основы кодирования и графы) - это очень трудно. Вы, умея кодировать, мыслите при освоении графа уже некими абстракциями, крупными строительными блоками, вроде "увеличить счётчик, сравнить с порогом", или "вычислить 16-разрядную разность". Человек же не освоивший кодирование - мыслит блоками поменьше, ассемблерными командами. Причём ему ещё приходится вспоминать/подбирать подходящий кирпичик... Добавьте к этому робость "начинающего водителя"...
Поэтому мне кажется, что сначала надо банально "набить руку", а потом уже переходить к графам.
А можно и не переходить вовсе Например, я, за все свои чуть ли не 20-лет программирования - ни разу не использовал графов, что не помешало мне писать навороченные машины состояний Я не хочу сказать, что графы не нужны, я хочу сказать, что они не обязательны.

 

Да конечно, мне, как начинающему, гораздо интереснее пока освоить именно кодирование. Чтобы это не вызывало проблем и впоследствии научиться мыслить более глобальными категориями. Вот мы здесь зациклились на обсуждении различных алгоритмов для решения конкретной задачи. Конечно это хорошо и правильно, без этого не обойтись, но учебный процесс по-моему несколько буксует на месте. Я бы давно начал писать программу, если бы представлял до конца весь алгоритм. Писать отдельные куски, которые потом никуда не встроишь тоже неинтересно. Хочется уж сразу сесть и написать по полной, по заранее согласованному алгоритму. И перейти к другой задачке, а то эта, честно говоря, навевает уже какое-то уныние. Я уже "остывать" начал. Брать и решать самостоятельно какую-то другую задачку, пока picmaniac не определится с алгоритмом, вроде тоже не здорово.

Все-таки эта задачка под учебную не очень косит. Я так думаю, что учебная, эта та, ответ на которую преподавателю известен заранее. А тут, вариантов масса, обсуждений куча, а вот тренинга в написании кода нет совсем. Тем более я-то неполноценный участник обсуждения, поскольку мало чего знаю и не имею опыта. Я больше к "старшим" прислушиваюсь. А пишу, так, для поддержания разговора, дровишек в костер подкидываю, чтобы не погас.
Я предлагал в начале, когда еще обсуждали задание, что-то попроще взять, ну чтобы сразу процесс пошел. Но Splav56 настоял, что только именно в таком виде она интересна, а сам между тем превратился в "читателя" и даже щепочек не подбрасывает.
А вот интересно, много ли еще в этой теме "читателей"? Пусть хоть голос подадут, или скажут чего.

 

Zandy: Но Splav56 настоял, ...

Ну вот и "стрелочник" определен.

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

 

Читаю ветку с переменным интересом. Пока читал, сделал девайс на 675 пике, программу писал на бейсике, всё работает. Всё с нуля, я и РВР скачал по здешней рекомендации. Разумеется, код не оптимален, но моей целью и не была оптимизация кода - "вам шашечки или ехать", я выбрал "ехать". Ну а в свободное время буду и оптимизировать и ускорять, если заставлю себя, конечно, - потому, что на очереди уже ещё пяток задумок, изящно воплощающихся на пиках.

 

AHTOXA: Позвольте не согласиться Да я немного не то имел в виду. Смысл в том, что в этой ветке один человек может осваивать кодирование, а другой, параллельно, графы. И они не будут друг другу мешать, даже наоборот, это будет полезно всем.

Zandy: Splav56 даже щепочек не подбрасывает Угу, это верно.

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

 

О себе - страницы сохраняются, и при тесном контакте с МК это востребуется, как справочный материал...

Продолжайте дерзать!

 

Наверно, лучше будет создать тему "Изготовление микроконтроллерных устройств", где будем разбираться с изготовлением конкретного девайса, не углубляясь в дебри теорий. От задумки до воплощения в железе с работающей прошивкой. Только первый девайс должен быть несложным, чтоб быстро пройти все этапы, и в дальнейшем использовать пройденный путь как шаблон. И ещё - девайс должен быть практически полезным в быту. Например, программируемый таймер. Так будет значительно интереснее.
И ещё. По каждому девайсу должен быть избран куратор. Слово которого будет решающим. Как в очерёдности этапов изготовления, так и в построении алгоритма и кода.
А писанину-то зачем удалять? Пусть остаётся... DWD Удалил всё-таки. Ну и ладно.

 

picmaniac: Предлагаю вплотную сосредоточиться на первой подзадаче - "отлавливание" изменений уровня на входах и расчёт периодов.
Так какой все-таки алгоритм выберем окончательно? Прерывания по сигналу, тайм-аут по отдельному таймеру? Или еще как-нибудь?
Я не совсем понимаю, почему тут могут быть пропуски? Если мы сначала сбросим флаг прерывания, а затем считаем порт, что тут криминального? Все равно ведь окончательное решение будем принимать по изменению состояния порта после входа в прерывние, а не по факту самого прерывания. Даже, если приход фронта сигнала (поднятие флага прерывания) придется на момент считывания порта, то мы "застукаем" его или в текущем, или в следующем прерывании.
Хочу все-таки немного забежать вперед. Меня неотвязно мучает вопрос по поводу мигалок. Ну хоть намекните в общих чертах, как мы их будем организовывать, а то скоро во сне сниться будут? Лично мне ничего, кроме организации таймеров задержки, в основной программе на ум не приходит. Или будем задействовать третий таймер с прерываниями по нему (о ужас! ) для организации мигалок в прерываниях? Хотя, можно и прерывания по первому (счетному) таймеру устроить для мигалок.

 

DWD: Наверно, всё таки, лучше взять конкретно нужное устройство и его "ваять"

А это и есть КОНКРЕТНОЕ четырехканальное устройство контроля частоты вращения асинхронного двигателя с номинальной частотой вращения 1500 об/мин, если на него установить автомобильный индуктивный датчик (датчик положения коленвала). Чем не прикладная задача? Очень многих интересуют вопросы защиты асинхронных двигателей при перегрузках, не применяя при этом таких средств, как частотные преобразователи, имеющие встроенную подобную защиту. Устройство должно несложно перестраиваться под двигатель с другим числом оборотов, путем замены константы, например.

 

DWD: Меня, снова, "напрягают" игрушками...
Конструкция реальная, и будучи "слабаком" в МК я планирую собирать её на обычной логике...

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