| Автор | Сообщение |
|---|
Postal2 Участник
Сообщения: 4116
|
Появилась интересная задачка, решил, что не только для меня  .
Необходимо создать поток байтов, исполняемый нормально на 8051 и 80186, имеющий одну точку входа и делающий return far на обоих. Задача кода - изменить ячейку памяти как признак, какое ядро определилось . Код грузится и стартует в RAM с адресов, которые можно задать, оттуда же нужно снимать результат. Во как !
Нужно для автодетекта ядра скалеров Genesis, у которых управление тем не менее одинаковое (типа биоса). То есть загрузка и старт кода выполняются одинаковыми командами для любого ядра.
|
|
GarikBaza Новичок
Сообщения: 664
|
Postal2, А ну ка подробнее, что значит поток байтов?
|
|
Postal2 Участник
Сообщения: 4116
|
GarikBaza, просто результат должен выглядеть как bin-файл, а код, его описывающий (ассемблер) - вторично. А команды у процов разного размера - массивом не назовёшь   .
Ну то есть допустим, байт "0х90" - загрузка DPTR 8051 и NOP для другого. Самое главное, исполнение разделить на код для своего проца, чтоб один прыгнул в одно место, второй в другое.
Добавлено 09-02-2011 19:54
| Postal2 писал: | | байт "0х90" - загрузка DPTR 8051 и NOP для другого |
А ! Вроде всё, походу, 8051 будет следующие два байта в DPTR грузить, а для 80186 там SJMP !!!
Добавлено 09-02-2011 20:08
Охренительно, но надо поискать другие варианты, не факт, что дата-поинтер трогать можно.
|
|
GarikBaza Новичок
Сообщения: 664
|
Postal2, Ага, теперь начал чтото пониматью Т.е. ты хочешь создать универсальный бутлоадер, который будет работать назависимо от ядра процессора, подобрать команды таким образом, чтобы они максимально подходили и к одному ядру, и ко второму. Типа LD R1,#0x00на одном ядре по коду совпадало с MOV R1,0x00.
Задачка действительно нетривиальная.
Может проще будет по каким то признакам определить ядро?
|
|
Postal2 Участник
Сообщения: 4116
|
GarikBaza, нет инфы, а когда есть - полно ошибок. Теперь, когда один вариант есть, понятно, что код для расцепления хода исполнения будет очень маленький. Только это не бутлоадер, а вызываемый код, поэтому лишнего трогать нельзя. В примере выше загаживается дата-поинтер, для конкретного чипа можно отследить в вызывающем софте, только чипов и вариантов немеряно. А создав хорошую проверялку, можно вообще не волноваться. В принципе, для 8051 не принято считать неизменным DPTR, но наверняка ещё варианты есть. Фирменный софт от этих чипов не то что тип ядра, протокол связи сам не определяет ! Какие там признаки... Но, в некоторых случаях, отдельный чип на соответствие проверяет чтением специальных адресов. Так чипов-то много, и универсальный метод как-то понадёжнее, да и, вроде, несложный.
|
|
Postal2 Участник
Сообщения: 4116
|
Пришлось остановить это направление - команда RamRead от GProbe не работает, не удаётся прочитать результаты. Будет тупо определяться чип чтением характерных для него регистров.
Пример кода (в виде массива) :
//LOAD TO ADDRESS 0x500, NEXT RUN 0x500, READ WORD 0x540,0x542
BYTE myCodeToLoad[68] = {
0x90,0x78,0x0D,0x90,0x05,0x40,0x74,0x51,
0xF0,0xA3,0x74,0x51,0xF0,0x22,0xFF,0xFF,
0x56,0x57,0x8B,0xF4,0xBF,0x40,0x05,0x90,
0x90,0x90,0x90,0xC7,0x05,0x86,0x80,0x47,
0x47,0x89,0x35,0x90,0x90,0x90,0x90,0x90,
0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,
0x90,0x90,0x90,0x90,0x5F,0x5E,0xCB,0xFF,
0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,
0x90,0x90,0x90,0x90 };
Пустые места в коде - был рассчёт на будущее, но не понадобится теперь.
|
|
|
