Отправлено: 27.04.09 18:53. Заголовок: Генератор задержек для ПИК

Примерно полтора года назад, здесь была просьба сделать программу, аналогичную программе "Pause" Николая Марова, но которая должна формировать задержку исходя из данных о частоте генератора контроллера и длительности задержки. Тогда это не получилось сделать и пришлось ограничится калькулятором, который высчитывал число машинных циклов исходя из данных о чатоте генератора и длительности задержки.

Буквально пару дней назад Игорь Батов подкинул мне идею как это можно сделать.
После нескольких экспериментов стало понятно что направление правильное и надо "копать" именно в эту сторону.
В результате, через пару часов всё получилось (кажется), по крайней мере я не смог найти ошибок в преобразовании.
Но непомешает дополнительная проверка.
Выкладываю заготовку программы, её надо протестировать http://www.filehoster.ru/files/cq1114
Сейчас она работает только с машинными циклами - так проще её отлаживать.
Кагда станет ясно что программа работает стабильно и ошибок в преобразовании нет, тогда соединю её с калькулятором.

 Отправлено: 27.04.09 19:15. Заголовок: :sm36: ..

Программа очень нужная. Желаю успехов.

 Отправлено: 27.04.09 19:22. Заголовок: Пётр пишет: пришлос..

Пётр пишет:

цитата:

пришлось ограничится калькулятором

Я этим калькулятором всякий раз пользуюсь. Без него программа Николая конечно не очень полноценная.

 Отправлено: 27.04.09 19:33. Заголовок: Вот и я говорю, ..

Вот и я говорю, что "два в одном флаконе" это гораздо лучше чем два отдельных "флакона".

 Отправлено: 27.04.09 19:59. Заголовок: Пётр, спасибо, что н..

Пётр, спасибо, что не забыли. Обе программы архинужные. Без них, как без рук. Если получится сделать их как "две в одном флаконе", будет программа не то, что на каждый день, а на каждый час!

 Отправлено: 27.04.09 23:44. Заголовок: Пока проект не закон..

Пока проект не закончен, одно небольшое замечание:

т.е. должно быть 65 млн, а не 655. И еще, мне кажется, было бы неплохо, если бы было какое-то разделение (пробелом, точкой) групп цифр, т.е. 65.536 или 562.425.123, или так 65 536 или 562 425 123. При вводе большого числа так бы было удобнее, ИМХО.

 Отправлено: 28.04.09 16:56. Заголовок: Alberto пишет: дол..

Alberto пишет:

цитата:

должно быть 65 млн, а не 655

Точно.
Я в основном смотрел чтобы небыло ошибок в преобразовании, а это прозевал.
Кстати, в алгоритме есть ошибка.
Попробуйте в вести 197124 а потом 197125 и сравните с результатом программы "Pause". Эта ошибка устанена.

 Отправлено: 28.04.09 17:04. Заголовок: Пётр пишет: Эта оши..

Пётр пишет:

цитата:

Эта ошибка устанена.

а новую версию выложил?

 Отправлено: 28.04.09 17:10. Заголовок: Нет. Вот добавлю ещё..

Нет.
Вот добавлю ещё подержку сторожевого таймера, тогда и выложу.

 Отправлено: 14.05.09 10:10. Заголовок: Бяк оказалось больше..

Бяк оказалось больше чем я думал.
В принципе есть вводить числа наугад, то в подавляющем числе сучаев результат верный.
Но на границе перехода с одного регистра на другой (например, если ввести число 773) появляется бяка!
Похоже что нужно вносить корректировку при переходах между регистрами...

 Отправлено: 26.05.09 18:43. Заголовок: Разобрался с коррект..

Разобрался с корректировкой регистров.
Эта корректировка нужна в том случае если имеющегося числа регистров недостаточно для создания задержки, а если добавить регистр, то станет много. Правда это случается очень редко. В этом случае внутрь последнего "кольца" задержки нужно вставлять дополнительный Nop и уменьшать величину задержки на количество циклов, затраченых на выполнение этого Nop'а. Иными словами, нужно отнять 255 от величины задержки.

Вот доработаный вариант программы http://purik.nextmail.ru/pic/Delay_1_1.rar
Его проверял в течение нескольких часов подставляя разные виличины задержки и не обнаружил ошибок в преобразовании.
Но т. к. длительность задержки может находиться в пределах 4...216737899999999999, то просто нереально проверить работу со всеми возможными вариантами...

 Отправлено: 26.05.09 20:01. Заголовок: Пётр пишет: Разобра..

Пётр пишет:

цитата:

Разобрался с корректировкой регистров. Эта корректировка нужна в том случае если имеющегося числа регистров недостаточно для создания задержки, а если добавить регистр, то станет много. Правда это случается очень редко. В этом случае внутрь последнего "кольца" задержки нужно вставлять дополнительный Nop и уменьшать величину задержки на количество циклов, затраченых на выполнение этого Nop'а. Иными словами, нужно отнять 255 от величины задержки. Вот доработаный вариант программы http://purik.nextmail.ru/pic/Delay_1_1.rar Его проверял в течение нескольких часов подставляя разные виличины задержки и не обнаружил ошибок в преобразовании. Но т. к. длительность задержки может находиться в пределах 4...216737899999999999, то просто нереально проверить работу со всеми возможными вариантами...

Я тоже погонял во всех направлениях. Ошибок нет.

 Отправлено: 26.05.09 20:05. Заголовок: Спасибо, Пётр. Сегод..

Спасибо, Пётр. Сегодня времени не будет, но на днях обязательно погоняю.

 Отправлено: 28.05.09 19:21. Заголовок: Добавил поддержку ст..

Добавил поддержку сторожевого таймера
http://purik.nextmail.ru/pic/Delay_1_2.rar

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

 Отправлено: 28.05.09 19:58. Заголовок: Пётр пишет: Добавил..

Пётр пишет:

цитата:

Добавил поддержку сторожевого таймера

Можете не поверить но я специально зашел чтобы про WDT напомнить . Бывает же.

цитата:

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

сейчас скачаю и проверю.
Проверил, всё нормально.
Было бы неплохо добавить работу не с машинными циклами, а с сек (мсек, мксек и т.д.) и с частотой использованного кварца.

 Отправлено: 28.05.09 22:23. Заголовок: Alberto пишет: Пров..

Alberto пишет:

цитата:

Проверил, всё нормально.

Значит русские буквы нормально отображаются в винде, которая напрямую не поддерживает кириллицу. Замечательно!
А в предыдущей версии программы текст тоже нормально отображается в испанской винде?

Alberto пишет:

цитата:

Было бы неплохо добавить работу не с машинными циклами, а с сек (мсек, мксек и т.д.) и с частотой использованного кварца.

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


PS.
Кто нибудь из нас использует операционную систему Linux?
Если что, могу скомпилировать прогу и под эту ОС

 Отправлено: 29.05.09 05:07. Заголовок: Пётр пишет: А в пре..

Пётр пишет:

цитата:

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

в самой первой версии были "крякозябры", а предыдущую завтра на работе попробую, дома у меня русская Винда.

цитата:

Кто нибудь из нас использует операционную систему Linux?

а разве MPLAB идет под Linux'ом?

 Отправлено: 29.05.09 06:48. Заголовок: Alberto пишет: а ра..

Alberto пишет:

цитата:

а разве MPLAB идет под Linux'ом?

Да есть версия под линукс.

 Отправлено: 29.05.09 13:08. Заголовок: Так кроме MPLAB'..

 Отправлено: 29.05.09 13:12. Заголовок: Alberto пишет: а пр..

Alberto пишет:

цитата:

а предыдущую завтра... попробую

предыдущая:

 Отправлено: 30.05.09 13:10. Заголовок: Верися 1.2 имеет одн..

Верися 1.2 имеет одну серьёзную ошибку, связанную с тем, что программа скомпилирована в формате юникода. Ошибка проявлявлятся в том, что числа отображаются в диапазоне 0...65536, а не в 0...255


Полностью переделал окно - добавил калькулятор. http://purik.nextmail.ru/pic/PIC_Delay_1_3.rar
Есть пока небольшёй глюк при задействованом сторожевом таймере, связанный с корректировкой регистов. В ближайшее время постараюсь исправить.

 Отправлено: 30.05.09 15:21. Заголовок: Пётр пишет: Верися ..

Пётр пишет:

цитата:

Верися 1.2 имеет одну серьёзную ошибку, связанную с тем, что программа скомпилирована в формате юникода.

а не проще сделать выбор языка из списка? Хоть русский, хоть индейцев племени мумба-юмба.

 Отправлено: 30.05.09 17:07. Заголовок: Alberto пишет: а не..

Alberto пишет:

цитата:

а не проще сделать выбор языка из списка?

Ну во первых надо знать эти языки, а во вторых, не факт что без поддержки юникода это получится сделать!
Я как-то пробовал русифицировать одну из прог, так вот, в место русских букв были крякозябры.
Да и делеко ходить не надо, достаточно вспомнить программу WinPic800.

А если программа поддерживает юникод, то теоритически в окне проги можно одновременно отображать текст любого из языков, даже китайскике иероглифы.
Это благодаря тому, что для кодирования символа используется 2 байта, что позволяет отобразить любой из 65536 различных символов.
Если программа использует Ascii формат, то на кодировку символа используется только один байт и поэтому можно закодировать всего 256 символов.

 Отправлено: 30.05.09 20:06. Заголовок: Alberto пишет: на д..

Alberto пишет:

цитата:

на днях обязательно погоняю

погонял. Нашёл вот что:

понимаю что при задержке в пару сотен тысяч лет одна мксек ничто, но факт есть факт. И еще, без использования калькулятора максимальная задержка может быть 216 737 899 999 999 999 машинных циклов, а если попытаться ввести тоже значение в микросекундах (при частоте кварца 4 МГц), то пишет что "Задана слишком большая задержка". Может стоит убрать разрядность вычислений в одном случае или добавить в другом, чтобы они в обоих случаях были одинаковыми?

 Отправлено: 30.05.09 21:15. Заголовок: Это из-за того, что ..

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

Alberto пишет:

цитата:

максимальная задержка может быть 216 737 899 999 999 999 машинных циклов, а если попытаться ввести тоже значение в микросекундах (при частоте кварца 4 МГц), то пишет что "Задана слишком большая задержка".

Наверно просто происходит округление в большую сторону и в итоге такое сообшение.
Кстати, я немного доработал прогу (выложу позже) и теперь максимальная задержка составляет 9.223.372.036.854.775.800
Это даже больше чем в программе Николая Марова
Увеличивать дальше уже PureBasic не позволяет.

 Отправлено: 30.05.09 21:34. Заголовок: Пётр пишет: Надо вы..

Пётр пишет:

цитата:

Надо выбирать, или точность при обработке больших чисел, или отказ от дроби.

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

 Отправлено: 31.05.09 12:16. Заголовок: В сожалению отказать..

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

 Отправлено: 31.05.09 15:48. Заголовок: Погонял его еще немн..

Погонял его еще немного. Погрешность есть только на пределе. Может быть как больше заданного значения, так и меньше: +/- 1-2 мксек. В программе Николая Марова такого нет. Специально проверял. Ты не пробовал с ним связаться, может он поделится алгоритмом? Это первый вариант. Второй вариант: ограничить верхний предел в 31 557 600 000 000 мксек (около 1000 лет). Этого больше чем достаточно для любого, самого безумного программиста. Зачем гнаться за задержками в 300 млн. лет? И третий вариант: в самой программе, в окне машинного кода убрать надпись задержка столько-то машинных циклов, оставить только в мксек/мсек/сек и т.д. И последний вариант: при задержках на пределе, вместе с другими надписями выводить надпись предупреждающую о данной особенности.
Я бы остановился на третьем варианте: если я ввожу задержку в сутках, то зачем мне знать ее с точностью до машинного цикла? Плюс/минус одна-две мксек роли не сыграют. Если такая точность нужна, то нужно сразу вводить в мксек. Конечно это ИМХО.

 Отправлено: 31.05.09 16:22. Заголовок: Alberto пишет: Може..

Alberto пишет:

цитата:

Может быть как больше заданного значения, так и меньше: +/- 1-2 мксек. В программе Николая Марова такого нет

Так это глюк калькулятора или генератора кода?
Если генератора кода, то при каком числе машинных циклов появляется ошибка?
Я думаю что ошибка в несколько машинных циклов при выдержке в пару лет, всё же допустима, ведь нестабильность тактового генератора внесёт гораздо большую ошибку!
Да и вряд ли такая большая задержка вообще нужна, обычно используется до миллиона машинных циклов.

 Отправлено: 31.05.09 16:52. Заголовок: Пётр пишет: Так это..

Пётр пишет:

цитата:

Так это глюк калькулятора или генератора кода? Если генератора кода, то при каком числе машинных циклов появляется ошибка?

думаю что генератора кодов. Хотя не уверен, нужно проверить. И сложно вот так сразу сказать при каком конкретно числе появляется ошибка.

цитата:

ведь нестабильность тактового генератора внесёт гораздо большую ошибку! Да и вряд ли такая большая задержка вообще нужна

вот и я о том же. Ну если уж хочется иметь возможность рассчитать задержку в 300 млн. лет, то смотри вариант 3 в предыдущем посту:

убрать то, что зачеркнуто. Оставшейся информации больше чем достаточно и в глаза не лезет. Разумеется это ИМХО.

 Отправлено: 31.05.09 17:12. Заголовок: Зачем убирать? Наобо..

Зачем убирать?
Наоборот, путь сразу будет заметно что в вычислениях есть ошибка.

 Отправлено: 31.05.09 17:59. Заголовок: Тогда сразу теряется..

Тогда сразу теряется доверие и ко всему остальному. Это чисто психологически.
Тогда остается два пути: исправить или ограничить максимальную задержку "разумным" пределом (например в 10 тыс. лет, а не 500 тыс. как сейчас). Опять же ИМХО.

 Отправлено: 31.05.09 20:11. Заголовок: Пётр пишет: Так это..

Пётр пишет:

цитата:

Так это глюк калькулятора или генератора кода?

если это тебе поможет, то в "Длительность задержки в машинных циклах" подставляется правильное значение, а в поле "Время" - остается введенное число, которое может отличаться от рассчитанного в машинных циклах. Но это проявляется только на числах больше 3 000 000 000 000 000 мксек. Где именно искать сложно. Да и, честно говоря, кому нужна задержка в 95 тыс. лет? Или батарейки сядут, или солнечную панель песком занесет, или какая помеха пройдет. Так что это несущественно.
А в остальном отлично работает. Спасибо.

 Отправлено: 31.05.09 21:36. Заголовок: Alberto пишет: ..

Alberto пишет:

цитата:

"Длительность задержки в машинных циклах" подставляется правильное значение, а в поле "Время" - остается введенное число, которое может отличаться от рассчитанного в машинных циклах.

Это округление результата деления введённых данных при расчёте в калькуляторе.
В генераторе кода большие числа хранятся только в челочисленых переменных и поэтому там такая ошибка не произойдёт. Да и деления при вычислениях остатка нет, только умножение.

 Отправлено: 31.05.09 22:17. Заголовок: Пётр пишет: Это окр..

Пётр пишет:

цитата:

Это округление результата деления введённых данных при расчёте в калькуляторе.

думаю здесь надо проводить предварительный анализ и если есть остаток, то надо введенное значение уменьшать на 1-2 мксек, которые потом будут скомпенсированы одним-двумя nop'ами. Правда с алгоритмом данной программы не знаком, так что это только догадка. А вообще, как я уже говорил, меня задержки больше 90 тыс. лет мало интересуют, ввиду того что их сложно в MPLAB'е отследить.

 Отправлено: 25.06.09 18:17. Заголовок: Вот новая версия про..

Вот новая версия программы http://purik.nextmail.ru/pic/PIC_Delay_1_4.rar

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

Добавлена простейшая база данных имён регистров и меток. Это будет полезным если в отлаживаемой программе есть несколько подпрограмм задержек, которые при наладке надо изменять, т. е. подбировать задержку. Этого мне сильно нехватало в программе Николая Марова.
Кроме того, если в качестве имени метки использовать символ $, то метки как таковой не будет, а будет использоваться относительный переход (на уровне MPASMа, т. е. до компиляции) на начало цикла задержки.

Код будет таким

; Задержка 1 234 567 890 машинных циклов 
             Movlw       .148 
             Movwf       Reg_1 
             Movlw       .247 
             Movwf       Reg_2 
             Movlw       .119 
             Movwf       Reg_3 
             Movlw       .25 
             Movwf       Reg_4 
             Decfsz      Reg_1, F 
             Goto        $-1 
             Decfsz      Reg_2, F 
             Goto        $-3 
             Decfsz      Reg_3, F 
             Goto        $-5 
             Decfsz      Reg_4, F 
             Goto        $-7 
             Nop

 Отправлено: 25.06.09 18:56. Заголовок: Петр, прекрасно. По..

Петр, прекрасно.
После "сканирования" всеми желающими и в случае необнаружения "бяк" (я терпелив), эта программа может быть размещена на моем сайте (плюс "Обмен..."), но это полностью зависит от Вашего желания. Желание автора - закон.
Замечание: это применимо к ПИКам среднего семейства, но не к ПИКам 18-й серии (значение $-... должно быть бОльшим).
Полагаю, что это достаточно легко исправить путем введения в программу возможности выбора семейства ПИКов (ПИКи среднего семейства / ПИКи 18-й серии. По умолчанию - среднее семейство).
На мой взгляд, в командах не должно быть заглавных букв (например, не Goto, а goto).

 Отправлено: 25.06.09 19:08. Заголовок: Evgeny Korabelnikov ..

Evgeny Korabelnikov пишет:

цитата:

Полагаю, что это достаточно легко исправить путем введения в программу возможности выбора семейства ПИКов

цитата:

На мой взгляд, в командах не должно быть заглавных букв (например, не Goto, а goto).

было бы здорово.

 Отправлено: 25.06.09 19:42. Заголовок: Для 18-ых ПИКов испо..

Для 18-ых ПИКов использовать BANKED или ACCESS?

 Отправлено: 25.06.09 19:46. Заголовок: Для 18-ых ПИКов испо..

Для 18-ых ПИКов использовать BANKED или ACCESS?

Банк быстрого доступа (ACCESS) - в первую очередь, ну а BANKED - на Ваше усмотрение. Просто не хочу показаться наглым.

 Отправлено: 25.06.09 20:14. Заголовок: В первую очередь про..

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

Я только собираюсь изучать 18-тые ПИКи, так что задам парочку вопросов.

Ассемблерные инстукции остаются те же, или нужно использовать другие?
В первую очередь интерисует использовать GOTO или BRA?

Я так понимаю что инстукция DECFSZ работает как и в 16-той серии (в смысле для моей программмы)? Правда она выполняется за 3 м. ц. если происходит "скачок" через двух байтную инстукцию, которой является GOTO, т. е. нужно это учесть в генераторе задержек.