Вспомнил какая была проблема с ATtiny13a в Proteus:
Не работает АЦП в непрерывном режиме (флаг ADLAR если не изменяет память, могу ошибаться).
То есть после выполнения первого преобразования АЦП, значение не изменяется пока не запустишь явное преобразование (ADEN). Баг не страшный, но неприятный.
После пары дней мытарств, нашел описание проблемы у буржуев.
Я до железа добираюсь только после полноценных тестов в эмуляции, все фантазии сначала воплощаю виртуально, очень помогает при разработке.
Добавил к статье ссылку на библиотеку LCD, с моими «художествами», символы из которой представлены в демо-ролике.
Её необходимо скопировать с заменой в папку с протеусом:
«C:\Program Files (x86)\Labcenter Electronics\Proteus 8 Professional\MODELS\»
или где он у Вас установлен, только сохраните оригинал!
Библиотека работает с Proteus 8.3 sp2, с младшей ревизией возможны проблемы.
Успехов в разработках! :)
И еще, возможны проблемы при эмуляции на некоторых микроконтроллерах, в виде неправильно работающих узлов периферии, пусть это Вас не останавливает!
Это понятно, если реализовать таким способом, то для моей поставленной цели это сразу съест память тиньки, в моём случае, используется 1 байт RAM (без учета стека, которого при максимальной глубине вызовов, насколько помню, использовалось 8 байт).
В STM с этим проще, а значит C++ предоставляет все неоспоримые удобства и гибкость.
Кстати говоря, спасибо за Ваш интерес, специально для Вас открою тайну, о которой я забыл написать в статье :)
Эта функция использует одну аппаратную фичу атмела, которой нет у пиков, поэтому присмотритесь к ней внимательно ;)
Подсказка: присмотритесь как происходит вывод в порт.
Жду Ваши комментарии :)
Здесь все просто:
Взгляните на видео с демонстрацией. Там видно, что когда проскакивает сигнал защелки (канал B осциллографа), иногда на линии данных (канал С осциллографа) проскакивает последний бит (девятый). Так вот, если его видно на осциллограмме, значит это ноль, в противном случае — единица. Этот бит съедается дисплеем в момент чтения линии данных — параллельно с данными из сдвигового регистра. Это чтение происходит в тот самый момент, когда дисплей получает сигнал «E», или Latch — сдвигового регистра. То есть схема такая:
Дисплей читает «E» (сигнал enable read), в этот момент он считывает данные и сигнал RS, а я ему подсовываю на эту линию нужный сигнал параллельно с выдачей защелки.
Надеюсь понятно объяснил. Взгляните на ассемблерный код функции вывода (уменьшенный скрин кликабелен), там есть проверка _RS, после которой переход на выдачу защелки, либо на выдачу защелки и опускание линии. Так вот это оно.
Digispark я не прошиваю, прошивает мой друг, из патченой среды ардуино.
Я использую более суровые методы :)
Вроде такого, перешитого в про-версию, и припаянным ICSP разъемом (только разъем сделал как в стандартном программаторе — 10-ти пиновый, который полностью закрыл отверстие заглушки).
Код — скриншотами, для компактности отображения, ведь это не весь код, а только основные, относящиеся к делу касты.
Из-за чего-то (а может это мои кривые руки) при создании статьи, не заработал кат, куда я хотел сделать вставки чтобы не перегружать текст. После чего решил сделать как в прошлых статьях (в которых видимо по этой же причине сделал так).
Здесь, мне видится отображение более лаконичным, ввиду единого стиля студии и протеуса.
Считайте это моей фичей :)
Желающие «копипастить» получили исходник целиком.
Насколько я понял автора, говоря про узлы периферии, он имел ввиду именно конкретные минималистические проекты, которые предназначены для изучения работы конкретных узлов периферии.
Например: работа с таймером, UART, PWM и тп, но все в отдельных проектах. А уже после приступать к более высоко-уровневым и сложным проектам.
Лично я, почти так же поступил когда-то:
Проанализировал свои идеи и разбил на составляющие узлы (механизмы), из чего понял какие мне нужны технологии периферии. Но я уже владел и Си, и Ассемблером.
А к словам автора, я бы добавил механизмы виртуализации разработок, как например Proteus.
Многие его ругают, но ИМХО это от недостатка знаний. Меня он пока не подводил.
Ведь для таких экспериментов и паять уметь не нужно (для начала конечно), а параллельно с этим изучить и уроки пайки.
И тогда успех будет сто процентным.
Не понял какая строка раскомментирована, та что с задержкой для тестов?
Частота слишком высокая, попробуйте испытать в «протеусе», с картинкой на осцилографе.
Не уверен что в ардуинке заведется, впрочем не проверял.
(битовое представление — 00000000 RRRRRRRR GGGGGGGG BBBBBBBB)...
получаем 16к на буфер.
На деле, WS2812B имеет такой порядок бит: GGGGGGGG RRRRRRRR BBBBBBBB,
где будет занято 12к на буфер.
Другое дело — совсем не вижу смысла использовать буфер для таких примитивных целей, даже для СМУ, здесь можно реализовать любые последовательности используя 30-60 байт.
Вот если буфер заполнять с компьютера (от простейшего управления последовательностью, до полноценного потока), тогда в нем действительно есть необходимость.
Впрочем, идея хороша уже тем что это STM32, а по поводу временных задержек в реализациях которые уже были — все проще: у Attiny нет DMA.
Инвертирование поля можно рассматривать для пары катушек, а не для одной, тогда смещение сердечника в следующую катушку будет приводить к выталкиванию первой катушкой во вторую, но проблема в том, что этот процесс тоже нужно своевременно начать, и не менее своевременно закончить для достижения эффекта.
А по поводу датчиков, они необходимы для возможности корректировки задержек и процесса самообучения:
в EEPROM хранятся некие значения задержек для каждой из катушек, и некие значения дельта смещений задержек от предыдущего выстрела, программа корректирует считанную задержку новой дельтой и считает время излета.
Если таковое окажется успешнее предыдущего, происходит запись новой задержки и текущей дельты в EEPROM.
Новую дельту можно выбирать либо относительно предыдущей, либо совсем случайно, и в случае снижения показателей скорострельности — запись данных не производить. Таким образом пушка может самостоятельно повышать эффективность стрельбы. Короче целая область для фантазии.
Боюсь Вас расстроить, но в своих проектах я не вижу никакой другой возможности реализации сложно-связанных структур без указателей, потому как эти самые структуры никаким стандартам не известны. А уж с надежностью Вы совсем палку перегнули, и если у Вас, конкретно, дружба с забывчивостью, то это никаким образом не говорит о том, что у большинства программистов такие же патологии. которые в конечном итоге отражаются на качестве ПО.
А по-факту: следуя Вашей логике, Ассемблер — тем более нужно искоренить как «адское зло», потому что на нем очень трудно писать, ввиду сложности работы с адресами, и прочей «сатанинской сути».
Что уж говорить про машинный код, на котором, смею Вас заверить, тоже пишут, тоже люди, как бы странно Вам это не показалось.
Ваш товарищ еще больше удивился бы, если перед RAR-ом применил RLE (желательно эвристический).
Насколько помню, это давало степень сжатия выше JPG, без потери избыточности (в цвете).
… но тебе зачем-то понадобилось раздувать кашу на ровном месте...
Так выше же сказано зачем: «популизм»
А Вы не уподобляйтесь ему, не станет он отвечать на Ваши вопросы, он фанатик, которые нужны в любом деле, в нужном количестве.
Не работает АЦП в непрерывном режиме (флаг ADLAR если не изменяет память, могу ошибаться).
То есть после выполнения первого преобразования АЦП, значение не изменяется пока не запустишь явное преобразование (ADEN). Баг не страшный, но неприятный.
После пары дней мытарств, нашел описание проблемы у буржуев.
Добавил к статье ссылку на библиотеку LCD, с моими «художествами», символы из которой представлены в демо-ролике.
Её необходимо скопировать с заменой в папку с протеусом:
«C:\Program Files (x86)\Labcenter Electronics\Proteus 8 Professional\MODELS\»
или где он у Вас установлен, только сохраните оригинал!
Библиотека работает с Proteus 8.3 sp2, с младшей ревизией возможны проблемы.
Успехов в разработках! :)
И еще, возможны проблемы при эмуляции на некоторых микроконтроллерах, в виде неправильно работающих узлов периферии, пусть это Вас не останавливает!
В STM с этим проще, а значит C++ предоставляет все неоспоримые удобства и гибкость.
Эта функция использует одну аппаратную фичу атмела, которой нет у пиков, поэтому присмотритесь к ней внимательно ;)
Подсказка: присмотритесь как происходит вывод в порт.
Жду Ваши комментарии :)
Взгляните на видео с демонстрацией. Там видно, что когда проскакивает сигнал защелки (канал B осциллографа), иногда на линии данных (канал С осциллографа) проскакивает последний бит (девятый). Так вот, если его видно на осциллограмме, значит это ноль, в противном случае — единица. Этот бит съедается дисплеем в момент чтения линии данных — параллельно с данными из сдвигового регистра. Это чтение происходит в тот самый момент, когда дисплей получает сигнал «E», или Latch — сдвигового регистра. То есть схема такая:
Дисплей читает «E» (сигнал enable read), в этот момент он считывает данные и сигнал RS, а я ему подсовываю на эту линию нужный сигнал параллельно с выдачей защелки.
Надеюсь понятно объяснил. Взгляните на ассемблерный код функции вывода (уменьшенный скрин кликабелен), там есть проверка _RS, после которой переход на выдачу защелки, либо на выдачу защелки и опускание линии. Так вот это оно.
Я использую более суровые методы :)
Вроде такого, перешитого в про-версию, и припаянным ICSP разъемом (только разъем сделал как в стандартном программаторе — 10-ти пиновый, который полностью закрыл отверстие заглушки).
Из-за чего-то (а может это мои кривые руки) при создании статьи, не заработал кат, куда я хотел сделать вставки чтобы не перегружать текст. После чего решил сделать как в прошлых статьях (в которых видимо по этой же причине сделал так).
Здесь, мне видится отображение более лаконичным, ввиду единого стиля студии и протеуса.
Считайте это моей фичей :)
Желающие «копипастить» получили исходник целиком.
Насколько я понял автора, говоря про узлы периферии, он имел ввиду именно конкретные минималистические проекты, которые предназначены для изучения работы конкретных узлов периферии.
Например: работа с таймером, UART, PWM и тп, но все в отдельных проектах. А уже после приступать к более высоко-уровневым и сложным проектам.
Лично я, почти так же поступил когда-то:
Проанализировал свои идеи и разбил на составляющие узлы (механизмы), из чего понял какие мне нужны технологии периферии. Но я уже владел и Си, и Ассемблером.
А к словам автора, я бы добавил механизмы виртуализации разработок, как например Proteus.
Многие его ругают, но ИМХО это от недостатка знаний. Меня он пока не подводил.
Ведь для таких экспериментов и паять уметь не нужно (для начала конечно), а параллельно с этим изучить и уроки пайки.
И тогда успех будет сто процентным.
Частота слишком высокая, попробуйте испытать в «протеусе», с картинкой на осцилографе.
Не уверен что в ардуинке заведется, впрочем не проверял.
получаем 16к на буфер.
На деле, WS2812B имеет такой порядок бит: GGGGGGGG RRRRRRRR BBBBBBBB,
где будет занято 12к на буфер.
Другое дело — совсем не вижу смысла использовать буфер для таких примитивных целей, даже для СМУ, здесь можно реализовать любые последовательности используя 30-60 байт.
Вот если буфер заполнять с компьютера (от простейшего управления последовательностью, до полноценного потока), тогда в нем действительно есть необходимость.
Впрочем, идея хороша уже тем что это STM32, а по поводу временных задержек в реализациях которые уже были — все проще: у Attiny нет DMA.
А по поводу датчиков, они необходимы для возможности корректировки задержек и процесса самообучения:
в EEPROM хранятся некие значения задержек для каждой из катушек, и некие значения дельта смещений задержек от предыдущего выстрела, программа корректирует считанную задержку новой дельтой и считает время излета.
Если таковое окажется успешнее предыдущего, происходит запись новой задержки и текущей дельты в EEPROM.
Новую дельту можно выбирать либо относительно предыдущей, либо совсем случайно, и в случае снижения показателей скорострельности — запись данных не производить. Таким образом пушка может самостоятельно повышать эффективность стрельбы. Короче целая область для фантазии.
А по-факту: следуя Вашей логике, Ассемблер — тем более нужно искоренить как «адское зло», потому что на нем очень трудно писать, ввиду сложности работы с адресами, и прочей «сатанинской сути».
Что уж говорить про машинный код, на котором, смею Вас заверить, тоже пишут, тоже люди, как бы странно Вам это не показалось.
Насколько помню, это давало степень сжатия выше JPG, без потери избыточности (в цвете).
Почти чистый MSX Basic, в танках низкоуровневые подпрограммы для видеопроцессора написанные Алексеем Зайко (Phantom Lord), для осыпалки, копалки и тп.
Так выше же сказано зачем: «популизм»
А Вы не уподобляйтесь ему, не станет он отвечать на Ваши вопросы, он фанатик, которые нужны в любом деле, в нужном количестве.
Насколько я понял ТС юзает такую: байду, и судя по описанию, она на PL-2303
А вот ДШ на PL-2303, в котором сказано, что частота в ней программируемая. То есть сама она не подстраивается, а задается.