Появилась задача: получать данные с датчиков микросхемкой цифровать и потом отправлять на комп для обработки.
Микросхемки и человек который поможет и сделает есть, однако он спросил, как сигнал оформить мне. Что кидать.

Начитал что есть какие-то стоповые биты и в мсдн нашёл описание байт начала передачи, байт конца передачи и байт конца файла. первый 00010001 и в конце 00010011.
Эти байты по умолчанию были в структуре BSP когда я её считал.

То есть получится что МК кидает мне 00010001 потом данные, потом ЕОФ (не посмотрел ещё символ. из этой же структуры) и потом 00010011 и следом готовит следущую порцию данных.

Читаю так:



В общем-то и вопрос, правильно я думаю или где-то ошибка?

Протокол обмена между МК и РС - это абсолютно ваше дело с программистом, никакие там МСДН тут вам не указ, т.е. будет ли символ начала или конца файла или нет - дело ваше.
Если МК всегда передает данные порциями, надо в функции ReadFile указывать, сколько байтов надо принять, чтобы она возвращала сразу весь пакет целиком. Если МК выдает байт за байтом непрерывно - надо указывать этой функции, что надо принять именно 1 байт, и обрабатывать эти байты по мере поступления.
Раз задано 0 для Overlapped IO - функция ReadFile будет "подвешивать" всю программу до тех пор, пока не примет заданное количество байт - это может быть доволно большое время. Работа с ReadFile в режиме Overlapped требует определенного мастерства программирования. Если не охота заморачиваться, то перед вызовом ReadFile рекомендую получить сведения о количестве байт в буфере приемника (есть специальная функция в АПИ - программист должен знать) - и вызывать ReadFile только в том случае, если буфер не пуст - тогда никакого подвисания не будет.
В остальном ход мыслей верный.

Радует

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

Может проблема в том что я не так работу контроллера понимаю? И он тоже обязательно побайтно кидает?

Я понимаю, что мы договорились о частоте передачи и комп с этой частотой смотрит напряжение на ноге. и фиксирует у себя 0 и 1. а мк в соответствии с этой частотой меняет напряжение на ноге.
Комп в свою очередь каждые 8 считываний считает, что это был байт и записывает его в буфер. Хотя реально это может получиться бит одного байта и 7 бит другого?

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Буфер приема КОМ-порта компьютера очищается в момент открытия порта, т.е. при выполнении CreateFile. Сразу после этого приемник порта может начать принимать данные (настройки при этом будут те, которые заданы в системе для этого порта, т.е. через панель управления винды). Изменение настроек по ходу работы буфер не меняет!
Далее. Прием и передача в компе и в нормальных МК реализованы аппаратно, поэтому тебя вовсе не должно волновть, как там идет передача - твое дело настроить UART в МК, выдать байт в буфер передатчика, а дальше терпеливо ждать конце передачи . Так же песня и с компом: если скорости и кол-во битов данных настроено одинаково с МК и проводочки подключены верно - примет он байт, и тебя не колыхает, как именно . Никакого "бита от опредыдущего байта" в "следующий" не попадет, если все настроено нормально. Если тебя волнует возможность искажения данных при обмене - это надо делать при помощи подсчета контрольной суммы для пакета байтов - МК считает ее для передаваемого пакета и передает в конце его, а комп принимает байты, считает контрольную сумму и сравнивает ее с той, что передал МК - совпали обе - данные верны, не совпали - весь пакет данных сбрасывается и ожидается следующий...

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

Abaktych, ты когда в следующий раз ник менять будешь - меняй его сразу на "Посмотри на winavr.nm.ru внизу - там все подробно написано" - да и дело с концом - сэкономишь кучу сил на нажатиях клавиш: будешь только ник осталять в сообщении. Все равно все твои посты именно такие. Да и другим посетителям форума легче будет - сразу на заглавной странице будут видны ответы на все вопросы - зачем еще тему читать, искать чего-то?! А может ты вообще хочешь, чтобы Кот написал аршинными буквами на первой странице: "Форум закрыт, так как все, что вы хотели спросить уже подробно написано на winavr.nm.ru - все туда"?!?!

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

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

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


затем нажимаю кнопочку на МК и он передаёт на комп данные, те же 334 байта с контрольным в конце( к примеру)
Так?

А тот момент, когда я на компе принимаю файл (пытаюсь, жду) а на МК ещё кнопочку не нажал, там на ноге всё равно будет что-то. допустим ничего, то есть 0. он его не всосёт как кучу нулей?
ps: http://winavr.nm.ru/z5.htm читаю. Полезно, но вот такие мои вопросы не разобрались... пока что

Пока ты ждешь (не нажал на МК кнопочку) на линии TX будет логическая единица (учти, что для RS-232 это совсем не +5В!!!).
Приемник не "всосет" ничего до тех пор, пока передатчик МК не начент передвать. Начало передачи всегда обозначено переходом линии TX из единицы в ноль (стартовый бит) - именно с обнаружения этого момента начинает работать приемник.
Если ты будешь слишком долго думать, перед тем, как нажать кнопочку, на компе функция ReadFile может закончить свою работу с ошибкой таймаута (секунд через 10-30 примерно, может и дольше).

Мда... вернулся к началу...

будет использоваться контроллер 20С51 атмеловский,
а буфер ADM202. То есть никакой USART мк. И вся обработка будет осуществляться с 20С51.

то есть сначала ему надо отправлять 1. потом закинуть 0, что обозначит начало передачи, а потом байт данных (один только видимо, потом бит нечётности) и потом опять на 1 ставить ногу. тогда комп будет понимать это счастье как пришедший байт? И соответственно именно его я считаю прогой?

PS: прошу не предлагать использовать другие МК, потому как сейчас делает человек, любезно согласившийся помочь и умеющий с ними управляться, а если сменить, то делать буду я, а это ближайшие несколько лет ничем не закончится

Погодите, что значит "никакой USART мк"???
И потом, что за контроллер 20С51 от Атмел??? Сама фирма о таком не в курсе Может речь о AT89C2051?
Все 51-е микроконтроллеры обязаны иметь встроенный аппаратный UART - и AT89C2051 (если речь о нем) его имеет! Что за спеца вы там нашли, который собирается программно UART реализовывать на этом МК???
Кстати о птичках - рекомендую выбирать МК от атмел с буковкой S вместо С - их программировать проще .

Мда, видимо это я уже совсем запутался и не понимаю, чего он от меня хочет...

В общем пришли к мысли, попробует отправить несколько байтов и посмотреть как оно приходит... А потом уже смотреть будет, что да как...

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

Да вы что, ребята?! Что там смотреть?! Импульсы в линии, что ли?! Открываете виндовый терминал, настраиваете порт, как надо вам, отключаете контроль потока, выбираете эмуляцию терминала VT100, подключаете, а с МК передаете коды английских букв - они будут появляться на терминале... Если со своей прогой будете разбираться - то возможны нюансы, но с передачей битов-байтов?! Не забудьте TX микроконтроллера подать на RX компьютера .

ЗАЧЕМ ! использовать ископаемое старье ???

Есть КУЧА современный 8051 и есть ценой меньше 1 евро в розницу с USART !

Очень советую ATmega8 хотябы применить.

Симулировать ваше устройство вы можете в PROTEUS.

http://www.keil.com/c51/

микроконтроллеры 8051
http://www.keil.com/c51/chips.asp

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

Только чем дальше, тем страннее вопросы.

Он спрашивает только что мне кидать в порт.
Я задумался:
он кидает байты подряд. Скорость съёма информации на порядок быстрее передачи по ком порту. Буфер, используемый для хранения в МК не бесконечен. То есть будет собираться порция, отправляться в комп и ждать нового сигнала, для получения и отправки новой порции.

Я открываю ком для чтения, потом или кнопочкой или сначала пишу в ком, чтобы началась подготовка данных. Данные готовятся не мгновенно. поэтому я не знаю, что будет происходить в в этот период бездействия.
На МК будет 1 на ноге, а ком будет этим заполняться или нет?

Далее передача началась. Подряд 3 байта с датчиков, если эта единичка будет передаваться, то показания с датчиков перемешаются. по крайней мере я вычитал, что передача байта идёт в любом случае полностью. А вместо трёх байт с датчиков можно отправлять 4: первый- маркер.

Далее, читаю я не асинхронно, т.е. софтина ждёт пока данные прийдёт, как она поймёт что уже всё приехало? Надо что-то с МК в порт записать, чтобы софтина от порта отцепилась и не по тайм ауту.
Вот такие вопросы и на них ответа не могу найти

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

Это нормально

Не знаю, что там за решаемая задача, но МК обычно вовсе незачем иметь какой-то буфер для накопления данных - он их премило может выдавать в СОМ-порт по мере их появления (т.е. измерил что-то - выдал, затем начал мерить следующее).

Вопрос: оно вам надо?! В смысле, что там на ноге МК будет? Ваша прога на компе работает "на верхнем уровне", т.е. ей абсолютно безразлично, что там происходит на аппаратном.

Прекрасно! Только маркер должен быть таким, чтобы кардинально отличаться от передаваемых данных! Например, если в ожидаемом потоке данных байты должны быть заведомо меньше 200, то маркер может быть 243 . Или использовать двухбайтный маркер, или что-то еще - надо продумать все, как следует.

Софтина ваша же ждет не просто так, а постоянно проверяя данные в буфере приема порта. Появились данные - она проверяет их на равенство маркеру. Если не маркер - ждет дальше, если маркер - начинается цикл приема известного кол-ва данных. Разумеется, в цикле она тоже будет ждать, но уже без анализа на маркер.

То есть вам надо продумать протокол обмена между программой в ПК и программой в МК. Определитесь кто чего кому должен передавать, по каким "командам" и т.п. - станет все понятнее. Например, разработайте собственный "язык" команд, ну, например: ПК может передать в МК следующие команды:
0хС0 - это значит, начать измерение с нулевого канала
0хС1 - начать измерение первого канала и т.д.
МК, получив команду от ПК, начинает ее исполнять и выдает ответ - результат измерения. Нет команды - МК ждет, ничего не делает. В этом случае вы всегда будете знать, что происходит, в каком состоянии находятся устройства и программы, чего ждать и сколько .
Это только пример, у вас все может быть по-другому.

Так, во-первых идем вот сюда http://www.radiokot.ru/lab/controller/07 и читаем статью Мамонта, которую он в свое время написал о том как начать работать с UART на мк. Во вторых, если вам надо, чтоб софтина ждала окончания передачи, то задействуйте вспомогательные линии типа DTR, RTS и т.д и т. п.

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

В-третьих, в каком конкретно формате вы засунете туда свои байты волнует только вас. Как задумаете так и пройдет оно туда.

В-четвертых, особенность программ на С, на которую я недавно наткнулся. ReadFile весьма вероятно вылетит с ошибкой типа неправильный дескриптор com-порта если компилировать под XP компилятором MSVC с борландовским билдером такого не происходит. Видимо у msvc дефективный вызов api, который не позволяет работать с портами.

Вот!!! Оно! Какой символ отправлять?


Спасибо. Правда я в VS2005 компилирую, вроде пока не было проблем. Но если столкнусь буду знать

Это хорошо, если данных мало, а я их не в МК а на компе обрабатываю.

Задача стоит простая: есть вращающаяся деталь и в двух плоскостях снимаются силы. потом считается диаграмма и рассчитывается где надо подточить, чтобы деталь вращалась ровно.


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



Да нет. у меня цель получить все данные с буфера и только потом обрабатывать. чтобы данные не потерялись...

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

Главное, чтобы левые данные откуда-то не появлялись...

1. Термин "конец файла" применим к данным, количество которых заранее известно хотя бы на стороне передачи. Если у вас один цикл замеров (сколько угодно данных), а потом передача их в комп на обработку - и после этого МК больше ничего не делает, то о конце файла говорить можно. Если данные поступают пусть блоками но переодически и постоянно, то конец файла притянут за уши.
2. Для передачи блочных данных принят термин "пакет" - т.е. последовательность данных, часть из которых служит "обрамлением" для остальных. Например, передаем такой пакет: байт начала пакета -- длина данных (не считая обрамления), сами данные, контрольная сумма. В этом случае комп, получив такой пакет, всегда разберется с тем, сколько данных пришло, правильные ли они (т.е. не потерялись ли) и т.п.
3. Вам не стоит задумываться о физических сигналах в СОМ-порте, надо обдумать протокол взаимодействия - именно он определит, что должен давать МК и как это обрабатывать будет комп.