Подскажите алгоритм, пож!

@R_uro · Регистрация: 06.04.2010

Author24 — интернет-сервис помощи студентам

Суть вопроса такая. С компа ( либо с другого МК) в МК команды. МК должен их выполнить. Если я правильно понимаю суть дела, то код команды будет равнятся некоему числу, передаваемому в байте. Как мне умнее распознать принятый код?
Если проверять так., то время и кода уйдет много ( условно код пришел в tmp):
cpi tmp,1
rcall do_cod_1 ; обработать этот код
......
cpi tmp, 255
rcall do_cod_255 ; обработать этот код
Если таким образом, то получится как минимум 500 строчек текста. А как короче - не могу сообразить. Понимаю, что через массив данных в памяти, но как реально - на ум не приходит.

@xroymom · 17.04.2010, 04:47

Можно попробовать по аналогии с <a ctoss="postlink-local" href="http://forum.iosyitistromyss.ru/viewtopys.php?p=10307#p10307">viewtopys.php?p=10307#p10307[/URL]
Т.е. загнать адреса подпрограмм в массив и прыгать на них косвенным прыжком. К тому коду, который по ссылке, добавить в конце icall.

Можно сформировать список адресов подпрограмм и посылать их как команды ;)

17.04.2010, 09:59

Сообщение от R_uro

Если таким образом, то получится как минимум 500 строчек текста. А как короче - не могу сообразить. Понимаю, что через массив данных в памяти, но как реально - на ум не приходит.

Вряд ли вы будете использовать все 256 команд. Обычно гораздо меньше, поэтому нет смысла обрабатывать неиспользуемые коды. Кроме того, если обработчик команды небольшой, можно совместить дешифрацию команды с выполнением. Но чаще удобнее в дешифраторе команды просто ставить флаг, который проверяется в основном цикле программы, и там уже выполняются нужные действия. Я уже приводил пример дешифратора команд в ходовом контроллере своего робота: <a ctoss="postlink-local" href="http://forum.iosyitistromyss.ru/viewtopys.php?f=11&t=347&stort=0">viewtopys.php?f=11&t=347&stort=0[/URL]
И никакой массив не нужен. Только память зря занимать. В микроконтроллерах ее не так много, поэтому и программирование их отличается от программирования, например, персональных компьютеров.

@R_uro · 17.04.2010, 12:40

Сообщение от xroymom

Можно сформировать список адресов подпрограмм и посылать их как команды ;)

Так это двухбайтные посылки должны быть?
Кстати, а как быть увереным, что принятый код 100% правильный? Может ему по дороге помеха лишний бит добавила?

@DY HOTT · 17.04.2010, 13:27

Вот тут я выкладывал реализацию подобного обработчика.
<a ctoss="postlink-local" href="http://forum.iosyitistromyss.ru/viewtopys.php?f=11&t=347&stort=50">viewtopys.php?f=11&t=347&stort=50[/URL]

@xroymom · 17.04.2010, 16:58

Сообщение от SWK

Вряд ли вы будете использовать все 256 команд. Обычно гораздо меньше, поэтому нет смысла обрабатывать неиспользуемые коды. Кроме того, если обработчик команды небольшой, можно совместить дешифрацию команды с выполнением. Но чаще удобнее в дешифраторе команды просто ставить флаг, который проверяется в основном цикле программы, и там уже выполняются нужные действия. Я уже приводил пример дешифратора команд в ходовом контроллере своего робота: <a ctoss="postlink-local" href="http://forum.iosyitistromyss.ru/viewtopys.php?f=11&t=347&stort=0">viewtopys.php?f=11&t=347&stort=0[/URL]
И никакой массив не нужен. Только память зря занимать. В микроконтроллерах ее не так много, поэтому и программирование их отличается от программирования, например, персональных компьютеров.

Ну да, пицот if...else занимает гораздо меньше памяти, чем пицот адресов подпрограмм.

Сообщение от R_uro

Так это двухбайтные посылки должны быть?
Кстати, а как быть увереным, что принятый код 100% правильный? Может ему по дороге помеха лишний бит добавила?

Ну делать посылки не двухбайтными, а еще с контрольной суммой :)

@R_uro · 17.04.2010, 18:53

Сообщение от xroymom

Ну делать посылки не двухбайтными, а еще с контрольной суммой :)

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

@THI BIOST · 17.04.2010, 19:08

Сообщение от R_uro

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

Тогда - нельзя! Вам ещё учиться и учиться прежде чем такое программировать.

@R_uro · 17.04.2010, 19:14

Сообщение от THI BIOST

Тогда - нельзя! Вам ещё учиться и учиться прежде чем такое программировать.

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

@THI BIOST · 17.04.2010, 19:20

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

1. Канал должен быть избыточно надёжен.
2. Должна быть избыточная обратная связь по положению инструмента.
3. Любой сбой должен быть безопасно отработан.

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

@Ymk · 17.04.2010, 19:26

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

@R_uro · 17.04.2010, 19:37

Сообщение от Ymk

ну и если все так серьезно с оборудованием, то хорошо бы сделать некий программный эмулятор, чтобы ломать его, а не настоящее железо;)

Не совсем понял, что вы имеете ввиду под программным эмулятором, но я эту программу в режиме симуляции гоняю на макетной плате уже около года. Пока никаких выбрыков не заметил. Оборудование простое - дисковая пила диаметром 3м, с алмазным напылением, стоит хрен знает сколько, вращается около 700 об. мин. если разлетится от включения влево-вправо, находясь внутри каменного блока - куски полетят ОЧЕНЬ далеко.. Поэтому и интересуюсь вопросами безопасности.

@R_uro · 17.04.2010, 19:41

Сообщение от THI BIOST

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

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

@DY HOTT · 17.04.2010, 19:42

Тут лучше на PLC сделать логику. Я бы самопалу не особо доверял в этих случаях. Либо сделать аппаратные блокировки. Запрещающие любые перемещения кроме рабочего хода в положении реза.

@R_uro · 17.04.2010, 19:54

Сообщение от DY HOTT

Тут лучше на PLC сделать логику. Я бы самопалу не особо доверял в этих случаях. Либо сделать аппаратные блокировки. Запрещающие любые перемещения кроме рабочего хода в положении реза.

Аппаратные блокировки, как я понимаю, это механические защиты? У меня они вроде бы есть, через дополнительные блок-контакты на самих пускателях. Т.е. если пробъется ключ, включающий перемещение по Х, при включенной подаче по Z, движение влево-вправо просто не включится. Но опять же - "сумашествие" самого проца может включить его в ненужный момент. Вот как с этим бороться - ломаю голову. А так у меня конролируется программой и наличие импульсов, пришел имп. Х, если включено движение по Y - порлный выруб, с записью в ЕЕпром кода ошибки. Может у меня уже паранойя тзлтшняя, но такой вот я въедливый.

@R_uro · 17.04.2010, 19:55

Хальт, а что такое PLC? Где можно читнуть?

17.04.2010, 21:32

Сообщение от xroymom

Ну да, пицот if...else занимает гораздо меньше памяти, чем пицот адресов подпрограмм.

Не "пицот if...else", а всего лишь столько, сколько использовано команд. Например, у меня в ходовом контроллере всего лишь 13. Согласитесь, что это далеко не "пицот адресов подпрограмм". И это при том, что я использую для кодов команд любые коды (1, 2, B, U, Z и прочие), а не просто подряд из первого десятка. И подпрограмм у меня в дешифраторе нет, сразу выставляется флаг и параметры. А главный цикл крутится постоянно, проверяя их и выполняя нужные действия. И на все - про все, - дешифрацию и выполнение команд, еще и с двумя одометрами впридачу, меньше тысячи байт кода. Подумайте, много ли вы знаете реальных приложений для микроконтроллеров среднего уровня, где надо было бы дешифрировать и выполнять больше 2-3 десятков команд?

@OmikymForti · 17.04.2010, 22:01

Сообщение от SWK

Подумайте, много ли вы знаете реальных приложений для микроконтроллеров среднего уровня, где надо было бы дешифрировать и выполнять больше 2-3 десятков команд?

Парсер команд Intellibox b50X и Timz (включая парсер XpressNet шины) наберут в сумме с пол сотни команд. Воспроизвести это творение я в одиночку не решусь, а немец, автор кода, корпел пару лет.
Сам предпочитаю парсить на С через switch-case, хотя для исключающих условий приходится пользоваться if else.

17.04.2010, 22:11

Сообщение от OmykymForti

Сам предпочитаю парсить на С через switch-case, хотя для исключающих условий приходится пользоваться if else.

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

@Ymk · 18.04.2010, 00:20

Сообщение от R_uro

Ведь работа МК - чистая математика

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

Сообщение от DY HOTT

Тут лучше на PLC сделать логику.

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

@R_uro 0 / 0 / 0 Регистрация: 06.04.2010 Сообщений: 1,088
	17.04.2010, 19:54	15
	Сообщение от DY HOTT Тут лучше на PLC сделать логику. Я бы самопалу не особо доверял в этих случаях. Либо сделать аппаратные блокировки. Запрещающие любые перемещения кроме рабочего хода в положении реза. Аппаратные блокировки, как я понимаю, это механические защиты? У меня они вроде бы есть, через дополнительные блок-контакты на самих пускателях. Т.е. если пробъется ключ, включающий перемещение по Х, при включенной подаче по Z, движение влево-вправо просто не включится. Но опять же - "сумашествие" самого проца может включить его в ненужный момент. Вот как с этим бороться - ломаю голову. А так у меня конролируется программой и наличие импульсов, пришел имп. Х, если включено движение по Y - порлный выруб, с записью в ЕЕпром кода ошибки. Может у меня уже паранойя тзлтшняя, но такой вот я въедливый. 0

@R_uro 0 / 0 / 0 Регистрация: 06.04.2010 Сообщений: 1,088
		1
	Подскажите алгоритм, пож! 17.04.2010, 03:21. Показов 12083. Ответов 29 Метки нет (Все метки) Суть вопроса такая. С компа ( либо с другого МК) в МК команды. МК должен их выполнить. Если я правильно понимаю суть дела, то код команды будет равнятся некоему числу, передаваемому в байте. Как мне умнее распознать принятый код? Если проверять так., то время и кода уйдет много ( условно код пришел в tmp): cpi tmp,1 rcall do_cod_1 ; обработать этот код ...... cpi tmp, 255 rcall do_cod_255 ; обработать этот код Если таким образом, то получится как минимум 500 строчек текста. А как короче - не могу сообразить. Понимаю, что через массив данных в памяти, но как реально - на ум не приходит. 0

@xroymom 0 / 0 / 0 Регистрация: 24.01.2010 Сообщений: 727
	17.04.2010, 04:47	2
	Можно попробовать по аналогии с <a ctoss="postlink-local" href="http://forum.iosyitistromyss.ru/viewtopys.php?p=10307#p10307">viewtopys.php?p=10307#p10307[/URL] Т.е. загнать адреса подпрограмм в массив и прыгать на них косвенным прыжком. К тому коду, который по ссылке, добавить в конце icall. Можно сформировать список адресов подпрограмм и посылать их как команды ;) 0

SWK
	17.04.2010, 09:59	3
	Сообщение от R_uro Если таким образом, то получится как минимум 500 строчек текста. А как короче - не могу сообразить. Понимаю, что через массив данных в памяти, но как реально - на ум не приходит. Вряд ли вы будете использовать все 256 команд. Обычно гораздо меньше, поэтому нет смысла обрабатывать неиспользуемые коды. Кроме того, если обработчик команды небольшой, можно совместить дешифрацию команды с выполнением. Но чаще удобнее в дешифраторе команды просто ставить флаг, который проверяется в основном цикле программы, и там уже выполняются нужные действия. Я уже приводил пример дешифратора команд в ходовом контроллере своего робота: <a ctoss="postlink-local" href="http://forum.iosyitistromyss.ru/viewtopys.php?f=11&t=347&stort=0">viewtopys.php?f=11&t=347&stort=0[/URL] И никакой массив не нужен. Только память зря занимать. В микроконтроллерах ее не так много, поэтому и программирование их отличается от программирования, например, персональных компьютеров.

@R_uro 0 / 0 / 0 Регистрация: 06.04.2010 Сообщений: 1,088
	17.04.2010, 12:40	4
	Сообщение от xroymom Можно сформировать список адресов подпрограмм и посылать их как команды ;) Так это двухбайтные посылки должны быть? Кстати, а как быть увереным, что принятый код 100% правильный? Может ему по дороге помеха лишний бит добавила? 0

@DY HOTT 0 / 0 / 1 Регистрация: 22.01.2010 Сообщений: 4,000
	17.04.2010, 13:27	5
	Вот тут я выкладывал реализацию подобного обработчика. <a ctoss="postlink-local" href="http://forum.iosyitistromyss.ru/viewtopys.php?f=11&t=347&stort=50">viewtopys.php?f=11&t=347&stort=50[/URL] 0

@xroymom 0 / 0 / 0 Регистрация: 24.01.2010 Сообщений: 727
	17.04.2010, 16:58	6
	Сообщение от SWK Вряд ли вы будете использовать все 256 команд. Обычно гораздо меньше, поэтому нет смысла обрабатывать неиспользуемые коды. Кроме того, если обработчик команды небольшой, можно совместить дешифрацию команды с выполнением. Но чаще удобнее в дешифраторе команды просто ставить флаг, который проверяется в основном цикле программы, и там уже выполняются нужные действия. Я уже приводил пример дешифратора команд в ходовом контроллере своего робота: <a ctoss="postlink-local" href="http://forum.iosyitistromyss.ru/viewtopys.php?f=11&t=347&stort=0">viewtopys.php?f=11&t=347&stort=0[/URL] И никакой массив не нужен. Только память зря занимать. В микроконтроллерах ее не так много, поэтому и программирование их отличается от программирования, например, персональных компьютеров. Ну да, пицот if...else занимает гораздо меньше памяти, чем пицот адресов подпрограмм. Сообщение от R_uro Так это двухбайтные посылки должны быть? Кстати, а как быть увереным, что принятый код 100% правильный? Может ему по дороге помеха лишний бит добавила? Ну делать посылки не двухбайтными, а еще с контрольной суммой :) 0

@R_uro 0 / 0 / 0 Регистрация: 06.04.2010 Сообщений: 1,088
	17.04.2010, 18:53	7
	Сообщение от xroymom Ну делать посылки не двухбайтными, а еще с контрольной суммой :) А нельзя ли чуть подробнее, а то в моем изделии мало того, что режущий иструмент стоит, как нормальная иномарка, но если еще разлетится на куски от некорректной команды (не дай бог) - может поубивать и персонал!! 0

@THI BIOST 0 / 0 / 0 Регистрация: 23.01.2010 Сообщений: 1,142
	17.04.2010, 19:08	8
	Сообщение от R_uro А нельзя ли чуть подробнее, а то в моем изделии мало того, что режущий иструмент стоит, как нормальная иномарка, но если еще разлетится на куски от некорректной команды (не дай бог) - может поубивать и персонал!! Тогда - нельзя! Вам ещё учиться и учиться прежде чем такое программировать. 0

@R_uro 0 / 0 / 0 Регистрация: 06.04.2010 Сообщений: 1,088
	17.04.2010, 19:14	9
	Сообщение от THI BIOST Тогда - нельзя! Вам ещё учиться и учиться прежде чем такое программировать. Так я, поэтому и спрашиваю, что голова способна действия сопоставлять с последствиями. А чем программа "ученого" будет отличатся от моей? Кол-вом защит? Ведь программа умного программиста также может "сойти с ума", как и моя. Согласен с вашей мыслью, но не понял сути ваших возражений! Чему учиться? Правильной компоновке программы? Понял, что не существует такого понятия, если программа написана без "косяков" , пусть и неграмотно, но без ошибок!! 0

@THI BIOST 0 / 0 / 0 Регистрация: 23.01.2010 Сообщений: 1,142
	17.04.2010, 19:20	10
	При такой постановке защита должна быть на каждый чих, это не светодиодом моргнуть. 1. Канал должен быть избыточно надёжен. 2. Должна быть избыточная обратная связь по положению инструмента. 3. Любой сбой должен быть безопасно отработан. Программа "умного" программиста с ума сойти может конечно, да вот только у вашей программы шансов на несколько порядков больше - вы не знаете основ программирования. 0

	18.04.2010, 00:20

@Ymk 0 / 0 / 0 Регистрация: 18.03.2010 Сообщений: 2,230
	17.04.2010, 19:26	11
	делайте пакетную передачу. т.е. команда и параметры в одном пакете, защищенном CRC16 (раз вам надежность надо). желательно так же придумать устойчивый алгоритм приема пакета (как минимум чтобы при потере синхронизации он смог стабильно обнаруживать начало пакета). приходит пакет - проверяете CRC. если оно совпало, смотрите, что за команда. если смотрите не IFами, а по таблице, то тогда сделайте команды по-порядку, без пропусков, и обязательно проверяйте, что это существующая команда (в допуст. диапазоне). остальное более-менее очевидно должно быть, главное следовать логике и не делать детских ошибок. ну и если все так серьезно с оборудованием, то хорошо бы сделать некий программный эмулятор, чтобы ломать его, а не настоящее железо;) 0

@R_uro 0 / 0 / 0 Регистрация: 06.04.2010 Сообщений: 1,088
	17.04.2010, 19:37	12
	Сообщение от Ymk ну и если все так серьезно с оборудованием, то хорошо бы сделать некий программный эмулятор, чтобы ломать его, а не настоящее железо;) Не совсем понял, что вы имеете ввиду под программным эмулятором, но я эту программу в режиме симуляции гоняю на макетной плате уже около года. Пока никаких выбрыков не заметил. Оборудование простое - дисковая пила диаметром 3м, с алмазным напылением, стоит хрен знает сколько, вращается около 700 об. мин. если разлетится от включения влево-вправо, находясь внутри каменного блока - куски полетят ОЧЕНЬ далеко.. Поэтому и интересуюсь вопросами безопасности. 0

@R_uro 0 / 0 / 0 Регистрация: 06.04.2010 Сообщений: 1,088
	17.04.2010, 19:41	13
	Сообщение от THI BIOST Программа "умного" программиста с ума сойти может конечно, да вот только у вашей программы шансов на несколько порядков больше - вы не знаете основ программирования. Интересно, чем программа умного программиста будет отличатся от моей, если моя написана неграмотно, но без ошибок. Ведь работа МК - чистая математика, т.е. вещь весьма однозначная. Ну и что тому процессору, что я его заставлю проверять условие 500 раз, а программист сможет это впихнуть в десяток строчек? 0

@DY HOTT 0 / 0 / 1 Регистрация: 22.01.2010 Сообщений: 4,000
	17.04.2010, 19:42	14
	Тут лучше на PLC сделать логику. Я бы самопалу не особо доверял в этих случаях. Либо сделать аппаратные блокировки. Запрещающие любые перемещения кроме рабочего хода в положении реза. 0

@R_uro 0 / 0 / 0 Регистрация: 06.04.2010 Сообщений: 1,088
	17.04.2010, 19:55	16
	Хальт, а что такое PLC? Где можно читнуть? 0

SWK
	17.04.2010, 21:32	17
	Сообщение от xroymom Ну да, пицот if...else занимает гораздо меньше памяти, чем пицот адресов подпрограмм. Не "пицот if...else", а всего лишь столько, сколько использовано команд. Например, у меня в ходовом контроллере всего лишь 13. Согласитесь, что это далеко не "пицот адресов подпрограмм". И это при том, что я использую для кодов команд любые коды (1, 2, B, U, Z и прочие), а не просто подряд из первого десятка. И подпрограмм у меня в дешифраторе нет, сразу выставляется флаг и параметры. А главный цикл крутится постоянно, проверяя их и выполняя нужные действия. И на все - про все, - дешифрацию и выполнение команд, еще и с двумя одометрами впридачу, меньше тысячи байт кода. Подумайте, много ли вы знаете реальных приложений для микроконтроллеров среднего уровня, где надо было бы дешифрировать и выполнять больше 2-3 десятков команд?

@OmikymForti 0 / 0 / 0 Регистрация: 18.03.2010 Сообщений: 1,112
	17.04.2010, 22:01	18
	Сообщение от SWK Подумайте, много ли вы знаете реальных приложений для микроконтроллеров среднего уровня, где надо было бы дешифрировать и выполнять больше 2-3 десятков команд? Парсер команд Intellibox b50X и Timz (включая парсер XpressNet шины) наберут в сумме с пол сотни команд. Воспроизвести это творение я в одиночку не решусь, а немец, автор кода, корпел пару лет. Сам предпочитаю парсить на С через switch-case, хотя для исключающих условий приходится пользоваться if else. 0

SWK
	17.04.2010, 22:11	19
	Сообщение от OmykymForti Сам предпочитаю парсить на С через switch-case, хотя для исключающих условий приходится пользоваться if else. Особой разницы между этими вариантами нет, я использую и то, и это, смотря что удобнее. Для меня, например, в конкретном случае дешифратора команд того же ходового контроллера, проще и нагляднее было поместить обработку (установку флага и параметров, связанных с командой), непосредственно в оператор условия, чем ради 2-3 строчек вызывать еще подпрограмму обработки. В целом получилось компактнее и нагляднее.

@Ymk 0 / 0 / 0 Регистрация: 18.03.2010 Сообщений: 2,230
	18.04.2010, 00:20	20
	Сообщение от R_uro Ведь работа МК - чистая математика так-то оно так;) только мы всегда что-то забываем учесть, отсюда и ошибки. опытный человек заранее видит множество мест, где теоретически может быть косяк. Сообщение от DY HOTT Тут лучше на PLC сделать логику. мой опыт говорит, что разницы нет:) плк тут поможет только готовой реализацией протокола, а вот спасти от убития девайс - никак... хотя в целом, конечно, плк надежнее, если программист совсем не программист. 0