Котуинко

[Мурик]

ОК. Выложите код который используете в QB для доступа к COM порту.

[BOB51]

Как я уже выше (до бурного обсуждения яиц") писал:
"В неспешных планах - доработать консольку к базовой котуинке и программатору для ат89сх051...

..."
вот будет готово - выложу.
Пока стадия проверок/тренировок/оценки чего и куда можно использовать.
Возможно и не понравится/чего-то не устроит - это ж мои "хотелки" - спешить некуда!

[Мурик]

Я не пишу о законченной программе, а только о работе с COM портом, т. е. его открытие, прием и передача данных. Или у вас нет никаких наработок (например из других программ)?

[BOB51]

Есть.
Но того, чего моим хотелкам надобно пока не совсем получается - мутим воду в ступе (нет достаточного описания по нужным моментам - приходится пробным тыком).
У МК можно с СОМ портом (UART) аки пожелается работать.
А вот ЯВУ обычно через функции/библиотеки - их то и долбимсс...
Да еще "побочные эфекты" по разнице ввода с клавиатуры, русификаторам и прочим мелкопакостям разницы ХР и DOS-Win98.

[ARV]

А вот ЯВУ обычно через функции/библиотеки - их то и долбимсс...

если смириться с тем, что настройку COM-порта делать через свойства драйвера в диспетчере устройств, то на уровне ЯВУ работа с COM-портом в самом простом случае ничем не отличается от работы с файлом: открываете файл "COM1", и пишите-читаете его, потом закрываете (можно и не закрывать - по завершению программы ОС сама все позакрывает).

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

[BOB51]

Там больше гвоздь не в настройках, а в "непечатаемом обрамлении"...
0х0D - 0x0A и когда оные заблаговолят добавится в каждом конкретном случае.

Вобчемс потихоху проверяю "границы дозволенного" да как и куда их применить.

[ARV]

если бы вы говорили нормальным языком, я мог бы попробовать вам помочь. а так - только сочувствую.

[BOB51]

Дык нормально все - "идет плановый процесс" садизма над прожками.

Собственно считать - принять - переслать - записать *.hex файлик.
Так чтоб корректно во всех случаях (из возможных) было.

[Мурик]

если смириться с тем, что настройку COM-порта делать через свойства драйвера в диспетчере устройств

Если не обратили внимание BOB51 собирается писать на QB т. е. бейсике для DOS. А в нем кроме прямого доступа к порту вроде нет другого способа работы (даже если в QB есть функции работы с портом, в конечном счете они используют прямой доступ, т. е. в DOS драйверов порта не было). Так что настройки диспетчера устройств не имеют значения.

единственное, к чему надо быть готовым при таком подходе, так это в к тому, что если МК на комп не послал данные, попытка чтения из такого "файла" начнется, но не кончится - будет ждать данных.

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

[ARV]

вроде нет другого способа работы

я не говорю о работе с портом, я говорю о работе с файлом. правда, с COM-портами в DOS-е не работал, но вот "файл" LPT1 открывался на ура, и печатал все отлично. может, так и есть какие-то тонкости, но на уровне файлов должно и с COM-портами работать, имхо.

Перед чтением можно проверить есть ли данные в буфере приема порта

можно, но я говорил о самом примитивном варианте работы с ним.

[BOB51]

Как раз qbasic использует функционал DOS при работе с СОМ портом (особо туда лезть не требуется), который вполне поддерживаем при работе с ХР. Относительно LPT по непосредственному адресу там возможен только прямой ввод/вывод в/из регистра данных, а доступ к управляющим регистрам по прямому адресу ХР блокирует, что и привело в недалеком прошлом к прекращению работы со старыми самодельными программаторами. Там у меня обмен шел частично через служебный регистр LPT непосредственным "программным ногодрыгом". А вывод в LPT как в файл ессно на сегодня уже особого интереса не представляет.
Гораздо более перспективно с точки обмена с всяко-внешней безделицей использовать СОМ (или USB-COM на соответствующих номерах, поддерживаемых старовасиками - СОМ1, СОМ2).
Посему за основу и взяты работа с текстовыми файлами (частность формат intel hex8 он же и как простой *.txt может быть записан) и с СОМ портом как с файлом random доступа.
Вполне себе приятненькая штука, учитывая что в КОТУИНКе (и в программаторе для АТ89Сх051 на ее основе) для обмена и управления используются именно *.hex файлики.
Одначе там и просто непосредственные ASCII сторки информационных сообщений через СОМ перегоняются.

Относительно простых строк - проблем вообще никаких нету.
А вот с точным преобразованием *.hex блоков кой - чего таки пришлось помудрить из-за неполной информации.
Смысл перебросок -
чтение с диска и пересылка через СОМ на устройство
и
прием с устройства и запись в ранее заготовленный пустой шаблон *.txt...
В основном проблемы в выборе INPUT# или LINE INPUT#, разных опциях самого СОМ как файла при открытии и поведении "непечатаемых символов" обрамления - 0x0D, 0x0A, 0x1A при записи/чтении данных в/из целевого файла на диске.
Ибо мудрить с добавлением 0x1A в готовые файлы есть некошерно, а "задвоение" 0x0A порой весьма на нерву действует.
Вобчемс... разобрался и с этим.

Благо тестировка особо проблем не представляет - открываем обыкновенный terminal на СОМ1 и собственно васик на СОМ2 да гоняем заранее известные файлики туда-сюда пока необходимый результат не получим.
Из аппаратной добавки - простейший перекрестный кабель (нуль-модемный) с минимальным набором сигнальных линий - используются только RxD, TxD и "земляной" (прицел на радиоканал).
Из дополнительных средств анализа - hieW6.86 - дабы наблюдать те "непечатные" в исходном и конечном файликах.

Теперь все расписать по конспектам да добавить всякоудобств, контроля и прочего интерфейсу для результирующей консольки програмаматора...

[Мурик]

А вот с точным преобразованием *.hex блоков кой - чего таки пришлось помудрить из-за неполной информации.

https://ru.wikipedia.org/wiki/Intel_HEX

[BOB51]

МУРИК
речь не о формате *.hex файла и его интерпретации!

Там просто не всегда "непечатные" на свои места в нужном количестве попасть могут -
зависит от применяемых команд и настроек СОМ порта.
Информация как раз о специфике команд маловата была.

[Мурик]

В вики написан формат данных в файле. Разобрать его или собрать не представляет сложностей.
Передавать данные hex файла в МК и в нем разбирать обычно не имеет смысла. Проще разобрать на компе, а через порт отправить бинарные данные.

[BOB51]

Еще раз повторяю -
источником проблем являются
не сами данные, а "непечатные символы" обрамления символьной строки данных.
Эти байтики в обычном режиме просмотра НЕ ВИДНЫ, однако весьма коварно себя проявляют.
ЛЮБАЯ строка intel hex файла стандартно имеет два завершающих символа ASCII
0x0D и 0x0A (CR,LF)
однако если при промежуточной обработке чего-то из них или исчезнет или
удвоится - нормального результата можно не ожидать.
Чаще всего вариант
......0x0D 0x0A 0x0A вместо
......0x0D 0x0A
как следствие - к примеру строка завершения файла:
.....
:00000001FF
может внезапно оказаться на байт длиннее -
хотим контролировать 9-й байт (1 в случае конца файла):
m$ = MID$(B$, 9, 1) не сработает - по факту при "задвоении 0x0A" в m$ попадет значение 0 от 8-го байта
причем не факт, что подобное "задвоение" будет с первого раза обнаружено - в первой строке обрабатываемого файла
(считали, через СОМ переслали и записываем) такой скрытый подарочек может проявится только при обработке второго файла из нескольких последовательно пересылаемых.
или внезапно в записанном на диск файле при его открытии стандартным редактором вместо слитно следующих строк
появится "черезполосица" которую уже дальше по назначению использовать без редактирования вручную будет затруднительно.

[Мурик]

Задача легко решается.

Код: Выделить всё

s$ = "1234"+Chr($0C)+Chr($0A)+Chr($0A)+Chr($0A)+
     "5678"+Chr($0A)+
     "0000"+Chr($0C)+
     "4321"+Chr($0A)+Chr($0C) ; Такая вот строка.

ReplaceString(s$, Chr($0C), Chr($0A), #PB_String_InPlace) ; Замена в исходной строке 0x0C на 0x0A.
s$ = ReplaceString(s$, Chr($0A)+Chr($0A), Chr($0A))       ; Замена двух следующих друг за другом 0x0A на один.
Count = CountString(s$, Chr($0A))                         ; Узнаем сколько 0x0A в строке.

Debug "Count = "+Count
Debug " ---- "

For i = 1 To Count
  str$ = Trim(StringField(s$, i, Chr($0A)))
  If str$ <> ""
    Debug str$
  EndIf
Next

Спойлер

Строки.png

(30.16 КБ) 63 скачивания

[BOB51]

Снова не то!

Стандартно файл имеет или запись заданного размера.... (что для строки *.hex файла неприемлемо ибо они могут быть переменной длины) или надо использовать INPUT#/LINE INPUT# с последующим PRINT# одной и той же строки.
Зачем собственно вникать в СОЗДАНИЕ или РЕДАКТИРОВАНИЕ заранее сделанного содержимого на уровне программы транзитной пересылки (кроме проверок контрольной суммы да ошибок обмена в максимальном варианте)?.
Нужно всего-то УЖЕ ГОТОВЫЕ *.hex блоки перегонять, да простые информационные строки для вывода в окошко консоли сообщений.
Только тут малость разница - строка сообщения это LINE INPUT#, а для *.hex записи более корректно INPUT# (относительно файла на диске или СОМ порта как файла режима RANDOM).
Это при одной и той же конфигурации СОМ порта.
Изготовление самих *.hex делается в других программах/устройствах.
А вот СОВМЕСТИМОСТЬ результата для использования в иных программаторах (содержимое скачанное из ПЗУ МК) обязана присутствовать. Т.е. корректно созданный во внешнем устройстве (или считанный с диска) *.hex файл должен пройти передачу через СОМ порт и также корректно далее быть записанным на диск.
Да и как писалось выше ПРОБЛЕМА уже УСПЕШНО РЕШЕНА.
А долизывать и восстанавливать старую консольку - то уже по мере желания и времени.
Всеж - таки НОВОГОД!

[Мурик]

Снова не то!

Тогда что подразумевали под этим?

ЛЮБАЯ строка intel hex файла стандартно имеет два завершающих символа ASCII 0x0D и 0x0A (CR,LF) однако если при промежуточной обработке чего-то из них или исчезнет или удвоится - нормального результата можно не ожидать. Чаще всего вариант...... 0x0D 0x0A 0x0A вместо...... 0x0D 0x0A

Мне неоднократно приходилось разбирать hex файлы и создавать их и не возникало описанных проблем.

[BOB51]

Вопрос именно в пересылке - какая настройка СОМ порта и какие команды использовать.
Это не создание файла средствами программы, а пересылка уже готовых между потребителями.
Ведь читаем строку символов ВСЮ. ее же и отсылаем.
Причем с дисковыми файлами проще - один как input, другой как output - а вот СОМ предпочтительно random...
Строка читается из одного и пишется в другой (не анализируется и не пересобирается).
Причем во всех случаях присутствует СОМ (или как источник или как приемник), а не файл-файл на диске.

Ежли б тот 0х0А, добавленный в конец там и оставался после пересылки - то вероятно быстрее бы внимание обращено было.
А тут ошибка проявляется по - хитрому - добавленный 0х0А цепляется к началу следующей строки.
Пока вспомнил все давно позабытое, да чего и не знал...

Ну да то еще не все "мелконюансы" - ведь база QBasic (1.0/4.5/7.1) таки для 98-й в лучшем случае была сделана.
дополнительно вылез нюанс по вводу с клавиатуры:
n$=INKEY$ при запуске под ХР не выполняется
вместо него приходится цеплять
n$ = INPUT$(1)
какие-то отличия в обработке клавиатуры...

Вероятно ещё чего-нибудь по ходу вылезет - не даром же матюк от мелкософта при запуске
"ОЙ!!! НЕ ТА СИСТЕМА!!! Я ТОЛЬКО ПОД ДОС АРБАЙТЕН БЕЗ МОЗГОТРЕПА!!!"

Хотя родную DOS от ХР таки признают ВСЕ васики.
Было сомнение - сможет ли пройти запись файла на NTFS диск - пишут те васики без проблем.

[Мурик]

Ведь читаем строку символов ВСЮ. ее же и отсылаем.

Проще на компе преобразовать hex в bin и отослать через порт. Все равно это нужно сделать.

Причем с дисковыми файлами проще - один как input, другой как output - а вот СОМ предпочтительно random...

COM это последовательный порт. Какой random доступ хотите получить?

Строка читается из одного и пишется в другой (не анализируется и не пересобирается).

Еще скажите что в МК зашивается hex как есть без преобразования в bin?