UTC 3.3: Контроллер для теслы
эх блин мне бы на производстве платы заказать бы для теселки своей... но возиться и ждать чето ломает...
Sharix, у меня сейчас с ногой плохо, я нифига не ходячий 
Не удержался и собрал одну штучку Протестировал питание - работает.
Сори за качество, фотал абы как
Не удержался и собрал одну штучку
Протестировал питание - работает.Сори за качество, фотал абы как
хилька солидности девайсу таки добавляет. смотрится как мерин на дороге. (даешь что нить аля ролсройс! )
)Немного поописываю, чего я уже сделал. Итак, поднял процессор на плисине. Освоил его ассемблер, кроме мигалки светодиодом, написал программый уарт и spi, научился читать внутреннюю память фпгашки.
Теперь нужно сделать загрузку конфигурации приложения (ну, к примеру, значение опережения фазы) из этой самой флэшки, а потом - ее программирование. Далее будут более прикольные штуки - когда приедут драйвера, нужно будет собрать теслу, запустить ее и протестировать помехоустойчивость этого всего добра.
Заказал драйвера с дигикея. Это будут вот такие 9А драйвера от Clare.
Теперь нужно сделать загрузку конфигурации приложения (ну, к примеру, значение опережения фазы) из этой самой флэшки, а потом - ее программирование. Далее будут более прикольные штуки - когда приедут драйвера, нужно будет собрать теслу, запустить ее и протестировать помехоустойчивость этого всего добра.
Заказал драйвера с дигикея. Это будут вот такие 9А драйвера от Clare.
Провел вечер за отладкой программного UART'а. Он теперь работает. Для процессора, который я использую доступно 1024 инструкции. Еще почти ничего нет, а уже занято 148. Надеюсь, влезу
А вообще, picoblaze - приятная штука, даже не смотря на то, что там стэк отсутствует как класс. Штука мелкая и с хорошей документацией. Набор инструкций тоже замечательный, а вот сам ассемблер (программа, которая компилит ассемблер в машинные слова) как-то не очень. Не умеет нифига. Все приходится в один файл кидать.
Теперь нужно разобраться с обновлением прошивки - как из ISE извлечь бинарник моей проги и как по уарту его записать во флэшку.
А вообще, picoblaze - приятная штука, даже не смотря на то, что там стэк отсутствует как класс. Штука мелкая и с хорошей документацией. Набор инструкций тоже замечательный, а вот сам ассемблер (программа, которая компилит ассемблер в машинные слова) как-то не очень. Не умеет нифига. Все приходится в один файл кидать.
Теперь нужно разобраться с обновлением прошивки - как из ISE извлечь бинарник моей проги и как по уарту его записать во флэшку.
Урряяя, я таки сделал это. Итак, теперь прошивку плисины можно обновлять через интерфейс конфигурирования UTC. Показать особо нечего, кроме скриншота формы обновления.
Обновляльщик передает шифрованный поток, который со стороны плисины расшифровывается. Расшифрованными блоками прошивается флэшка плисины, потом проверяется правильность записи данных и плисина перезагрузается уже на новую прошивку. Работает это все довольно медленно - не хотелось тратить аппаратные средства на это. В итоге, шифрованием занимается бедненький picoblaze. Прошивка обновляется примерно за 3 минуты.
Есть еще одна беда - если прекратить передачу прошивки посреди обновления, то, с большой вероятностью, UTC умрет. Но это принципиальное ограничение и тут никуда не деться.
Обновляльщик передает шифрованный поток, который со стороны плисины расшифровывается. Расшифрованными блоками прошивается флэшка плисины, потом проверяется правильность записи данных и плисина перезагрузается уже на новую прошивку. Работает это все довольно медленно - не хотелось тратить аппаратные средства на это. В итоге, шифрованием занимается бедненький picoblaze. Прошивка обновляется примерно за 3 минуты.
Есть еще одна беда - если прекратить передачу прошивки посреди обновления, то, с большой вероятностью, UTC умрет. Но это принципиальное ограничение и тут никуда не деться.
Есть еще одна беда - если прекратить передачу прошивки посреди обновления, то, с большой вероятностью, UTC умрет.
совсем умрет? и не починить уже ни как?
Ну, не совсем, просто прошивка будет повержена, а контроль целостности прошивки не даст плисине страртануть с поврежденной прошивкой. Починить можно будет, выслав ко мне, я перепрошью на низком уровне и верну обратно. Ну лучше просто не вытаскивать провода во время перепрошивки и вообще не трогать компьютер
Кстате, странно, что тебя это так удивляет, довольно много устройств (телефоны там всякие) умирают, если внезапно прекратить прошивку.
Кстате, странно, что тебя это так удивляет, довольно много устройств (телефоны там всякие) умирают, если внезапно прекратить прошивку.
телефоны и прочие железки умирают не до конца. как выяснилось UTC то же. тогда все ок.
самое сложное позади?
самое сложное позади?
самое сложное позади?
Да не, тут еще много напряженный моментов. Но это - одна из самых главных вещей. Если чего-то пойдет не так, то я смогу поправить прошивку и ты сможешь перешить уже у себя.
мдя. чеж я все ни как в программеры не подамся... и желание есть, и проблем небыло бы... но чето все дургим пока занимаюсь. ато тоже крутил вертел бы
в общем вся надежда на тебя Сергей успешного тебе пыхтения.
в общем вся надежда на тебя Сергей
успешного тебе пыхтения.Сегодня сделал встроенный прерыватель для теслы.
Хотел скринкаст записать, но что-то разобраться с кодеками нормально не могу. Весь вечер на кодеки убил и так нифига нормально и не получилось
Ну да ладно, обойдемся скриншотом.
Итак, прерыватель умеет - генерировать импульсы заданной ширины и частоты, притом умеет еще и ограничивать количество импульсов. К примеру, может сделать 10 импульсов по 30мкс с частотой 1234 Гц. После этого, контроллер будет ждать, когда отключат питание. Это должно быть удобно для отладки - поставил одиночный импульс, посмотрел -если теслу прошило, то ничего серьезно повредиться не успеет. Если хочется, чтобы тесла работала до выдергивания вилки, можно просто оставить в этом поле 0.
Еще много ваял софта для компьютера. К примеру, на скриншоте показана ошибка при валидации параметров. Кроме того, у аппаратуры есть некоторые физические ограничения, к примеру стартовая задержка генерируется с шагом в 100мс. А пользователь может ввести 1234 мс. Поэтому, после потери фокуса, в поле подставляется ближайшее возможное значение.
Ну, и, естественно, есть кнопки "считать параметры" и "записать параметры".
Хотел скринкаст записать, но что-то разобраться с кодеками нормально не могу. Весь вечер на кодеки убил и так нифига нормально и не получилось
Ну да ладно, обойдемся скриншотом.Итак, прерыватель умеет - генерировать импульсы заданной ширины и частоты, притом умеет еще и ограничивать количество импульсов. К примеру, может сделать 10 импульсов по 30мкс с частотой 1234 Гц. После этого, контроллер будет ждать, когда отключат питание. Это должно быть удобно для отладки - поставил одиночный импульс, посмотрел -если теслу прошило, то ничего серьезно повредиться не успеет. Если хочется, чтобы тесла работала до выдергивания вилки, можно просто оставить в этом поле 0.
Еще много ваял софта для компьютера. К примеру, на скриншоте показана ошибка при валидации параметров. Кроме того, у аппаратуры есть некоторые физические ограничения, к примеру стартовая задержка генерируется с шагом в 100мс. А пользователь может ввести 1234 мс. Поэтому, после потери фокуса, в поле подставляется ближайшее возможное значение.
Ну, и, естественно, есть кнопки "считать параметры" и "записать параметры".
а что значит "listen to optical/wired"? это чтоб запустить встроенный интер надо подать импульс с внешнего? это как странновато. или я чего не понял? в общем как будет стартовать встроенный интеруптер, и как вообще стартует контролер? (подозреваю что как и раньше но расписать бы неплохо стартовую последовательность проверок и инициализаций, там жешть от куда то должна грузиться прошивка, читаться параметры и т.д.)
а что значит "listen to optical/wired"?
Если выбрана одна из этих опций, то по умолчанию работает внутренний прерыватель, но если придет сигнал по выбранному каналу (к примеру, от i3), то контроллер перейдет в режим конфигурации.
Сейчас мне кажется, что конфигурация из i3 - не очень то и хорошая идея. Проблема в том, что там однонаправленный канал связи и придется параметры, которые хочется изменить, задавать в абсолютных единицах. Поэтому, я пока оставлю заглушку под конфигурацию с i3, реализовывать ее не буду пока не доберусь до этого в прерывателе. Поэтому, опции равноценные. Могу просто убрать, если мешают.
и как вообще стартует контролер?
Сейчас примерно так:
- Конфигурируется ПЛИСина (в процессе проверяется целостность прошивки плисины, если она повреждена, то плисина не стартует)
- Ожидается высокий уровень UVLO (при падении UVLO, контроллер синхронно отрубается)
- Контроллер мигает всеми светодиодами в знак того, что появилось питание (это занимает 1200мс)
- Контроллер определяет - подключен ли компьютер. Если подключен, то контроллер в режим настроек и остается там до отключения питания.
- Происходит загрузка пользовательских настроек. В настройках есть несколько контрольных сумм, если они не совпадают, контроллер переходит в режим настроек
- Выполняется стартовая задержка, задаваемая пользователем (во время задержки, контроллер мигает светодиодом питания - мол питание есть, но тесла еще не работает).
- Включается реле
- Из настроек определяется активный прерыватель.
- Подается сигнал разрешения работы теслы
- Если прерыватель внешний, то ожидается, пока появится активный сигнал. Если у сигнала определенная форма, то включается режим настройки с прерывателя, после этого - перезагрузка.
- Если используется внутренний прерыватель с ограничением по количеству циклов, то после завершения, контроллер мигает двумя светодиодами до отключения питания.
Как-то так
кажись все верно, и все продумано.
насчет абсолютных величин с i3 - да и хрен бы. главное чтоб на ходу работало. а там пусть i3 при нажатии на кнопочку +/- считает от вбитого в него минимума и до вбитого в него же максимума и передает расчитанные значения в UTC. а то что длина стримера будет регулироваться не с последнего значения а с нуля - не проблема. да и потом если UTC не может передать в i3 что было в последний раз то что мешает i3 запоминать самому чего на нем крутили? а если у кого будет десяток тесел на один i3 - или наоборот - тот сам виноват и опять же в память i3 можно вбивать пресеты для разных тесел.
насчет абсолютных величин с i3 - да и хрен бы. главное чтоб на ходу работало. а там пусть i3 при нажатии на кнопочку +/- считает от вбитого в него минимума и до вбитого в него же максимума и передает расчитанные значения в UTC. а то что длина стримера будет регулироваться не с последнего значения а с нуля - не проблема. да и потом если UTC не может передать в i3 что было в последний раз то что мешает i3 запоминать самому чего на нем крутили? а если у кого будет десяток тесел на один i3 - или наоборот - тот сам виноват
и опять же в память i3 можно вбивать пресеты для разных тесел.Вроде, запрогал одну из самых геморройных частей. Вход внешнего прерывателя с ограничителем ширины импульсов и частоты. Так как тратить аппаратные ресурсы на это не хотелось, делал программно. В итоге, получились довольно не точные ограничители. К примеру, погрешность ограничителя ширины импульсов - 500нс. С другой стороны, это не особо то и страшно. Если кто и будет юзать эту фишку, вряд ли, ограничитель будет устанавливаться совсем уж впритык.
Там-же и логика обнаружения управляющей команды от UTC. Правда я все больше и больше думаю выпилить нафиг эту возможность - слишком уж много геммора и ограничений с ней связанно. С вероятностью, 80% выпилю. Да и непонятных галочек станет меньше. А такая идея была
.
На очереди ограничитель тока. Его настройки я уже успел нарисовать.
Там-же и логика обнаружения управляющей команды от UTC. Правда я все больше и больше думаю выпилить нафиг эту возможность - слишком уж много геммора и ограничений с ней связанно. С вероятностью, 80% выпилю. Да и непонятных галочек станет меньше. А такая идея была
.На очереди ограничитель тока. Его настройки я уже успел нарисовать.
ам-же и логика обнаружения управляющей команды от UTC.
это че за команда такая? помнится был разговор про управляющую команду с i3 для исключения ложных стартов.
шо есть галка "use interrupter control"?
ну и последнее: Actual - это текущие установки?
Это - команда, которая переключает контроллер в режим управления от UTC. По идее, после переключения, прерыватель мог посылать управляющие команды - в том числе и конфигурационные, и для защиты от ложных запусков. Проблема в том, как передавать эту управляющую последовательность.
В начале я думал вот так - передаем лог 1 в течении определенного, и довольно короткого, времени, к примеру, 3мкс. Контроллер определяет, что пачка слишком короткая и ждет передачи байта. Тут сразу две проблемы - даже этот короткий импульс запустит теслу, и обычный прерыватель неумышленно может передавать такие короткие импульсы.
Второй вариант - сделать подобие аппаратного уарта и слушать вход прерывателя. Как только принятый байт совпадет с неким ключевым, переходить в режим конфигурации от прерывателя. Тут тоже есть проблемы - тратится аппаратура, тесла запускается даже несколько раз, хоть и с короткой накачкой.
Второй вариант станет работоспособным, если сделать так, что тесла не будет запускаться, если длинна импульса меньше определенного значения. К примеру, 5мкс.
Ну, и кроме всего остального - таблы с односторонней связью не позволяют нормально конфигурировать теслу.
Это задумывалось как переключатель - будет ли работать управление от прерывателя. Если галка стоит, то контроллер слушает прерыватель на предмет комманды и присутствует ограничение в 5мкс до старта. Если нет, то контроллер не слушчает, но и ограничения нет.
Сейчас это все слишком сложно становится и нуно бы решиться - сделать прослушку прерывателя постоянно работающией с ограничением минимальной длительности, или без ограничения, но и без фишек с прерывателем.
В поля вы вводите желаемые значения, а в поле actual прога говорит, что получится сделать у железа по факту.
К примеру, хочешь частоту 1234.13213Гц. Железо такое не может, оно предложит 1234.45Гц, к примеру.
В начале я думал вот так - передаем лог 1 в течении определенного, и довольно короткого, времени, к примеру, 3мкс. Контроллер определяет, что пачка слишком короткая и ждет передачи байта. Тут сразу две проблемы - даже этот короткий импульс запустит теслу, и обычный прерыватель неумышленно может передавать такие короткие импульсы.
Второй вариант - сделать подобие аппаратного уарта и слушать вход прерывателя. Как только принятый байт совпадет с неким ключевым, переходить в режим конфигурации от прерывателя. Тут тоже есть проблемы - тратится аппаратура, тесла запускается даже несколько раз, хоть и с короткой накачкой.
Второй вариант станет работоспособным, если сделать так, что тесла не будет запускаться, если длинна импульса меньше определенного значения. К примеру, 5мкс.
Ну, и кроме всего остального - таблы с односторонней связью не позволяют нормально конфигурировать теслу.
шо есть галка "use interrupter control"? это оно и есть?
Это задумывалось как переключатель - будет ли работать управление от прерывателя. Если галка стоит, то контроллер слушает прерыватель на предмет комманды и присутствует ограничение в 5мкс до старта. Если нет, то контроллер не слушчает, но и ограничения нет.
Сейчас это все слишком сложно становится и нуно бы решиться - сделать прослушку прерывателя постоянно работающией с ограничением минимальной длительности, или без ограничения, но и без фишек с прерывателем.
ну и последнее: Actual - это текущие установки?
В поля вы вводите желаемые значения, а в поле actual прога говорит, что получится сделать у железа по факту.
К примеру, хочешь частоту 1234.13213Гц. Железо такое не может, оно предложит 1234.45Гц, к примеру.
если я правильно понимаю то можно было бы сделать так:
с компа задается режим прослушки входа прерывателя:
0. "прерыватель UTC" (вход не слушаем вообще и работаем от прерывателя в UTC)
1. "проводной прерыватель" (все тупо: сигнал есть - прет накачка, сигнала нет - ждем сигнала).
2. "оптический прерыватель" (аналогично).
3. "прерыватель i3" и тут уже все веселье можно закрутить.
логика работы примерно следующая:
i3 просто так ни чего не передает. любой посылке предшествует код с описанием что это такое будет. т.е. UTC слушает вход, как только на него приходит сигнал UTC расценивает его как код определяющий что же сейчас будет передано с i3.
1. если i3 сказал что сейчас будет команда на запуск теслы - соответственно UTC ждет высокий уровень и по нему включает накачку. как только высокий уровень кончился - накачка обрубается и UTC ждет следующий код. если опять приходит код запуска накачки то все повторяется. сдается мне что пару лишних байтов переслать перед каждой накачкой успеется.
2. если с i3 приходит код соответствующий режиму конфигурации - соответственно UTC в этот режим переходит и далее уже работает по протоколу конфигурации. когда на i3 нажимается кнопочка "сохранение конфигурации" (ну это я образно говорю) приходит код означающий окончание конфигурации и UTC сохраняет конфигурацию и переходит в режим ожидания следующего кода.
3. если на вход UTC приходит не пойми что - расцениваем это как глюк баг или тупо отвалившийся оптокабель и ждем нормального кода.
таким макаром ложных запусков не будет, если только не получится что с i3 придет код запуска, и тут связь оборвется, а UTC будет стоять и ждать пол года и когда на него любая кака придеть он отработает ее как старт накачки. но на этот счет надо просто сделать контроль "срока годности" кодового слова. по истечении которого UTC отменяет все что было начато (например конфигурацию) и будет ждать нового нормального кода.
вот. а про управляющую команду от UTC я так и не понял нифига.
с компа задается режим прослушки входа прерывателя:
0. "прерыватель UTC" (вход не слушаем вообще и работаем от прерывателя в UTC)
1. "проводной прерыватель" (все тупо: сигнал есть - прет накачка, сигнала нет - ждем сигнала).
2. "оптический прерыватель" (аналогично).
3. "прерыватель i3" и тут уже все веселье можно закрутить.
логика работы примерно следующая:
i3 просто так ни чего не передает. любой посылке предшествует код с описанием что это такое будет. т.е. UTC слушает вход, как только на него приходит сигнал UTC расценивает его как код определяющий что же сейчас будет передано с i3.
1. если i3 сказал что сейчас будет команда на запуск теслы - соответственно UTC ждет высокий уровень и по нему включает накачку. как только высокий уровень кончился - накачка обрубается и UTC ждет следующий код. если опять приходит код запуска накачки то все повторяется. сдается мне что пару лишних байтов переслать перед каждой накачкой успеется.
2. если с i3 приходит код соответствующий режиму конфигурации - соответственно UTC в этот режим переходит и далее уже работает по протоколу конфигурации. когда на i3 нажимается кнопочка "сохранение конфигурации" (ну это я образно говорю) приходит код означающий окончание конфигурации и UTC сохраняет конфигурацию и переходит в режим ожидания следующего кода.
3. если на вход UTC приходит не пойми что - расцениваем это как глюк баг или тупо отвалившийся оптокабель и ждем нормального кода.
таким макаром ложных запусков не будет, если только не получится что с i3 придет код запуска, и тут связь оборвется, а UTC будет стоять и ждать пол года и когда на него любая кака придеть он отработает ее как старт накачки. но на этот счет надо просто сделать контроль "срока годности" кодового слова. по истечении которого UTC отменяет все что было начато (например конфигурацию) и будет ждать нового нормального кода.
вот. а про управляющую команду от UTC я так и не понял нифига.
Так тоже не получится. В режиме полифонии, i3 слишком много всего шлет, кроме того, пачки которые он шлет в этом режиме асинхронны, то есть, расстояние между ними может быть самым произвольным. При этом, кстати, у UTC должна быть отключено ограничение по частоте. Во многих других режимах, i3 шлет сигналы прямо с таймеров, а, значит послать специальные посылки, не получится. Сильно переделывать i3 не хочется.
Остается два варианта - ограничить минимальную длительность импульса или вырезать все специфичные для i3 штуки. Я над этим уже три дня думаю, пока ничего более разумного не придумал.
Вот, как, я думаю, можно организовать переход UTC в режим управления от i3:
interrupter_in - вход прерывателя, а interrupter_sync - сигнал интерраптера, синхронизированный с клоком плисины. Сигнал сэмплируется по возрастающему фронту sample.
после возрастающего фронта, контроллер ждет 1500нс, смотрит, что на ножке. если ноль, то дальше, если не ноль, то это - сигнал и нужно включать теслу.
дальше контроллер ждет еще 1000нс, смотрит что на ножке, если 1, то дальше.
Два события 0->1 гарантируют, что это не выход обычного прерывателя. Ведь прерывателя с частотой в 500кГц быть не может.
Я там еще один сэмпл нарисовал, но этого - достаточно, дальше можно по УАРТу передавать байты.
Если приходит обычный сигнал, который больше 1мкс, то этак микросекунда добавляется после отключения прерывателя.
А теперь подводные камни. Представим, что тесла не определила или не правильно определила старт такой посылки. Прерыватель дальше начнет слать байты, которые будут запускать теслу (от ведь не знает - получила ли их тесла). Потенциально - фатально.
Поэтому у меня есть еще одна причина вырезать управления с UTC.
Остается два варианта - ограничить минимальную длительность импульса или вырезать все специфичные для i3 штуки. Я над этим уже три дня думаю, пока ничего более разумного не придумал.
Вот, как, я думаю, можно организовать переход UTC в режим управления от i3:
- i3_detection.gif (10.78 КБ) 17986 просмотров
interrupter_in - вход прерывателя, а interrupter_sync - сигнал интерраптера, синхронизированный с клоком плисины. Сигнал сэмплируется по возрастающему фронту sample.
после возрастающего фронта, контроллер ждет 1500нс, смотрит, что на ножке. если ноль, то дальше, если не ноль, то это - сигнал и нужно включать теслу.
дальше контроллер ждет еще 1000нс, смотрит что на ножке, если 1, то дальше.
Два события 0->1 гарантируют, что это не выход обычного прерывателя. Ведь прерывателя с частотой в 500кГц быть не может.
Я там еще один сэмпл нарисовал, но этого - достаточно, дальше можно по УАРТу передавать байты.
Если приходит обычный сигнал, который больше 1мкс, то этак микросекунда добавляется после отключения прерывателя.
А теперь подводные камни. Представим, что тесла не определила или не правильно определила старт такой посылки. Прерыватель дальше начнет слать байты, которые будут запускать теслу (от ведь не знает - получила ли их тесла). Потенциально - фатально.
Поэтому у меня есть еще одна причина вырезать управления с UTC.
Итого, попробую подвести итоги.
За управление с UTC:
1. Это должно получится удобно. Не очень хочется таскать теслу к компьютеру.
2. Это должно получиться более безопасно, можно блокировать и разблокировать теслу.
Против:
1. Будет присутствовать минимальная не воспроизводимая теслой длительность.
2. Есть опасность взрыва теслы из-за не распознанной стартовой последовательности.
3. Нет двусторонней связи, числа придется вводить в абсолютных единицах.
4. Дофига кодить
Нейтрально:
1. Старт-стоп не факт, что нужен - тесла и так защищёна ограничениями по частоте/длительности и ограничением по току.
2. Можно сделать проводок от i3, который будет эмулировать подключение к компьютеру. Правда, для этого придется иметь отдельный проводок.
Как не печально, хочется таки вырезать управление от UTC Может у вас еще будут аргументы за/против?
За управление с UTC:
1. Это должно получится удобно. Не очень хочется таскать теслу к компьютеру.
2. Это должно получиться более безопасно, можно блокировать и разблокировать теслу.
Против:
1. Будет присутствовать минимальная не воспроизводимая теслой длительность.
2. Есть опасность взрыва теслы из-за не распознанной стартовой последовательности.
3. Нет двусторонней связи, числа придется вводить в абсолютных единицах.
4. Дофига кодить
Нейтрально:
1. Старт-стоп не факт, что нужен - тесла и так защищёна ограничениями по частоте/длительности и ограничением по току.
2. Можно сделать проводок от i3, который будет эмулировать подключение к компьютеру. Правда, для этого придется иметь отдельный проводок.
Как не печально, хочется таки вырезать управление от UTC
Может у вас еще будут аргументы за/против?дело хозяйское. если клоняешься к варианту выпилить нах - значит так и надо поступить.
тем более это первая версия нового UTC, сразу все продумать и просчитать сложно. надо сделать образец, обкатать его, поюзать основательно, сформировать предложения и тогда уже городить огороды. тем более если вся модернизация будет в софте - вообще нет проблем. (за исключением конечно той что кодить до жопы много тогда ставь заглушки куда можно и двигай дальше).
и еще - если UART-USB конвертер будет подключен постоянно и на морде теслени будет стоять USB разъемчег, то и нет проблем подтащить ноут к тесле, ткнуть шнурок, передернуть питание и вбить чего хотел. тем более что там и надо то будет только в процессе отладки переставлять ограничение тока да и то не слишком много раз, а остальные настройки вообще не требуется оперативно изменять.
тем более это первая версия нового UTC, сразу все продумать и просчитать сложно. надо сделать образец, обкатать его, поюзать основательно, сформировать предложения и тогда уже городить огороды. тем более если вся модернизация будет в софте - вообще нет проблем. (за исключением конечно той что кодить до жопы много
тогда ставь заглушки куда можно и двигай дальше).и еще - если UART-USB конвертер будет подключен постоянно и на морде теслени будет стоять USB разъемчег, то и нет проблем подтащить ноут к тесле, ткнуть шнурок, передернуть питание и вбить чего хотел. тем более что там и надо то будет только в процессе отладки переставлять ограничение тока да и то не слишком много раз, а остальные настройки вообще не требуется оперативно изменять.
Вообщем, выпилил я функциональность управления от UTC. Слишком много геммороя, а проблема, действительно, чисто софтверная. Вчера поговорил в шарящим в цифровом дизайне человеком, нашли пару потенциальных метастабильностей в коде. Поправил. Сейчас получше оттестирую ограничители длинны импульса и частоты, добавлю возможность включать их раздельно и перейду к детектору превышения тока.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 52 гостя