Ого, linvinus впрягся в датчик, что-то будет
Фигасссе вопросов, пробую отвечать.
linvinus писал(а):Dmitry__ , а чего сразу код не запушили на гит?
Так я твой способ вообще проверил на другом проекте
, где был makefile, а этот датчик надо заставить себя дописать до make, надо все выпиливать из *.ino, приводить в порядок все *.h. Выпиливать все ардуиновские быдлобиблиотеки. write() я сразу не использовал, а вот analogwrit таки допустил, ну очень не хотел тратить время на свой pwm
linvinus писал(а):Кстати для geany есть плагин который подсвечивает что в коде изменено но не запушено в гит.
Даaa, замечательный этот geany, не устаю удивляться, я и 3% о его возможностях не знаю. Когда начинал его учить, тоже делал расцветку кода для avr, прикручивал make, а потом понял что это все бантики и все открутил
make в отдельной терминалке, подсветка синтаксиса для слабаков, сравнивалка - meld. Гит только commit, pull и push. Ot гитовского diff в глазах рябит, meld в миллиард раз удобнее.
setar писал(а):dccharacter писал(а):
ДАТЧИК НЕ РАБОТАЕТ, НАДО ПИЛИТЬ ДАТЧИК
работает и не плохо.
Да он нас троллит, хочет заставить работать быстрее
linvinus писал(а):Пытаясь понять как ваш датчик работает, для себя определил два момента
Забудь про быстрое чтение картинки, они цпециально все загрубили, чтоб дальше мышей это не использовали. Быстре 10 кадров/с не получишь никогда, а это вообще ни о чем. Единственный вариант,я его не исключаю в будущем: Приехало пятно в поле пзс, встали, 3 раза прочитали картинку, рассчитали смещение, отдали марлину.
Внутренними алгоритмами управления лазером тоже нельзя пользоваться, там все завязано на параметр "качество". Прямой зависимости "удерживать 50" там точно нет, посмотри лог от датчика в тестовых режимах. И да, эти алгоритмы меняются не только от чипа к чипу, но и от ревизии одной модели чипа.
linvinus писал(а):Но в документации atiny85 сказано что есть 2х проводной режим USIWM1 =1, USIWM0 =0
Не очень понял, avr может работать со spi по 1 пину sdi + sdo? Не знал. Но самый большой недостаток avr, что он не может мапить ресурсы на разные пины. В дигиспарк, например, нельзя трогать один пин юсб интерфейса, иначе пропадет загрузчик, и там вообще сделано все для уменьшения резания дорожек. Например штатный светодиод дигиспарка является выходом для принтера. И нет вообще лишних пинов. Остался один свободный пин юсб, который нельзя трогать. В будущем, я хотел перевести дигиспарк на rs232 загрузчик, тогда этот пин освободится и можно дебажные режимы обьединять с основным.
linvinus писал(а):Т.е. картинка доступна на следующий ферйм., т.е. 1 сек это что то неправильное.
Да там не только в этом пичалька, там пуза между чтениями регистров должна быть 100мкс. Это получается овер до фига, до 100мс. доходит только одно чтения кадра и без всяких ожиданий след. кадра. ЗАБУДь, нас кинули с фаст граб!
linvinus писал(а):вот ещё идея, можно использовать аппаратный SPI и (USITC: Toggle Clock Port Pin) софтварный клок, это ускорит загрузку данных, можно 6 тактов поделать что нибудь полезное
Да программно можно за 3 такта забирать бит, в это время контроллеру делать нечего совсем, не вижу потребностей в аппаратном spi. Даже в программном чтении добавлены задержки в виде "nop".