что кидать в COM с мк, чтобы нормально считать программой

[dmitryk1]

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

Да. именно так. сбор данных - 1/10 секунды потом передача Всех полученных данных. Новые игнорируются. Я бы не против получать вообще все данные потоком , но компорт такого не осилит. Я прикидывал, тна скорости 128000 бод в принципе можно уложиться, но это предельная скорость компорта потому не уверен в работоспособности полученного устройства.

...сами данные, контрольная сумма.

Ну в данном случае мне достаточно посчитанных пакетиков по три байта: заголовок+порядковый номер+3 Б данных + возможно контрольный байт. Но! Передаваться будет ввиде битов и я возвращаюсь к началу: какая техническая инфа там идёт...
сначала идёт 1 это тишина.
потом 0.
потом пошла передача. потом
заголовок+порядковый номер+3 Б данных + возможно контрольный байт
потом байт конца файла?
потом 0 и 11111111111 ->тишина?
[/quote]

не стоит задумываться о физических сигналах в СОМ-порте

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

Ну читаю литературу, может что-то прояснится...

[Alexey_B]

ещё разок вдумываемся в то, что вам написали.

вот настройка вашего ком-порта

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

dcb.BaudRate = 9600;
      dcb.ByteSize = 8;
      dcb.Parity = NOPARITY;
      dcb.StopBits = ONESTOPBIT;

если вы uart мк настроите на те же параметры (как это делается, см. даташит). То все остальное просто. UDR='a' и вперед, символ 'a' будет получен на принимающей стороне без всякой фигни из серии какой бит стартовый, какой стоповый, что за биты придут в программу. ReadFile считает именно 'a'.

[ARV]

Давайте раз и навсегда определимся с данными. Почему вы упoрнo твердите о передаче БИТОВ??? Повторяю еще раз: вы из МК выдаете байт ---> он доходит в комп. КАК он это делает - вас не должно интересовать!!! Для того и реализован UART аппаратно, чтобы не маяться с битами! Если у вас результат замера содержит, предположим 20 БИТОВ, то вы просто передаете 3 байта - и все!!!
Объясните общественности: зачем вам надо знать физику передачи битов?!?!

Но если уж так интересно, то физически сначала 1 в линии - это тишина, потом передается 0 - это старт, начало передачи БАЙТА, затем идут 8 (или 9 - в зависимости от настроек порта) БИТОВ ДАННЫХ, затем передается обязательно одна или 2 единицы - это стоп. Все, после этого в линии снова тишина (т.е. 1) до начала передачи следующего байта. Конец файла - это символ, который должен сформировать ваш МК или кто-то там еще - обратите внимание, этот символ имеет отношение к ПРОТОКОЛУ ОБМЕНА ВЕРХНЕГО УРОВНЯ, а не физическому протоколу обмена битами!!! Если вы придумываете свой протокол обмена, то конец файла в принципе вам не нужен!!!
Похоже, вы зачитались литературой и получилась некая каша из информации... Надо ее расхлебывать

[dmitryk1]

Давайте раз и навсегда определимся с данными. Почему вы упoрнo твердите о передаче БИТОВ???

Отвечаю. Человек, который любезно согласился помочь мне с электронной частью оперирует битами. Априори он лучше меня разбирается в МК, поэтому советов перейти на другой МК или использовать что-то дополнительно я не хочу. да и не буду. В конце-концов он тратит на это своё свободное время. (это не наезд, а объяснение со своими знаниями я могу только разветвители для наушников паять, которые кстати работают )

выдаете байт ---> он доходит в комп. КАК он это делает - вас не должно интересовать!!!

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

Объясните общественности: зачем вам надо знать физику передачи битов?!?!

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

Но если уж так интересно, то физически сначала 1 в линии - это тишина

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

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

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

-на мк стоит 1. передача не идёт

-я запускаю чтение файла на компе.

-жму кнопку на мк.

-мк передаёт побайтно по протоколу описанному ранее (
0 - байт побитно 01010101 - бит чётности - 1 - 1 - единиц может быть много.)

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

-последним передаётся байт 0xff который нужен функции readfile() для завершения чтения блока. Хотя в данном случае мне можно использовать размер буфера.

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

В общем вот такая получается котовасия

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

[ARV]

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

Однобитный он у вас какой-то
В общем, пока мысль у вас идет в верном направлении, желаю удачи! Только задумайтесь над концом файла: а если где-то посередине ваших данных попадется байт FF?

[dmitryk1]

Однобитный он у вас какой-то

Не, он просто устройства самостоятельные делает. без компортов.

желаю удачи! Только задумайтесь над концом файла: а если где-то посередине ваших данных попадется байт FF?

О! Спасибо за подсказку, я этот момент выпустил. буду контролировать при выдаче и в случае совпадения уменьшать на 1. данные аналоговые, на общую картину не повлияет