У меня написана программа управления насосами на ATMEGA 8, я, чтобы не заморачиваться с печаткой, хочу залить её в адруино, но там ATMEGA168, ноги у них одинаковые, а как она будет работать, и зальётся ли вообще от восьмёрки в сто шестьдесят восьмую?
_________________ Пишу с ошибками и опечатками.На это у меня есть разрешение и справка
Напрямую - нет. Придется перекомпилировать и, скорее всего, компилятор ругнется на другие имена регистров. Например, UART в m8 называется UCSRA, UCSRB, ..., а в m48/88/168/328 уже UCSR0A, UCSR0B, ...
Если речь о скетче под ардуино, то нужно будет установить платформу MiniCore от MCU Dude. Возможно пройдет... Если исходник написан "в рамках референса" ардуино IDE... Если обычный Си - там придется выполнить совет ранее данный.
Тогда придется под ту программку и платка делать и мегу искать соответствующую. Корректной правку Сишного проекта только автор или спец по Си сделать может. Ежли у Вас таковой возможности нету - печалька. Другое дело, если бы проект изначально в среде и по правилам Ардуино делался - там легче от младшего к старшему кристаллы перейти можно.
Да ладно вам. Между m8 и m168 не так много различий. Большая часть должна пересобраться без проблем, а остальное правится подбором наиболее подходящего регистра. Правда, с тем же UART придется быть осторожнее: настройка скорости обмена там может отличаться принципиально (но не уверен, смотрите даташиты). А вот если исходника нет, то тут да, будет посложнее. Хотя все равно можно рискнуть и дизассемблировать, внести правки с регистрами, и собрать обратно. Авось нигде нет слишком строгой завязки на тайминги.
Это ежли у java текст исходника имеется. А вот ежли только хекс... Тогда без вариантов лишь порвтроение один в один... Мы же и конкретной схемы проекта не знаем...
А в исходнике вы этого и не увидите, за исключением специфичных регистров (и то если используются). Выбор камня, его частота и список исходников прописываются в makefile. Ну или "настройках проекта".
Цитата:
Цитата:
А вот если исходника нет, то тут да, будет посложнее.
Это ежли у java текст исходника имеется.
Ну да. Но, еще раз, рискнуть дизассемблировать все же можно. Основное отличие, что в m168 к некоторым регистрам доступ будет не по in/out, а по sts/lds, что на такт дольше и на два байта больше. Так что тайминги и хакерские вычисления адресов могут разъехаться.
Цитата:
если сам не нашел, покажи исходник. кто-нибудь найдется помочь тебе.
На всякий случай: исходник это не только единственный *.c файл, а скорее всего весь каталог. Если делалось в AVRStudio (а судя по m8 - могло и в ней) - *.aps, *.aws, Debug и т.д. Еще, если есть, прочая документация. Схема там, настройки фьюзов.
Исходник есть, сейчас весь просматрел, так и не нашёл, где там прописано, что он именно для атмеги 8.
Так выложите тот исходник тут - может понятнее будет, чего с ним сделать (да и от какого компилятора - смотря по расширению, может оно просто *.ino - тогда все вопросы напрямую в ардуиноIDE снимаются)...
Правда, с тем же UART придется быть осторожнее: настройка скорости обмена там может отличаться принципиально (но не уверен, смотрите даташиты)
В восьмой меге регистры UBRRH/UCSRC делят один адрес и там логика доступа через одно место... в 168 уже атмелы не пожлобились на адресное пространство регистров и раскидали их друг от дружки.
В восьмой меге регистры UBRRH/UCSRC делят один адрес и там логика доступа через одно место...
Я помню, что в некоторых камнях (да, кажется, в m8 тоже) была такая особенность. Но вот в каких конкретно - надо смотреть документацию.
Just_Fluffy писал(а):
в 168 уже атмелы не пожлобились на адресное пространство регистров и раскидали их друг от дружки.
Дело не в "не пожлобились", а в том, что адресное пространство и без того кончилось, пришлось выносить регистры в MMIO. Причем тоже коряво: нет бы сгруппировать часто используемые (регистры данных, флаги, ...) в IO области, а редкие (настройки) - в MMIO. Чтобы не потерять скорость доступа. Но нет, решили разбить тупо "поперек", эта периферия целиком останется в IO, а эта - целиком в MMIO. Возможно, конечно, так сделать было сложно технически... но сильно сомневаюсь.
COKPOWEHEU, несколько не это имела ввиду. Регистры, которые не поместились в регистровый файл (0x00-0x3F) раскидали по всему оставшемуся пространству, от 0x40 до 0xFF, а не собрали рядышком, начиная с 0х40. И ради этого RAMSTART отодвинули с 0x60 на 0x100... (Кстати, вот еще одна несовместимость камней, если переменные в ассемблере "прибиты" гвоздями к адресам, а не к константе начала ОЗУ - то тоже трабла будет. Так то и в восьмой меге к регистровому файлу можно обращаться через MMIO, просто прибавив к адресу регистра 0x20.
а кто-то, видимо, не дочитал, что это у меня только для АТмега8. а для АТмега 88, 168 и 328 у меня ZH всегда 1 и загружаю только ZL, чтобы всегда попадать в 0х100...
_________________ Мудрость приходит вместе с импотенцией... Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
Кстати, вот еще одна несовместимость камней, если переменные в ассемблере "прибиты" гвоздями к адресам, а не к константе начала ОЗУ - то тоже трабла будет.
Да, вот про это я не вспомнил. И это куда более серьезная проблема, ведь в дизасме не будет даже человеко-читаемых меток для переменных, только куча одинаковых адресов. Тут либо надеяться, что статических переменных будет немного (все на регистрах или локальных переменных в стеке), либо уже полноценно реверсить. Впрочем, ТС говорил, что исходник в природе есть. Возможно, он даже сумеет его раздобыть.
Just_Fluffy писал(а):
Так то и в восьмой меге к регистровому файлу можно обращаться через MMIO
Ну, я понадеялся, что терминология IO/MMIO в данном контексте все же будет достаточно понятной.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения