КР1878ВЕ1

[fifan]

Это почти тоже самое, я через такой подключал программатор плисин от Алтеры. Современнее было бы именно под USB.

[Shumadan]

Вот именно, а есть схема программатора под USB, переходники LPT/USB не предлагать.

https://7b17252a-a-62cb3a1a-s-sites.goo ... edirects=0
вот схема под COM. Добавив преобразователь на CH340 или FT232 будет по USB

[kotofalk]

Вот именно, а есть схема программатора под USB, переходники LPT/USB не предлагать.

Есть. У Б.Ю. Семёнова есть странички, посвящённые этому МК. Там есть ссылка на программатор со схемой на USB. Конструкция называется Ve1ProgUSB. Сделано на базе отладки FT245BM, которую уже не купить. В принципе, ещё можно купить отдельно микросхему, отдельно память 93C46 и сделать. Но мне показалось, что свой на ардуине сделать быстрее. Показалось =).
вот тут статья по программатору http://www.mcu-cpld.narod.ru/Ve1ProgUSB.html
Навсяк приложу файлы.

Схема с компортом, которую выложил Shumadan мне неизвестна. По крайней мере, я не знаю, каким софтом можно было бы гарантированно прошить этот МК через ком порт.

[Lavr]

... , но вот "порядок байт" меня ни разу
не побеспокоил в этом процессе...

Это потому, что у вас win98 и железный LPT

А что, Венды, начиная с Win XP, меняют порядок байт в файле?
Что-то я такого не слышал...

[kotofalk]

А что, Венды, начиная с Win XP, меняют порядок байт в файле?

Да не. Просто w98+LPT - это железная связка, на которой всё работает. А она не у всех есть.
Начиная с winXP уже прямая работа с LPT не катит. У кого-то был опыт использования каких-то прокачанных драйверов. Но у меня такого опыта нет. Да и вряд ли это поможет exe-файлу написанному под 16-разрядный DOS.
Порядок байт может менять софт. Если, к примеру, компилятор пишет в файл.sav 16b-word'ами, то в хекс-редакторе байты будут перевёрнутыми. Ну это если на x86 запускать. Соответственно, читающая программа также читает 16b-слова и никаких проблем нет. Вопрос возникает, когда файл открывается программой, которая не знает, что там word'ы и читает файл побайтно.
Да модель протеуса с толку сбила. Там на вкладке ROM содержимое контроллера с перевёрнутыми байтами. Хотя, скорее всего, разработчик модели просто не заморачивался содержимым окна ROM.
Просто открывая прошивку я надеялся увидеть опкоды. А увидел, что программа начинается после пропуска 512 байт и не с jmp 0x8015, а 0x1580. До того как залез файл прошивки, я так с этой пустотой в 512 байт данные в камень и отправлял.

[Lavr]

Я скачал ваш asm-файл, но никак в нём сам не разберусь.

Я сам скачал этот asm-файл, посмотрел в него и увидел, что там все просто.
Файл *.sav считывается в буфер памяти программы - как есть.
Никаких перестановок байтов нет. После чего байты берутся из буфера памяти
по одному в том порядке, как их занесли из файла *.sav.
Где там может поменяться порядок байтов - я просто не представляю...
Файл *.sav используется так, как он создан.

[Lavr]

Да модель протеуса с толку сбила. Там на вкладке ROM содержимое контроллера с перевёрнутыми байтами. Хотя, скорее всего, разработчик модели просто не заморачивался содержимым окна ROM.

Что-то вы и про Proteus странные сказки рассказываете... Либо Proteus у вас кривой...

Вот у меня проект Proteus этих самых часов, и выведен дамп памяти.

C18.PNG

А вот файл прошивки Clock18.sav - через WinHex...

C18_1.PNG

Я не вижу ни перевёрнутых байтов, ни каких иных различий. Если что - Windows 7 у меня.

[Lavr]

Начиная с winXP уже прямая работа с LPT не катит.

Это тоже вы неправду излагать изволите...
Вот у меня самодельный программатор ByteBlasterMV :



Работаю с ним из под winXP под «MAX+plus II» через LPT и всё "катит"...

Программатор не сложнее того, что используется здесь для КР1878ВЕ1.
Единственное различие: под winXP прямое обращение к LPT идёт из DLL-
библиотеки, потому как обычной программе это просто запрещено.

[kotofalk]

Что-то вы и про Proteus странные сказки рассказываете...

У меня там всё то же, что и у вас.
Вот только незадача, по документации ангстрема, jmp никак не может быть 1580.

Так что, байты явно где-то перепутаны. Возможно, что и в документации.

Ну хотя бы со смещением 0x200 вы согласны? Оно видно на ваших скриншотах.
Если sav-файл используется так, как он создан, то в контроллер предварительно должны отправляться 512 байт пустоты.

Хорошо, что у вас с байтбластером получается. У меня пока ни разу нормально битбанг на LPT не заработал. А теперь и ни одного компьютера дома нет с LPT. И венда x64. Все 16-разрядные приложения только из-под виртуалки запускаются.

Я конечно удивлён. Попробую засовывать в камень "как есть". Ошибочки пока ещё не все нашлись, видимо. Спасибо за участие =)

[Lavr]

Что-то вы и про Proteus странные сказки рассказываете...

У меня там всё то же, что и у вас.
Вот только незадача, по документации ангстрема, jmp никак не может быть 1580.

Да какая мне разница? Я не писал компилятор для КР1878ВЕ1...
Файл *.sav - это бинарник, который создаёт компилятор ангстрема.
Никто на всём просторе интернета, пока я занимался КР1878ВЕ1, не сказал
ни разу, что компилятор ангстрема создаёт неправильный файл *.sav !
На программаторы грешат многие, на компилятор нареканий я не слышал...

[Lavr]

Если sav-файл используется так, как он создан, то в контроллер предварительно должны отправляться 512 байт пустоты.

И "пустоты" у меня там тоже нет, а есть какие-то байты.

C18_2.PNG

Но я себе не морочил голову содержимым... есть *.sav-файл и это - прошивка, созданная средствами Ангстрема.
Значит - она такая, как надо, и её надо залить как есть.

[kotofalk]

Да какая мне разница? Я не писал компилятор для КР1878ВЕ1...
Файл *.sav - это бинарник, который создаёт компилятор ангстрема.
Никто на всём просторе интернета, пока я занимался КР1878ВЕ1, не сказал
ни разу, что компилятор ангстрема создаёт неправильный файл *.sav !

Я нигде не сказал, что он неправильный. Я выражаю сомнение, что файл sav, это точный дамп. Т.к. я не могу взглянув на asm-файл прошиватора, сказать, что там всё просто и все байты заходят в камень точно так, как написано в файле. Потому к вам и обратился.
Т.к. мне не на что больше ориентироваться. В документации на камень - одно. В модели протеуса - другое (перевёрнуто), в файле sav - третье (перевёрнуто+смещение).

Я Бы тоже не морочил себе голову, если б не собрался свой USB-программатор сделать.

[Lavr]

Я нигде не сказал, что он неправильный. Я выражаю сомнение, что файл sav, это точный дамп.

А кто и где сказал, что файл *.sav - это точный дамп?

C1.PNG

Это файл прошивки... точный дамп - это обычно *.bin !

. я не могу взглянув на asm-файл прошиватора, сказать, что там всё просто и все байты заходят в камень точно так, как написано в файле.

А что вам мешает? Там прилично комментариев...
Я в упор не помню всего этого, но открыл файл и всё увидел...

Code: Select all

sub_FILE_89E  proc near        ; CODE XREF: start+3Cp  start+9Ap
    pusha
    push ds
    push cs
    pop  ds
    assume ds:seg000
    mov  ax, 3D00h
    int  21h; DOS -  2+ - OPEN DISK FILE WITH HANDLE
            ; DS:DX  -> ASCIZ filename
            ; AL = access mode
            ; 0 - read
    jb   loc_0_8DB
    mov  bx, ax
    xor  cx, cx
    mov  dx, cx
    mov  ax, 4202h
    int  21h; DOS -  2+ - MOVE FILE READ/WRITE POINTER (LSEEK)
            ; AL = method: offset from end of file
    jb   loc_0_8DB
    mov  bp, ax
    xor  cx, cx
    mov  dx, cx
    mov  ax, 4200h
    int  21h; DOS -  2+ - MOVE FILE READ/WRITE POINTER (LSEEK)
            ; AL = method: offset from beginning of file
    jb   loc_0_8DB
    mov  cx, bp
    mov  dx, offset byte_0_A99; 0A99h
    mov  ah, 3Fh
    int  21h; DOS -  2+ - READ FROM FILE WITH HANDLE
            ; BX = file handle, CX = number of bytes to read
            ; DS:DX  -> buffer
    jb   loc_0_8DB
    cmp  ax, cx
    stc
    jnz  loc_0_8DB
    mov  cs:word_0_89C, ax
    mov  ah, 3Eh
    int  21h; DOS -  2+ - CLOSE A FILE WITH HANDLE
            ; BX = file handle

loc_0_8DB:                     ; CODE XREF: sub_FILE_89E+9j
                               ; sub_FILE_89E+16j ...
    pop  ds
    assume ds:nothing
    popa
    retn
sub_FILE_89E  endp

В модели протеуса - другое (перевёрнуто), в файле sav - третье (перевёрнуто+смещение).
Я Бы тоже не морочил себе голову, если б не собрался свой USB-программатор сделать.

На самом деле вы весьма долго мне голову морочите и всему форуму совершенно надуманными проблемами...

P.S. Особенно с учетом того, что вы решили "свой USB-программатор сделать", а я лишь проверил
программу Ангстрема, работающую на LPT, на соответствие Ангстремовским же алгоритмам...
Причем мне и в голову не приходило ковыряться в структуре *.sav файла...

P.P.S. Может быть, вам лучше у этого чувачка спросить исходник? На ЯВУ написано...http://radionet.com.ru/shem/shem956.html

[Shumadan]

Схема с компортом, которую выложил Shumadan мне неизвестна. По крайней мере, я не знаю, каким софтом можно было бы гарантированно прошить этот МК через ком порт.

вот здесь и прога под XP
https://sites.google.com/site/russianlabyrinth/

[Lavr]

*.sav - это файл прошивки...

в файле sav - третье (перевёрнуто+смещение).

Я структуру файла *.sav не разбирал, поскольку, судя по коду, программатор считывает его целиком в свой внутренний буфер.
В этом случае в памяти программатора байты лежат так, как лежали в файле *.sav

Из интересу я вчера пошарил структуру файла *.sav поисковиками по Интернету, и ничего не нашел...

Но, сравнив несколько собственных файлов типа *.sav, пришел к выводу, что в начале файла - служебная
информация, по крайней мере, два ненулевых байта - это длина кода с адреса 200h.

C18_3.PNG

Что касается "другое (перевёрнуто), ... третье (перевёрнуто+смещение)", то ничего там
не перевёрнуто, а всё - совершенно правильно!

Команда КР1878ВЕ1 - 16-разрядная:



Программатор начинает читать команду побитно, начиная со старшего бита старшего байта слова:

C18_4.PNG

Поэтому старший байт в файле *.sav лежит первым, ибо это - файл прошивки.
После 16 сдвигов этот байт окажется на своём старшем месте, а следующий за ним - на своём младшем.