EdgeAligned

На схеме указан PIC16LF648, а вы симулируете PIC16F627. Несмотря на то, что они довольно похожи, но всё-таки, они чем-то да различаются. За давностью лет, я не помню, чем именно.

Да не намного там сложнее в автомобилях. Датчика положения коленвала более чем достаточно для определения угла поворота коленвала. Может еще добавляться датчик положения распредвала, но частота его импульсов иная.

А почему именно два датчика угла поворота коленвала? Так то в автомобилях он завсегда один был.

F3 ковырял на отладочной плате Nucleo. До использования в проектах не дошло. А ведь еще есть линейки с F2xx или F101. Номенклатура микроконтроллеров у ST весьма широкая. А на Алиэкспрессе продается то, что берется покупателями, и то, что можно по-быстрому сделать. F103 так до сих пор пользуется большим спросом. А F303CC - ближайший pin-to-pin конкурент F103C8, большого распространения не получил, хотя имеет более мощные характеристики.

Где логика, где логика... И этот господин еще утверждает, что оператор switch, по его мнению, говнокод.

Збасиба, мануал читать я умею 🙂 Я спрашивал, че за ересь в целом там написана 🙂

А, да, это от настроек компилятора зависит. Стандарт не задает однозначности. В принципе, переопределения uint32_t для того и придуманы, чтобы была однозначность. Ладно, но static тогда зачем? Да и сама переменная тоже как бы не нужна. В принципе, я вот сколько не пытался понять этот код, всё время путался в закомменченных строках. Ну и я как бы не понимаю назначение этой функции, названной modbus_usart_5(). Вообще, осмысленные названия функций для того и придуманы, чтобы отражать назначение и выполняемые действия. Небрежность в оформлении и форматировании кода затрудняет его просмотр и отладку.

Есть слова типа разгр/е/б/ать и употре/б/л/я/ть, у которых вторая половина слова - чисто матюковая. -------------------- Если честно, в том коде написана какая-то дичь. Серьезно. Сколько бы не пытался разобрать код, всё сваливается к фейс-палму с тяжким вздохом. static long unsigned int usart_sr_my=0; что это? Почему в размерности long int, то есть 64 бита? Почему 64 бита, если USART->SR имеет разрядность 32 бита, а регистр DR вообще содержит только 9 значащих бит? Ладно, а почему переменная static? Её содержимое - что, нужно сохранять при следующем входе в эту функцию? Но зачем, если в нее просто читается заново срдержимое регистра USART->SR usart_sr_my=UART5->ISR; Нет, ну серьезно, ЗАЧЕМ static? Использование long int вероятно говорит о том, что сей код писал тот, кто еще недавно пересел с 8-битных МК. И такие вопросы - практически в каждой строчке. Там всё переписывать надо с нуля. Серьезно. Я совершенно не понимаю, ЗАЧЕМ туда воткнуто ВСЁ ВОТ ЭТО? Что это вообще такое? Не понимаю, чесслово. Может вы, firstvald, как автор расскажете, что это там написано и для чего? if((usart_sr_my&USART_ISR_TXE)!=0){//ïî ïåðåäà÷å //äàííûå ïåðåäàëèñü â ñäâèãîâûé ðåãèñòð //UART5->ISR&=~USART_SR_TC; // UART5->ICR|=USART_ICR_TCCF ;//ñáðîñèì ôëàã UART5->RQR|=USART_RQR_TXFRQ ;//ñáðîñèì USART_SR_TXE // tx_flag=1; __nop(); } Это - что такое? Что за ересь такая? Кто знает, что здесь написано? Объясните, плиз, что тут? Кодировка, кстати, обычная широкораспространенная Win CP1251, ничего особого.

У нас было "А кто такой Вуглускр?" 🙂

Ладно, так и быть, показываю, как можно обходиться без вставки описания битов в рабочий текст: Так же, запись usart_sr_my&USART_ISR_TXE обычно принято писать с пробелами: usart_sr_my & USART_ISR_TXE дабы визуально был заметнее оператор и понятнее было, что там именно операция, а не набор букв. Небрежность в оформлении создает общее говнопредставление. В общем, в своем говнокоде, будьте любезны, разбирайтесь уж сами 🙂

Тест экономит место, поскольку они уже есть в заголовочном файле, а нормальная IDE при наведении мышки показывает значения битовых масок, и при щелчке можно перейти в заголовочник прямо к описанию Поэтому, даже если программист убежал в другую контору, описания битов никуда не денутся, они остаются в заголовочнике и легко просматриваются. И здесь у вас - классический пример индусского кода. И проще послать подальше, чем реально разгрeбать портянки в попытке найти ошибку PS. Блин, я раз пять переписывал этот текст, и не мог понять, где именно "запрещенное слово" в тексте. А оказалось, что приличное слово "разгр/е/бать" считается тут неприличным 🙂

Чтобы менять частоту, там есть скриптовый вид генератора. В вашем этом SimulIDE изменение частоты реализуется не самим генератором, а программой на втором МК. Ну и вот навряд ли SimulIDE будет точнее Протеуса. Уж не знаю, кто там так говорит. Но лично я в те времена редко встречал, чтобы отсимулированная в Протеусе прога не работала в железе. По крайней мере, такой простой случай. Поэтому, повторюсь еще раз - проверяйте осциллографом сигналы на входах и выходах в железе, и пересматривайте свою программу микроконтроллера. Лично я не брал в руки PIC16 уже лет 10, а на ассемблере для него не писал и того больше. Попробуйте упростить программу, убрав расчет фазового смещения и оставив переключение выхода в момент захвата таймера, чтобы проверить именно работу таймера.

Просто я раньше с PIC16 работал в Протеусе, и он весьма точно симулировал работу микроконтроллера. Двухканальный противофазный сигнал? Такой? или такой? если да, тогда вставайте, аплодируйте 🙂 Под входным каскадом я подразумеваю оптопары развязки. Соответственно, осциллографом желательно проверить, что на вход МК приходит сигнал заданного диапазона уровней, незашумленный ложными импульсами.

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

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

Дааа, говнокод конечно знатный, да еще и почему-то включены закомменченные описания регистров/битов. И почему половина кода закомментирована вообще? Еще и комменты на каком-то пуштунском языке. В СПб на каком языке говорят то? Ладно там "поребрик/бордюр", но это... if(spd==3) и тд обычно записывается с помощью switch(spd) { case 1: break; case 2: break; } Впрочем, дануевона, разбирать сиё творение. Мутотень и говнокод. Особенно еще с таким форматирвоанием.

Ох, мать... А с какой стороны это смотреть?

Технически это возможно, если написать РАЗНЫЕ функции генерации, и желательно без циклов. То есть, где нужно быстро дергать ногой, там напрямую импульсы без циклов и условий. А там, где процессорного времени будет достаточно, там можно и циклы, и условия перехода. Только все это нужно проверять и подгонять. Вообще, следует выбрать другой вариант решения, а не натягивать совв на глобус.

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

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

Зря, очень зря. Без оптимизации используется наиболее простейший алгоритм построения, с минимальным набором инструкций и РОН. Включение оптимизации ускоряет генерируемый код в 2-3 раза. А никто и не гарантирует, что NOP-ы будут равномерно проходить и исполняться. Они вообще могут выкидываться из исполнения, поскольку NOP применяется так же и для выравнивания инструкций по границам 4-х байт

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

Два ШД и даже больше на одну ось - очень даже может использоваться при больших размерах платформы для исключения её перекосов. В моем принтере на Z-оси тоже два ШД, соединенных ремнем на верхнем конце винтовых валов. В механике "дргыгостола" может быть два ШД на Y-оси при широкой платформе. Угловой энкодер можно ставить там, где есть риск пропуска шагов. Некоторые драйверы TMC могут обнаруживать сам факт пропуска шагов, но они не скажут, на сколько именно шагов случился пропуск. При печати пропуск шагов возможен при резких разгонах и торможениях X и Y осей, когда принтер работает на пределе скоростных возможностей.

А массив указателей на ф-ции - разве не вариант "вычисляемого перехода"? И я чет не понял, зачем столько NOP-ов в таблице? Они ж ничем не отличаются. Это чето похоже на индусский код.

Ну а я о чем говорил, повторял раз пять наверно, но ничерта, никто даже, черт подери, внимания не обратил! Старших - надо слушать, хоть иногда.