Крайне желательно расширить работу с портом UART

[ginps]

Уже в скриптах для MB90F появилась необходимость контролировать процесс передачи.

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

При работе с MB96 эта необходимость встала ещё большей стеной, надо думать как выкручиваться, какие костыли вставлять.

Предлагается добавить в программный интерфейс UART регистр статуса - UART_ST.

Один бит выделить на флаг контроля передачи.

Он должен устанавливаться при записи в UART_DATA, а сбрасываться когда завершится передача байта

(не освободится внутренний буфер, а именно полностью выйдет в линию).

Так же можно добавить в этот статусный регистр контроль буфера приёма или количество принятых байт в приёмном буфере.

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

Т.е. при наличии возможности передачи отключать приём, чтобы возможный лишний мусор не поступал на приёмник.

[Александр]

Это потребует модификации прошивки программатора и соответственно обновления ее.

Кроме того может возникнуть несовместимость с уже существующими скриптами, где используется UART. И нужно будет эти все скрипты корректировать и рассылать по-новой.

[ginps]

Это потребует модификации прошивки программатора и соответственно обновления ее.

Кроме того может возникнуть несовместимость с уже существующими скриптами, где используется UART. И нужно будет эти все скрипты корректировать и рассылать по-новой.

Прошивка меняется без запинки.

Почему возникнет несовместимость?

"может возникнуть", но может и не возникнет, что более вероятно (с моей колокольни).

Регистр добавляется, а не меняется. Т.е. все старые скрипты должны работать с UART как и прежде.

Но попробовать нужно, как минимум.

Сделать более полноценный UART.

[+Roman_77]

Ну тот кто хочет - ищет пути решения. кто нет - ищет сложности в пути для оправдания.

Я конечно не разработчик ПО, но мне уже из описанного понятно, что при имеющемся софте есть предел - некий круг за который уже не выйти. Если это всё ещё на стадии, как это модно стало нонче называть "развивающийся проэкт", то когда то придется и дорабатывать и исправлять и обновлять и разсылать.

[eeprom+]

Работа со скриптами требует виртуальной машины в прошивке процессора, поэтому есть сложности в изменении обработчика скриптов. До момента написания сриптов для 96й серии режимов UART хватало. Нет возможности подстраивать прогер под каждый скрипт, должно быть наоборот и никак иначе.

[+Roman_77]

Нет возможности подстраивать прогер под каждый скрипт, должно быть наоборот и никак иначе.

Это совершенно понятно. Но есть ли возможность? Я то не в курсе. Человек пишет про отсутствие возможности реальной или он плохо искал, не знаю. Я больше не на вопрос ТС отреагировал а На ответ. Не вдаваясь в суть, сама тональность навела на меня грусть за будущее))

[ginps]

Рано или поздно возникла бы подобная необходимость. (конечно ни кто не виноват, что исходная реализация половинчатая, неподумали)

Чем раньше её выправить, тем лучше.

PS:

Видимо придётся выдумывать костыли, чтобы хоть как-то можно было работать.

А жаль.

Может даже плату какую-то городить, хотя всё необходимое - доделать виртуальную программу.

[ginps]

Человек пишет про отсутствие возможности реальной или он плохо искал, не знаю.

Искали уже в одном комплекте скриптов, нет ничего. Статуса UART нет в принципе.

Пришлось костыль ставить, чтобы хоть как-то поехало.

А в текущей ситуации и костыль не просматривается.

[u-vovchika]

Блочный прогер тоже неплохо. Правда ценник может поднятся

[eeprom+]

Как же так - для моторол, renesas, MBUS, KLINE и др. текущего UART-a хватало выше крыши, и для тех же MB90X, а тут вдруг UART требует доработки. Обновление прошивки прогера - это добавление нового модуля. Возникла необходимость CAN - обработчик CAN добавлен в прошивку, появилась необходимость в BDM - так же этот модуль добавили. Нужен был инверсный UART - реализован железно. Все необходимые требования выполняются. Я не знаю для чего отключать прием в UART, если обнулить внутренний буфер - то достаточно вычитать оттуда все данные пока не будет читаться 0x8000.

[ginps]

Нужен был инверсный UART - реализован железно. Все необходимые требования выполняются.

Железно непонятно когда ушла посылка, а для протоколов, требующих синхронизации на это чревато последствиями.

В любой реализации универсального UART имеется регистр статуса, в котором много интересного.

Жаль, что не подумали это реализовать хоть в минимальном варианте.

[ginps]

Блочный прогер тоже неплохо. Правда ценник может поднятся

Однозначно поднимется, только это будет не прогер, а костыль за дополнительные деньги.

PS:

Но я такой вариант не понимаю.

Хотя с точки зрения бизнеса это конечно дополнительный бонус.

[+Roman_77]

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

Начни с целей и задач. Слухаемо...

[+Odotech]

Спорная ситуация, с одной стороны ginps прав, а с другой eeprom+.

Добавление этих процессоров стоит того, чтобы кардинально подумать и решить что нибудь для не хромого варианта.

[+Roman_77]

Я эт к тому - про цели и задачи, что мне наверное всё просто кажется, если не вдаюсть в подробности написания скрипта.

Есть проц определенной марки, серии..

Он читается и пишется по уарту2. - это все возможности доступа к процу?

Проц имеет ли защиту, и если имеет, возможен ли её обход. Если возможен, то изменяется ли при этом параметры чтения/записи?

Кстати - где эти процы стоят? На сколько это всё вообще надо ?

[ginps]

Нужно простое, отправить посылку синхронизации, несколько байт.

Во время этой посылки на вход UART приходит мусор, всё что угодно.

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

Если он верный, то процесс синхронизации успешно завершён. А если нет, повторяем с оправки.

Но при текущей реализации нельзя отделить мусор от того единственного байта, т.к. непонятно когда завершается отправка пакета синхронизации.

Выделить из мусора "верный" нельзя, т.к. он может так же легко появиться в мусоре.

[+Roman_77]

Спорная ситуация, с одной стороны ginps прав, а с другой eeprom+.

Добавление этих процессоров стоит того, чтобы кардинально подумать и решить что нибудь для не хромого варианта.

Так надо порассуждать вслух оптом и понять где надо додавить а где можно обойти

[ginps]

Кстати - где эти процы стоят?

viewtopic.php?f=48&t=383

[+Roman_77]

Нужно простое, отправить посылку синхронизации, несколько байт.

Во время этой посылки на вход UART приходит мусор, всё что угодно.

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

Если он верный, то процесс синхронизации успешно завершён. А если нет, повторяем с оправки.

Но при текущей реализации нельзя отделить мусор от того единственного байта, т.к. непонятно когда завершается отправка пакета синхронизации.

Выделить из мусора "верный" нельзя, т.к. он может так же легко появиться в мусоре.

А нельзя ли это реализовать через обычную верификацию? Ну летит мусор по своим адресам, так он же не в адреса целей летит.. Прочитать оттуда и понятно будет, всё ли долетело как надо ?

Так процы в панельках или где?

[ginps]

А нельзя ли это реализовать через обычную верификацию?

нельзя.

Остальное вообще не в тему.

[coolibin]

Сколько писал код, ни разу не было такого что вот чего то не хватает в УАРТ'е. Его функционала хватало чтобы решить все задачи которые встречались мне. Можете привести пример где реально без нововведений никак? Есть этот кусок документации на проц? Из выше написанного не всё понятно. Нужна правильно поставленная задача - будет решение.

[+Odotech]

Тогда хороший вариант такой, экспериментально изменяется firmware программатора и тестируется на совместимость со старыми имеющемися скриптами.

[+Roman_77]

нельзя.

Остальное вообще не в тему.

Ну не в тему, так не в тему. Вопросы есть а ответов нет. В итоге то......? Модули будут без доработки софта прогера?

[coolibin]

Компромиссный вариант - реализую поставленную задачу на имеющемся УАРТ-е за половину стоимости складчины.

[u-vovchika]

Компромиссный вариант - реализую поставленную задачу на имеющемся УАРТ-е за половину стоимости складчины.

Надеюсь ваше общее сотрудничество ускорит процесс