У меня написана программа управления насосами на ATMEGA 8, я, чтобы не заморачиваться с печаткой, хочу залить её в адруино, но там ATMEGA168, ноги у них одинаковые, а как она будет работать, и зальётся ли вообще от восьмёрки в сто шестьдесят восьмую?

Напрямую - нет. Придется перекомпилировать и, скорее всего, компилятор ругнется на другие имена регистров. Например, UART в m8 называется UCSRA, UCSRB, ..., а в m48/88/168/328 уже UCSR0A, UCSR0B, ...

Если речь о скетче под ардуино, то нужно будет установить платформу MiniCore от MCU Dude.
Возможно пройдет... Если исходник написан "в рамках референса" ардуино IDE...

Если обычный Си - там придется выполнить совет ранее данный.

Когда мне писали программу, адруины ещё впомине не было, это чисто под атмегу 8

В продаже новые LED-драйверы XLC компании MEAN WELL с диммингом нового поколения

Компания MEAN WELL пополнила ассортимент своей широкой линейки светодиодных драйверов новым семейством XLC для внутреннего освещения. Главное отличие – поддержка широкого спектра проводных и беспроводных технологий диммирования. Новинки представлены в MEANWELL.market моделями с мощностями 25 Вт, 40 Вт и 60 Вт. В линейке есть модели, работающие как в режиме стабилизации тока (СС), так и в режиме стабилизации напряжения (CV) значением 12, 24 и 48 В.

Подробнее>>

Тогда придется под ту программку и платка делать и мегу искать соответствующую.
Корректной правку Сишного проекта только автор или спец по Си сделать может.
Ежли у Вас таковой возможности нету - печалька.
Другое дело, если бы проект изначально в среде и по правилам Ардуино делался - там легче от младшего к старшему кристаллы перейти можно.

Да ладно вам. Между m8 и m168 не так много различий. Большая часть должна пересобраться без проблем, а остальное правится подбором наиболее подходящего регистра. Правда, с тем же UART придется быть осторожнее: настройка скорости обмена там может отличаться принципиально (но не уверен, смотрите даташиты).
А вот если исходника нет, то тут да, будет посложнее. Хотя все равно можно рискнуть и дизассемблировать, внести правки с регистрами, и собрать обратно. Авось нигде нет слишком строгой завязки на тайминги.

Проще Мегу168ю сдуть и 8ю припаять...

Это ежли у java текст исходника имеется.
А вот ежли только хекс...
Тогда без вариантов лишь порвтроение один в один...
Мы же и конкретной схемы проекта не знаем...

Исходник есть, сейчас весь просматрел, так и не нашёл, где там прописано, что он именно для атмеги 8.

если сам не нашел, покажи исходник. кто-нибудь найдется помочь тебе.

А в исходнике вы этого и не увидите, за исключением специфичных регистров (и то если используются). Выбор камня, его частота и список исходников прописываются в makefile. Ну или "настройках проекта".
Ну да. Но, еще раз, рискнуть дизассемблировать все же можно. Основное отличие, что в m168 к некоторым регистрам доступ будет не по in/out, а по sts/lds, что на такт дольше и на два байта больше. Так что тайминги и хакерские вычисления адресов могут разъехаться.

На всякий случай: исходник это не только единственный *.c файл, а скорее всего весь каталог. Если делалось в AVRStudio (а судя по m8 - могло и в ней) - *.aps, *.aws, Debug и т.д. Еще, если есть, прочая документация. Схема там, настройки фьюзов.

можно поинтересоваться, по каким событиям у вас насосы управляются?
Уровень, давление, температура.. или что-то ещё?

Так выложите тот исходник тут - может понятнее будет, чего с ним сделать (да и от какого компилятора - смотря по расширению, может оно просто *.ino - тогда все вопросы напрямую в ардуиноIDE снимаются)...

В восьмой меге регистры UBRRH/UCSRC делят один адрес и там логика доступа через одно место... в 168 уже атмелы не пожлобились на адресное пространство регистров и раскидали их друг от дружки.

Я помню, что в некоторых камнях (да, кажется, в m8 тоже) была такая особенность. Но вот в каких конкретно - надо смотреть документацию.

Дело не в "не пожлобились", а в том, что адресное пространство и без того кончилось, пришлось выносить регистры в MMIO. Причем тоже коряво: нет бы сгруппировать часто используемые (регистры данных, флаги, ...) в IO области, а редкие (настройки) - в MMIO. Чтобы не потерять скорость доступа. Но нет, решили разбить тупо "поперек", эта периферия целиком останется в IO, а эта - целиком в MMIO. Возможно, конечно, так сделать было сложно технически... но сильно сомневаюсь.

COKPOWEHEU, несколько не это имела ввиду. Регистры, которые не поместились в регистровый файл (0x00-0x3F) раскидали по всему оставшемуся пространству, от 0x40 до 0xFF, а не собрали рядышком, начиная с 0х40. И ради этого RAMSTART отодвинули с 0x60 на 0x100... (Кстати, вот еще одна несовместимость камней, если переменные в ассемблере "прибиты" гвоздями к адресам, а не к константе начала ОЗУ - то тоже трабла будет.
Так то и в восьмой меге к регистровому файлу можно обращаться через MMIO, просто прибавив к адресу регистра 0x20.

Just_Fluffy, если есть исходник, то место расположения "гвоздей" не имеет никакого значения.

Starichok51, помнится, мне кто то рассказывал, что у него ZH всегда ноль, адреса только в ZL крутятся... А тут чикс! И нет ОЗУ в области до 0х100...

а кто-то, видимо, не дочитал, что это у меня только для АТмега8.
а для АТмега 88, 168 и 328 у меня ZH всегда 1 и загружаю только ZL, чтобы всегда попадать в 0х100...

Да, вот про это я не вспомнил. И это куда более серьезная проблема, ведь в дизасме не будет даже человеко-читаемых меток для переменных, только куча одинаковых адресов. Тут либо надеяться, что статических переменных будет немного (все на регистрах или локальных переменных в стеке), либо уже полноценно реверсить. Впрочем, ТС говорил, что исходник в природе есть. Возможно, он даже сумеет его раздобыть.

Ну, я понадеялся, что терминология IO/MMIO в данном контексте все же будет достаточно понятной.