Arduino.ru

а просто попробовать, пройдёт сквозняком xon/xoff от компьютера в ардуину через уарт при установленном программном управлении потоком, обратно я увидел, что проходит

ну что я должен проверить?

Все эти настройки для КОМ-порта придуманы лет 30-40 назад. Они являются стандартом! А вы мне пытаетесь расскахать, что у вас там что-то принципиально новое? Да я же просмотрел по диагонали вашу ссылку - ничего там нового нет.

Что картинка выше, что ваше описание ВинАпи - говорят об одном и том же. Реализация разная. суть одна. А может и реализация одна и та же.

я не удивлюсь, если настройки на картинке работают через то же АПИ. что у вас.

Так а зачем мне в обратную сторону. Мне нужно только в одну. Ладно , эксперемент рулит. Напишу новый скетч и буду чего нибудь в него отправлять.

b707, то что скорость приколочена гвоздями в том окне настроек и не имеет ни чего общего с реалиями.

это мелочи.

Вы сути не заметили

ua6em вам предложил выставить через эти настройки режим программного flow контроля и посмотреть, будет ли он работать с вашей ардуиной. Если да - значит ошибка в вашем коде на винде. если нет - то на ардуине

b707, это поведение по умолчанию. При записи структуры DCB все значения переопределяются.
Специально для вас - перечитайте пост 44.

В общем нашёл я косяк, но пока не понимаю почему именно так.

Управление потоком я активирую только в одну сторону DCB.fOutX.

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

Когда в исходящем потоке встречаются символы Xoff или Xon всё рассыпается.

еще раз xon/xoff в поток данных вставляет контроллер, если вы его таким образом сконфигурировали, считайте что аппаратно, в ардуине контроль переполнения буфера есть, хардварного контоля потока нет, остаётся только программный, посмотреть - видимо подключиться к пинам rx-tx и писать логическим анализатором и будет всё понятно, если на rx-tx флав есть, а вычитывая из буфера уарта нет, то контроллер уарт в режиме флав и он поддерживается аппаратно иначе, обрабатывать программно...мысли вслух...ежели что я тут не настоящий сталевар )))

Так и я сюда пришёл учится.

выдержка:

fOutX

 

Задает использование XON/XOFF управления потоком при передаче. Если это поле равно TRUE, то передача останавливается при приеме символа XoffChar, и возобновляется при приеме символа XonChar.

А у меня получается, что при передаче символа он теряется внутри cp2101. Предположительно, ещё не проверял, но теряется и Xon когда не было перед этим Xoff

может не теряется, а экранируется? Вы бы поэкспериментировали - послали набор байт, содержащий Xoff - и потом сравнили с принятым

судя по тому, что вы пишете в #44, что флоу-контроль у вас включен по умолчанию - похоже на то, что у вас все настройки имеют инверсное значение.

Тогда все сходится. Изначально контроль включен в обе стороны. Потом вы меняете поле DCB.fOutX и контроль на выходе выключается, а на входе остается включенным. При этом логично, что истема реагирует на символы Xoff или Xon в исходящем потоке..

А вообще, я бы не доверял так статье этого Титова Олега по вашей ссылке. Найдите лучше родное описание функций WinApi на сайте МС-девелоп, а то я что-то почитал и сдается мне, что у Олега может быть перевод с ошибками. Лучше всегда оригинал читать

Вот я лошара, Вы абсолютно правы. В поисках ошибки сам включил экран. На дворе ночь, пошёл спать.

Завтра всё по новой.

господа объясните пожалуйста, где я обосрался

Кусок цикла который посылает данные в порт

unsigned char check = 0;
for (unsigned int i = 0; i < 4; i++)
{
	bdm_port.TxBuffer[bdm_port.TxIter++] = buff[i];
	check ^= buff[i];
	printf("%02X ", buff[i]);
}
buff += 4;
bdm_port.TxBuffer[bdm_port.TxIter++] = check;
printf("%02X send\n", check);
portw();
portr(7);
printf("%02X %02X %02X %02X %02X %C%C\n", bdm_port.RxBuffer[0], bdm_port.RxBuffer[1], 
	bdm_port.RxBuffer[2], bdm_port.RxBuffer[3], bdm_port.RxBuffer[4], bdm_port.RxBuffer[5], bdm_port.RxBuffer[6]);

Кусок цикла в Arduino

Serial.write(Xon);
if (wait(5)) return;
Serial.write(Xoff);

sendbuff[0] = 0x05;
sendbuff[1] = Serial.read();
sendbuff[2] = Serial.read();
sendbuff[3] = Serial.read();
sendbuff[4] = Serial.read();
if (sendbuff[2] == 0x11) sendbuff[2] = 0x01;
if (sendbuff[4] == 0x13) sendbuff[4] = 0x01;
check = Serial.read();
Serial.write(sendbuff + 1, 4);
Serial.write(sendbuff[1] ^ sendbuff[2] ^ sendbuff[3] ^ sendbuff[4]);
if (check != sendbuff[1] ^ sendbuff[2] ^ sendbuff[3] ^ sendbuff[4]) { Serial.print("ER"); }
else Serial.print("OK");

выхлоп

00 01 02 03 00 send
00 01 02 03 00 OK
04 05 06 07 00 send
04 05 06 07 00 ER
08 09 0A 0B 00 send
08 09 0A 0B 00 ER
0C 0D 0E 0F 00 send
0C 0D 0E 0F 00 ER
10 11 12 13 00 send
10 01 12 01 02 ER
14 15 16 17 00 send
14 15 16 17 00 ER
18 19 1A 1B 00 send
18 19 1A 1B 00 ER
1C 1D 1E 1F 00 send
1C 1D 1E 1F 00 ER
20 21 22 23 00 send
20 21 22 23 00 ER
24 25 26 27 00 send
24 25 26 27 00 ER
28 29 2A 2B 00 send
28 29 2A 2B 00 ER
2C 2D 2E 2F 00 send
2C 2D 2E 2F 00 ER
30 31 32 33 00 send
30 31 32 33 00 ER
34 35 36 37 00 send
34 35 36 37 00 ER
38 39 3A 3B 00 send
38 39 3A 3B 00 ER

Почему не работает условие?

Не хватает скобок в 15 строке, почитай про приоритет операций

Эта ошибка была созданием этой темы. Получается XoffXon работает правильно и я пока полагаюсь на 

Serial.write(Xon);
if (wait(40)) return;
Serial.write(Xoff);

 Господа, есть у кого предложения по улучшению концепции?

моё виденье такое(поправте меня):

я использую аппаратные serial(0,5M) и spi(1M). Предполагаю, что встроенный класс Serial использует прерывания, для того что бы успевать принимать данные. На такой скорости прерывания очень короткие, но не нулевые. Стоит ли морочится с паралельной работой или нет? Скорость spi я могу поднять до предела, но линии придётся подтягивать внешне, нет желания.

как обычно заинтересовался странностями и всякие опыты ставил. Сперва по теме ТС, по ней опытов не ставил, ессно! ;))

1. Софтверное управление НЕ РЕАЛИЗОВАНО в Ардуино. Но тебе и не нужно. Если ты ИЗ Ардуино пошлешь Xoff в Винду, то ВИнда, на которой есть реализация XonXoff, остановит передачу, а тебе вроде этого и надо?

2. По скоростям. Вот пример программок для теста, 1000 байт случайно генерятся на Компе и передаются в Ардуинку, откуда возвращаются. В обоих местах считается ЦРЦ, но никак не проверяется... типа был задел на будущее ;)).

Эксперимент показал на Линуксе скорость 720К, на виртуальной Вин10 - 700К, выше сбои. Но тут, я полагаю, разница в виртуальности.

Замену нужно только одну сделать - на Линуксе ком-порт /dev/ttyUSB0 (для Нано на CH340), на винде - COM3: (ну у кого-что ;)) ).

-------------------------------------

Коды программ для тестов. ТС (топик стартер - автор темы), ты прости меня, но для винды у меня готовых сред программирования не стоит. Если будешь проверять, то текст на Питоне - ну очень простой, его легко прочесть. Если бы я под Винду на MinGW (это GCC для винды) написал, тебе бы ведь не стало легче прочесть?

Ардуинка:

#include <stdint.h>
#include <util/crc16.h>

#define TIMEOUT 100000

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  Serial.begin(700000);
}

void loop() {
  static byte buff[1000];
  static uint16_t bPos = 0;

  static uint32_t om = millis();

//Читаем
  while (Serial.available() && bPos < 1000 && millis() - om < TIMEOUT)
    buff[bPos++]  = Serial.read();

  if (bPos == 1000) {
    uint16_t crc = 0;
    for (int i = 0; i < 998; i++) crc = _crc16_update(crc, buff[i]);
    buff[998] = crc & 0xff;
    buff[999] = crc >> 8;
//если прочли - отправляем
    Serial.write(buff, 1000);
    bPos = 0;
    om = millis();

  }
}

Питон

import datetime
import time
import serial
import random


def ucrc16(crc, d):
    crc = crc ^ int(d)
    for i in range(8):
        if crc & 1:
            crc = (crc >> 1) ^ 0xa001
        else:
            crc = (crc >> 1)
    return crc

ser = serial.Serial('/dev/ttyUSB0', 700000, timeout=4)
#com3: for Windows

ba = bytearray(1000)

tryN = 0

while 1:
    tryN += 1
    
    crc = 0
    for i in range(998):
        ba[i] = random.randint(0,255)
        crc = ucrc16(crc,ba[i])
    ba[998] = crc & 0xff
    ba[999] = (crc >> 8) & 0xff
    
    starttime = datetime.datetime.now()
    ser.write(ba)
    endtime = datetime.datetime.now()
    delta = endtime - starttime
    deltam_s = int(delta.total_seconds() * 1000)
    
    starttime = datetime.datetime.now()
    ba_in = ser.read(1000)
    endtime = datetime.datetime.now()
    delta = endtime - starttime
    deltam_r = int(delta.total_seconds() * 1000)
    
    print ("Try # ", tryN, "Received ", len(ba_in), "bytes ",
           "Sent in ", deltam_s, "ms ", "received in",deltam_r, "ms ", 
           "S/R speeds were ",int(10000000/deltam_s),"/",int(10000000/deltam_r),"bod")
    for i in range(len(ba_in)):
        if ba[i] != ba_in[i]:
            print (i,ba[i],ba_in[i])
        
    time.sleep(1)

Для тех, кто станет спрашивать: почему скорость это 10млн делить на время? очень просто Время у меня в мс, а символов 1000, при обычном 8N1, получаем 10 бит 8+1+старт=10 бит на байт. 10тыс бит на 1000 байт. ;)))

Вывод программы:

Try #  10 Received  1000 bytes  Sent in  11 ms  received in 23 ms  S/R speeds were  909090 / 434782 bod
Try #  11 Received  1000 bytes  Sent in  11 ms  received in 23 ms  S/R speeds were  909090 / 434782 bod
Try #  12 Received  1000 bytes  Sent in  11 ms  received in 23 ms  S/R speeds were  909090 / 434782 bod
Try #  13 Received  1000 bytes  Sent in  11 ms  received in 23 ms  S/R speeds were  909090 / 434782 bod
Try #  14 Received  1000 bytes  Sent in  11 ms  received in 23 ms  S/R speeds were  909090 / 434782 bod
Try #  15 Received  1000 bytes  Sent in  11 ms  received in 23 ms  S/R speeds were  909090 / 434782 bod
Try #  16 Received  1000 bytes  Sent in  11 ms  received in 23 ms  S/R speeds were  909090 / 434782 bod

Что забавно? При одинаково выставленных скоростях, расчетная скорость передачи от ардуино в комп - почти вдвое ниже!

=======================

Ну и выводы. Как обычно, для любого посредника, например программатора, нужно принимать и передавать большие объемы. Прием по UART, передача у ТС, как я понял, по SPI? Устойчивая скорость УАРТа - да действидельно - около 500К. Передавать нужно небольшими фрагментами по несколько сотен байт с обязательной проверкой CRC. Потом данные уходят в SPI, и повторяем. Не нужен XonXoff. Придумай свой удобный протокол из пары команд. Типа "Готов принять блок" и "повтори блок - ошибка". Честно говоря больше и не нужно. Можно обогатить программу запросом блоков по номерам, если не записалось что-то уже в целевом направлении.

А если скорость поставить 750000 (на ардуино) PS сам спросил сам ответил
 

Try #  1 Received  0 bytes  Sent in  10 ms  received in 4010 ms  S/R speeds were  1000000 / 2493 bod
Try #  2 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  3 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  4 Received  1000 bytes  Sent in  20 ms  received in 10 ms  S/R speeds were  500000 / 1000000 bod
Try #  5 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  6 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  7 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  8 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  9 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  10 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  11 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  12 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  13 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  14 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  15 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  16 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  17 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  18 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  19 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  20 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  21 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  22 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  23 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  24 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  25 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  26 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  27 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  28 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  29 Received  1000 bytes  Sent in  20 ms  received in 10 ms  S/R speeds were  500000 / 1000000 bod
Try #  30 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  31 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  32 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  33 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  34 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  35 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  36 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  37 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  38 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  39 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  40 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  41 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod
Try #  42 Received  1000 bytes  Sent in  10 ms  received in 20 ms  S/R speeds were  1000000 / 500000 bod

это почему так много?

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

Проверил на своей UNO с CH340 -
Отправляю с ПК через терминал 40 символов,
При приеме первого символа UNO посылает XOFF, но все равно получает 40 символов
Если сначала UNO посылает XOFF, а потом Отправляю с ПК через терминал 40 символов, то ничего не получу, пока не отправлю XON

Если подключаю SoftSerial к переходнику CP2101 и общаюсь через него, то -
Отправляю с ПК через терминал 40 символов,
При приеме первого символа UNO посылает XOFF и получает 2 символа Оставшиеся 38 получает после отправки XON

Потому что usb. Для этого и придумано управление потоком. Получая разрешение передачи, CP сразу начинает скидывать свой буфер в порт. И хранить 512байт легче в аппаратном буфере CP, чем в атмеге. Несогласны?

Bruzzer, а вот это фигово. Я свой код до сих пор подлатать не могу, что бы проверить.

256 байт, если я правильно понимаю реализацию Serial

Ua6em, нет не правильно понимаете. Смотрим по даташиту исходящий буфер в микросхеме. Я уточню , что у меня всё таки cp2102. Ещё есть програмый буфер драйвера, который вы задаёте при открытии порта. Это буфер, который примет данные от вашей программы. Пересылкой данных из этого буфера в чип занимается драйвер без вашего участия.

ну вот и принимай решение! Пробуй, это и есть творчество, бля!!! я бы выбрал или 512 или 1024, для блока. нужно проверять. время -- ты неясно нахера  ты его считаешь. 1 или 2 мс для программатора - похер, ИМХО. в норме все пойдет без перезапросов. или бери другой контроллер.

Почему, почему, да потамучто. Возьми  1мс и SPI на скорости 1М. Сколько байт залезит в SPI? Я уже с этим наигрался, т.к. сначала просто подключал FTDI ногами к целевой плате. После каждого пакета задержка, как ни изголялся, но удалось приблизится только к 1мс. Чтение 16МБ  занимало 7 часов. Вот тебе и 1мс. Взял ардуино и перенёс функцию чтения внутрь, с первого раза получил 12мин, если отключить контрольку, то думаю будет минут 8. А вот функцию записи пока не получается перенести.

я про приёмный говорю (ардуино)

64 байта для устройств с оперативкой более 1к.

господа, застыдите меня, не понимаю, основ.

1) Serial.read() - мне казалось, что дождётся байт и выведет, но если я не использую Serial.available() перед этим, то контролька сразу рассыпается.

Каково поведение метода read()?

2) отключил всё управление потоком, все припенания в коде, со стороны spi подключен логический анализатор, который показывает, что вызов wait(40) выполняется 6.7милисекунды, на скорости 500000 - Что за полная фигня??? Я вроде считать не разучился  и 40байт 

должны передаться за:

1c / 500000бод * (40байт * 10бод\байт) = 0.0008с = 0.8мс

В чём прикол???

по второму вопросу разобрался. Дело всё в той же задержке по USB. Я слал данные в порт с ПК по 5 байт. Вот и накапливалась задержка, собрал пачку, и всё встало на свои места. 

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