Как я уже выше (до бурного обсуждения яиц") писал: "В неспешных планах - доработать консольку к базовой котуинке и программатору для ат89сх051... ..." вот будет готово - выложу. Пока стадия проверок/тренировок/оценки чего и куда можно использовать. Возможно и не понравится/чего-то не устроит - это ж мои "хотелки" - спешить некуда!
Я не пишу о законченной программе, а только о работе с COM портом, т. е. его открытие, прием и передача данных. Или у вас нет никаких наработок (например из других программ)?
Есть. Но того, чего моим хотелкам надобно пока не совсем получается - мутим воду в ступе (нет достаточного описания по нужным моментам - приходится пробным тыком). У МК можно с СОМ портом (UART) аки пожелается работать. А вот ЯВУ обычно через функции/библиотеки - их то и долбимсс... Да еще "побочные эфекты" по разнице ввода с клавиатуры, русификаторам и прочим мелкопакостям разницы ХР и DOS-Win98.
А вот ЯВУ обычно через функции/библиотеки - их то и долбимсс...
если смириться с тем, что настройку COM-порта делать через свойства драйвера в диспетчере устройств, то на уровне ЯВУ работа с COM-портом в самом простом случае ничем не отличается от работы с файлом: открываете файл "COM1", и пишите-читаете его, потом закрываете (можно и не закрывать - по завершению программы ОС сама все позакрывает).
единственное, к чему надо быть готовым при таком подходе, так это в к тому, что если МК на комп не послал данные, попытка чтения из такого "файла" начнется, но не кончится - будет ждать данных. если МК так и не пришлет ничего, задачу придется снимать диспетчером задач.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Там больше гвоздь не в настройках, а в "непечатаемом обрамлении"... 0х0D - 0x0A и когда оные заблаговолят добавится в каждом конкретном случае. Вобчемс потихоху проверяю "границы дозволенного" да как и куда их применить.
Дык нормально все - "идет плановый процесс" садизма над прожками. Собственно считать - принять - переслать - записать *.hex файлик. Так чтоб корректно во всех случаях (из возможных) было.
если смириться с тем, что настройку COM-порта делать через свойства драйвера в диспетчере устройств
Если не обратили внимание BOB51 собирается писать на QB т. е. бейсике для DOS. А в нем кроме прямого доступа к порту вроде нет другого способа работы (даже если в QB есть функции работы с портом, в конечном счете они используют прямой доступ, т. е. в DOS драйверов порта не было). Так что настройки диспетчера устройств не имеют значения.
ARV писал(а):
единственное, к чему надо быть готовым при таком подходе, так это в к тому, что если МК на комп не послал данные, попытка чтения из такого "файла" начнется, но не кончится - будет ждать данных.
Перед чтением можно проверить есть ли данные в буфере приема порта.
я не говорю о работе с портом, я говорю о работе с файлом. правда, с COM-портами в DOS-е не работал, но вот "файл" LPT1 открывался на ура, и печатал все отлично. может, так и есть какие-то тонкости, но на уровне файлов должно и с COM-портами работать, имхо.
Мурик писал(а):
Перед чтением можно проверить есть ли данные в буфере приема порта
можно, но я говорил о самом примитивном варианте работы с ним.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Как раз 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 файла и его интерпретации! Там просто не всегда "непечатные" на свои места в нужном количестве попасть могут - зависит от применяемых команд и настроек СОМ порта. Информация как раз о специфике команд маловата была.
В вики написан формат данных в файле. Разобрать его или собрать не представляет сложностей. Передавать данные hex файла в МК и в нем разбирать обычно не имеет смысла. Проще разобрать на компе, а через порт отправить бинарные данные.
Еще раз повторяю - источником проблем являются не сами данные, а "непечатные символы" обрамления символьной строки данных. Эти байтики в обычном режиме просмотра НЕ ВИДНЫ, однако весьма коварно себя проявляют. ЛЮБАЯ строка 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
Снова не то! Стандартно файл имеет или запись заданного размера.... (что для строки *.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 файлы и создавать их и не возникало описанных проблем.
Вопрос именно в пересылке - какая настройка СОМ порта и какие команды использовать. Это не создание файла средствами программы, а пересылка уже готовых между потребителями. Ведь читаем строку символов ВСЮ. ее же и отсылаем. Причем с дисковыми файлами проще - один как input, другой как output - а вот СОМ предпочтительно random... Строка читается из одного и пишется в другой (не анализируется и не пересобирается). Причем во всех случаях присутствует СОМ (или как источник или как приемник), а не файл-файл на диске. Ежли б тот 0х0А, добавленный в конец там и оставался после пересылки - то вероятно быстрее бы внимание обращено было. А тут ошибка проявляется по - хитрому - добавленный 0х0А цепляется к началу следующей строки. Пока вспомнил все давно позабытое, да чего и не знал... Ну да то еще не все "мелконюансы" - ведь база QBasic (1.0/4.5/7.1) таки для 98-й в лучшем случае была сделана. дополнительно вылез нюанс по вводу с клавиатуры: n$=INKEY$ при запуске под ХР не выполняется вместо него приходится цеплять n$ = INPUT$(1) какие-то отличия в обработке клавиатуры... Вероятно ещё чего-нибудь по ходу вылезет - не даром же матюк от мелкософта при запуске "ОЙ!!! НЕ ТА СИСТЕМА!!! Я ТОЛЬКО ПОД ДОС АРБАЙТЕН БЕЗ МОЗГОТРЕПА!!!" Хотя родную DOS от ХР таки признают ВСЕ васики. Было сомнение - сможет ли пройти запись файла на NTFS диск - пишут те васики без проблем.
Последний раз редактировалось BOB51 Пт дек 27, 2019 22:00:22, всего редактировалось 1 раз.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
