Програмирование pic на СИ.

[igorg1]

То: Крам
Вот ты только что такое написал - " Что такое Data Visualizer я в курсе. Вопрос был не про плагин, а про физический вывод из камня.
И тут твой замечательный ICD4 вообще не причем. Вывод в Data Visualizer не производится через ICSP.
Data Visualizer просто дает возможность увидеть данные полученные через COM порт от UART или SPI.
То есть через ненативные костыли. Нах такое "удобство". Лучше бы развивали DMCI, чтобы он избавился от детских багов и вывели JTAG из эрраты. DMCI и JTAG были бы самым удобным решением для контроля массивов сигналов. Но, увы..."

Вот снимок со свойств проекта -


Ты свою думку оставь при себе

[КРАМ]

[uquote="igorg1",url="/forum/viewtopic.php?p=4798388#p4798388"]а что ты молчишь про заморозку/разморозку переферии при отладке?[/uquote]
Я про нее уже все сказал. Заморозка периферии невозможна для твоей схемотехники, а ее работа при отладке приводит к проблемам мониторинга самого процесса вывода в ШИМ - инструменты контроля за переменными на лету у Микрочипа являются костыльными и неудобными.
Если ты этого не понимаешь, то это твои проблемы.

Добавлено after 1 minute 38 seconds:
[uquote="igorg1",url="/forum/viewtopic.php?p=4798390#p4798390"]Ты свою думку оставь при себе[/uquote]
Ты как всегда соврал. Показанный тобой скрин к dsPIC33 никакого отношения не имеет. Разговор про JTAG в эррате был именно про него.
Обтекай.
ЗЫ. Применение Микрочипом сторонних ядер позволяет использовать JTAG. Ясен пень, что через сканер JTAG можно данные пробросить в любой плагин.

[igorg1]

Сейчас открою проект на дсПИК33 - будет тоже самое.
Обтечёшь ты
Смотри про заморочку периферии на дсПИКе - там в названии проекта написано какой камень - и именно на нём я делал отладку для накала -

а вот про вывод

[КРАМ]

[uquote="igorg1",url="/forum/viewtopic.php?p=4798398#p4798398"]Сейчас открою проект на дсПИК33 - будет тоже самое.[/uquote]
Ну если в каком то dsPIC33 JTAG в эррату не попал, что вряд ли - я таких не встречал, а JTAG - это ядро и оно одно для всех, то значит именно на этом камне можно данные пробросить в плагин.
Только что это меняет?
Ты показал окно на фоне проекта для PIC10 - твои обычные шулерские замашки...

[igorg1]

Я показал тебе окно свойств на дсПИК - там так написано.
И на ПИК10 такое невозможно даже с HEADER - т. е. версией камня для отладки

Вот ты только что написал - "В третьих, ты бездарно просрешь возможности PIC32A, поскольку вообще ничего не знаешь про цифровую обработку сигналов и вообще не способен работать с камнем на самом нижнем уровне, реализуя все его фичи. Например автоматическое сохранение и восстановление контекста при переключениях задач при их небольшом количестве без применения громоздкого Зефира или иной РТОС. То есть шедулер в данном случае может быть примитивным до предела."
Когда ты не знаешь что такое планировщик в Зефире, как им пользоваться - лучше молчи
Могу тебе скинуть пример кода в main.c где цикла while () нет от слова совсем - при загрузке основной поток инициализирует другие потоки - и потом спокойно, штатно, завершает работу. А другие потоки продолжают свою работу в штатном режиме:)
А если ты своими корявыми ногтями залезешь в код планировщика - успеха не будет от слова совсем
Это понятно?

Добавлено after 2 minutes 18 seconds:
[uquote="КРАМ",url="/forum/viewtopic.php?p=4798402#p4798402"][uquote="igorg1",url="/forum/viewtopic.php?p=4798398#p4798398"]Сейчас открою проект на дсПИК33 - будет тоже самое.[/uquote]
Ну если в каком то dsPIC33 JTAG в эррату не попал, что вряд ли - я таких не встречал, а JTAG - это ядро и оно одно для всех, то значит именно на этом камне можно данные пробросить в плагин.
Только что это меняет?
Ты показал окно на фоне проекта для PIC10 - твои обычные шулерские замашки... [/uquote]
Не, тоже самое есть и в моём любимом dsPIC33EP256MU806.
Открыть проект?
Всё для тебя, дорогой - найду на сервере и открою.
Так делать?
Заметь - ты с меня постоянно что-то требуешь, я что-то постоянно оправдываюсь
Может хватит нести пургу?
говори по существу.

[КРАМ]

Игорек, для dsPIC33 можно написать шедулер самому. Не нужно никуда залазить.
Твоя попытка меня удивить отсутствием суперлупа в РТОС напомнила мне ситуацию, когда ребенок дошкольного возраста учит родителя... как делать детей...
Гомерически смешно. )))

[igorg1]

[uquote="КРАМ",url="/forum/viewtopic.php?p=4798410#p4798410"]Игорек, для dsPIC33 можно написать шедулер самому. Не нужно никуда залазить.
Твоя попытка меня удивить отсутствием суперлупа в РТОС напомнила мне ситуацию, когда ребенок дошкольного возраста учит родителя... как делать детей...
Гомерически смешно. )))[/uquote]
Ещё смеёшься?
Я тоже от твоего полного отсутствия понимания что такое РТОС.
И даже твоя кривая писанина не может называться РТОС - потому что помимо планировщика там ой как много что надо будет написать
FREERTOS уже лет 15-ть до ума доводят.
А Зефир только года 3 назад на ноги встал:)
Или ты уверяешь что КРАМRTOS ты за 2 недели напишешь???

Добавлено after 6 minutes 12 seconds:
И ты КРАМУшек, как-то ловко соскочил с темы что я не могу в отладке при наличии ОТЛАДЧИКА заморозить НУЖНУЮ мне периферию, а также через JTAG передавать что мне надо
Всё это и говорит о твоей квалификации, о том что ты просто диванный эксперт из 90-х на уровне АСМ и PIC16F84.

Добавлено after 11 minutes 10 seconds:
И если ты такой умный, рассуждая про отсутствие суперЛупа в коде для дсПИКа (да вообще хоть на каком камне), без РТОС - покажи мне хоть один пример кода, где будет отсутствовать while (1) - т. е. суперЛуп:) -сразу вылетишь аварийно.

[Transformer-V]

[uquote="КРАМ",url="/forum/viewtopic.php?p=4798115#p4798115"]У меня есть гибкая матрица примерно такого размера 16*64 диода. Завтра на работе сфотографирую
ЗЫ. Про размер соврал - 8*32:
https://supereyes.ru/catalog/led_matrit ... j358060609[/uquote]
Учитывая подключение ws2812b в данном поделии это близко не матрица(хоть и внешне похожа). Матрицей она будет когда каждая строка или колонка будет иметь вход.

P.S. NZR то ещё Г..., лучше использовать адресные светодиоды с SPI шиной.

[ARV]

Блин, без суперлупа МК даже остановить невозможно, не сняв питание. На сколько мне известно, "нормальное" завершение main все равно кончается бесконечным циклом при запрещённых прерываниях...

И в РТОСах тоже суперлуп есть, как минимум, в планировщике.

Так что тут всё дело в терминологии.

Добавлено after 3 minutes 53 seconds:
Думаю, только программа запуска детонации боеприпаса может в самом деле обойтись без оного

[Rapra]

Не обязательно, зависит от того, как написано то, что вне main(). У STM там по умолчанию бесконечный цикл. Но если бы его не было, МК ушел бы в одно из исключений, встретив недопустимую инструкцию, поскольку счетчик программ считает по возрастанию, если нет прямого указания на переход.
Остановить МК можно, отправив его в Sleep.

[ARV]

Остановить МК можно, отправив его в Sleep.

это "приостановить". sleep по традиции должен быть внутри "суперлупа". даже HALT в 8080 без запрета прерываний не может считаться остановкой.

ушел бы в одно из исключений

исключение - это всего лишь функция с бесконечным циклом (по умолчанию)

[КРАМ]

[uquote="ARV",url="/forum/viewtopic.php?p=4798512#p4798512"]Блин, без суперлупа МК даже остановить невозможно, не сняв питание. На сколько мне известно, "нормальное" завершение main все равно кончается бесконечным циклом при запрещённых прерываниях...
И в РТОСах тоже суперлуп есть, как минимум, в планировщике.[/uquote]
Под main() понимается та функция, с которой МК стартует. А не планировщик. Поэтому в файле main.c действительно может отсутствовать конструкция while(1). Правда это еще не означает отсутствие бесконечного цикла, поскольку код может по тем или иным причинам все таки дойти до последней инструкции в main() и тогда МК нужно ресетить, что бы повторно инициализировать. Таким образом цикл все таки есть. Но не с помощью while(1).
А так в РТОС суперлуп есть не только в планировщике, но и в каждой задаче.
Но поскольку они могут быть написаны не в файле main.c, то действительно в РТОС в этом файле (при определенных условиях) отсутствует суперлуп.
[uquote="Transformer-V",url="/forum/viewtopic.php?p=4798497#p4798497"]в данном поделии это близко не матрица(хоть и внешне похожа). Матрицей она будет когда каждая строка или колонка будет иметь вход.[/uquote]
Нет. Это классическая матрица. И в ОЗУ ее образ тоже будет трехмерным массивом. Как она управляется - дело десятое.
Обсуждаемая матрица в 256 диодов имеет частоту полной регенерации 120 fps. Вполне себе неплохо для такой матрицы.
В экранах HD драйверы обслуживают такие светодиоды в вертикальных столбцах. Обычно эти драйверы реализованы на FPGA.
[uquote="Transformer-V",url="/forum/viewtopic.php?p=4798497#p4798497"]NZR то ещё Г..., лучше использовать адресные светодиоды с SPI шиной.[/uquote]
Назови мне тип такого адресного светодиода. Было бы интересно узнать.
[uquote="igorg1",url="/forum/viewtopic.php?p=4798431#p4798431"]И даже твоя кривая писанина не может называться РТОС - потому что помимо планировщика там ой как много что надо будет написать
FREERTOS уже лет 15-ть до ума доводят.
А Зефир только года 3 назад на ноги встал
Или ты уверяешь что КРАМRTOS ты за 2 недели напишешь???[/uquote]
Речь не шла о вытесняющей РТОС универсального применения. Речь шла о вытесняющей РТОС, задачей которой является управление задачами, среди которых имеются блокирующие и синхронизация их доступа к критическим секциям кода, данным и ресурсам.
Вопросы отладки и мониторинга меня не интересуют. Они важны для тех, кто пользуется РТОС как "черным ящиком".
Про время необходимое для этого я ни слова не говорил. 2 недели ты высосал из своего заскорузлого пальца.
[uquote="igorg1",url="/forum/viewtopic.php?p=4798431#p4798431"]соскочил с темы что я не могу в отладке при наличии ОТЛАДЧИКА заморозить НУЖНУЮ мне периферию, а также через JTAG передавать что мне надо.[/uquote]
Ты очередной раз соврал. Речь не шла о невозможности морозить периферию вообще. Это элементарно делается в настройках дебаггера. Речь шла о невозможности морозить ШИМ из-за необходимости наблюдать за разверткой массива синуса этим самым дебаггером. Нельзя наблюдать за тем, чего нет.
[uquote="igorg1",url="/forum/viewtopic.php?p=4798431#p4798431"]И если ты такой умный, рассуждая про отсутствие суперЛупа в коде для дсПИКа (да вообще хоть на каком камне), без РТОС - покажи мне хоть один пример кода, где будет отсутствовать while (1)[/uquote]
Ты, Игорёк, как настоящий чурка "я твой дом труба шатал"...
Где я утверждал, что код построенный на суперлупе может не иметь суперлупа?
Явного суперлупа нет только в main() вытесняющей РТОС.
Кстати, с кооперативной РТОС все совсем не так. Она имеется даже для PIC10 c 12-битной адресной шиной и без прерываний. Занимает около 10 строк кода.
http://www.pic24.ru/doku.php/en/osa/ref ... tion/intro

[ARV]

main и без РТОС может не иметь супрлупа. доводилось делать девайс, который всегда был в глубоком power-down (в AVR из этого режима один выход - RESET), а в main просто кое-что делал и сохранял состояние в ОЗУ. нормальное решение.

[igorg1]

То: Крам - ты, Крампушек, полный прован в РТОС.
Потому что ты даже концепцию РТОСов не знаешь.
В реализации FREERTOS - суперлуп будет всегда, и планировщик в суперлупе вызывается системной функцией РТОСа вида SYS_TASK()
Зефир построен на другой концепции - на концепции потоков. Поток может жить какое-то время, может жить бесконечно.
Инициализация (создание) и поведение (что они делают), их приоритет и пр. - указывается при создании потока.
Также создаются семафоры и мутексы - что такое - читай в тех. документации Зефира - кардинально отличаются от таких же синонимов во FREERTOS - и им можно назначить какие прерывания они будут обслуживать.
В момент инициализации камня - основной поток инициализирует другие потоки (при наличии) - и если основной поток не нужен - т. е. нет суперлупа - спокойно завершает свою работу, передав управление планировщику, который инициализируется вместе с другими потоками - и планировщик управляет потоками.
Зефир крайне абстрагирован от железа - он наследник Линукса, иными словами - код написанный на Зефире - будет работать на ВСЕХ платах отладочных, которые имеют эту периферию. Достигается это за счет иерахического описания платы (.dts файлы) и иерархического описания железа (аппаратных возможностей) в файлах .dtsi
Поэтому РЕКОМЕНДУЕМЫЙ способ написания приложения на Зефире - взять отладочную плату, более подходящую под решаемую задачу - взять ГОТОВЫЙ пример - что будем использовать - проверить на плате - затем ИЛИ создать свою плату средствами ЗЕФИР - или написать .overlay файл, в котором переназначить выводы, частоту - да всё, что угодно.
Вот на пальцах - тот же SPI сделать не на Зефире - очень просто:) - а на Зефире - задача нетривиальная - надо будет написать клиента, расписать полностью работу клиента, поведение его в работе, во время слипа и пр. - там писанины ой как много.
Плюсы Зефира - код не зависит от используемой платформы и очень компактен.
И не ори про кооперативную РТОС - ты не хуже меня знаешь, что в любой момент времени камень может выполнять только ОДНУ задачу (инструкцию).
Технически на FREERTOS можно сделать кооперативную РТОС - но практической реализации я ни в одном примере не видел.
А твои ссылки на РТС на ПИК10 - попробуй сделай - это просто теория - напиши мне код, чтобы ПИК10 хотя бы моргал на этой инкарнации РТОС 2-мя светодиодами
Дерзай.
Не ори - когда не знаешь.
А я тебе - если ещё раз вянкешь - возьму плату микрочиповскую - которая поддерживает Зефир - это все АРМы 32-х битные (atSAM) и старшие ПИКи - PIC32MZ и выше - и приведу тебе код в main.c - где не будет суперлупа
И сделаю тебе что ты скажешь.
Усёк?

Добавлено after 2 minutes 10 seconds:
[uquote="ARV",url="/forum/viewtopic.php?p=4798533#p4798533"]main и без РТОС может не иметь супрлупа. доводилось делать девайс, который всегда был в глубоком power-down (в AVR из этого режима один выход - RESET), а в main просто кое-что делал и сохранял состояние в ОЗУ. нормальное решение.[/uquote]
А это как???
Инструкции в Си выполняются последовательно.
Делает что-то в main.c - и дальше что????
Гонять по кругу инструкциями goTo?
Зачем?
Если есть суперлуп?

[akl]

[uquote="ARV",url="/forum/viewtopic.php?p=4798533#p4798533"]...в AVR из этого режима один выход - RESET...[/uquote]Уточню. Даже в самом первом камне AT90S1200 выход из POWER DOWN был более гибким.

Спойлер

[КРАМ]

[uquote="igorg1",url="/forum/viewtopic.php?p=4798536#p4798536"]А твои ссылки на РТС на ПИК10 - попробуй сделай - это просто теория - напиши мне код, чтобы ПИК10 хотя бы моргал на этой инкарнации РТОС 2-мя светодиодами[/uquote]
Научись пользоваться сайтами, наконец:
http://www.pic24.ru/doku.php/en/osa/ref ... eds_pic10f

[igorg1]

[uquote="КРАМ",url="/forum/viewtopic.php?p=4798541#p4798541"][uquote="igorg1",url="/forum/viewtopic.php?p=4798536#p4798536"]А твои ссылки на РТС на ПИК10 - попробуй сделай - это просто теория - напиши мне код, чтобы ПИК10 хотя бы моргал на этой инкарнации РТОС 2-мя светодиодами[/uquote]
Научись пользоваться сайтами, наконец:
http://www.pic24.ru/doku.php/en/osa/ref ... eds_pic10f[/uquote]
Да читал я это очень давно.
Ты мне практическую конструкцию сделай с этим бредом - например NCO твой любимый.
Что ты мне ссылками тычешь.
Только идиот будет на Р10 делать РТОС.
И на ПИК18-ПИК24
Ты в жизни никогда не делал РТОС - а я тебе скажу - даже на PIC32MZ FREERTOS тормозит - по сравнению с голым железом - возьми любой проект у микрочипа для PIC32MZ - он будет как правило в 2-х инкарнациях - на РТОС и в голом железе.
И почувствуй разницу.
Дуру иногда надо выключать.

Добавлено after 3 minutes 49 seconds:
Внимательно прочитай что там написано - 12-й битный микроконтроллер:), 7-ми цветный светодиод:)
Вот разверни их архив и погляди - и они честно пишут, что "Function ChangeIntensity() is not a part of RTOS, thus you can to modify it as you wish to make your own intensity changing style." - вопросы ещё есть???

[ARV]

А это как???
Инструкции в Си выполняются последовательно.
Делает что-то в main.c - и дальше что????
Гонять по кругу инструкциями goTo?
Зачем?
Если есть суперлуп?

Ну, как-то так:

Код: Выделить всё

int main(void){
  init_peripherial();
  make_my_job();
  init_sleep_mode(SLEEP_POWER_DOWN);
  sleep_mode();
}

нет ни цикла, ни goto - за ненадобностью.

[veso74]

[uquote="igorg1",url="/forum/viewtopic.php?p=4798544#p4798544"]... мне практическую конструкцию сделай с этим бредом - например NCO твой любимый.[/uquote]
Просто спорите напрасно.

Прошло много времени деятельности с PIC MCU. NCO eсть возможности. Просто все находится внутри PIC-a, из аппаратной часты. Ничего не добавляем, ничего не паяем.

Внизу: генератор для любительского радиомаяка. PIC16F18426, шаг запрошенной перестройки Fout: 1 kHz. Clock: 25 MHz (24999760 Hz). Фото: два шага енкодера -> dF = 1 kHz.
Mожно сделать шаг гораздо меньше Hz.

Код: Выделить всё

// Frequency = (NCO Clock Frequency * Increment Value)/(2^21)
// Increment Value = Frequency * 2^21 / NCO Clock Frequency
// 3550000 Hz -> 297799

NCO в PIC MCU eсть много недостатков. Да, DDS AD9xxx лучше. Но NCO - это внутри MK. Пишешь немного кода с двумя формулами, и он работает. А МК свободен для других занятий. Попробуйте либо программно, либо с таймерX сделать на 3 550 000 Hz шаг 10/100/1000 Hz? (частично использую переводчик)

[ARV]

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

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