Arduino.ru

можно, но ошибка в ваш софт.

Берите про мини и подключайте к ней ftdi и будет счастье

Подготовьте тест, который не нужно полдня проводить, я запущу его и на FTDI и на нескольких CH340 .

А вообще - драйвера FTDI автоматически ставятся, их отдельно не нужно накатывать. Отсюда можно сделать предположение, что совместимость с Windows у них лучше.

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

SergeiSX, вам же в той теме уже растолковали что не может мега быстро работать на высоких скоростях сериала, или нет?  Гипотетическая максимальная скорость UART в меге =  F_CPU / 8, но это касается байта, который уже сидит в регистре данных и ждёт пинка под зад. На любые другие процедуры МК будет сильно отвлекаться, и фактическая скорость упадёт в разы, что вы и наблюдали.  Про 3 Мегабода надеюсь понятно, если это и возможно, то не на AVR.

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

Спасибо. Но про мини нет под рукой.

можно и на Нано.

Все как вы сказали - берете внешний Уарт на FTDI, подключаете пины данных к 0 и 1 нано. Питание на Нано не "внешнее", а с пинов питания от FTDI - подключаете на 5в и GND Нано.

Если опираться на Вашу формулу то при частоте кристалла в 16 МГц гипотетическая максимальная скорость будет 2 мегабод. Стало быть 1 мегабод это тоже возможно или нет ? По поводу любых других процедур, нету их в моем тесте. Только обработка прерываний как раз для UART. Пускай это замедлит ещё в два раза (хотя вряд ли ) Хотя бы 50 килобайт я могу получить в секунду если рассматривать задержки только на кристалле при всех ранее оговоренных условиях ?? Или даже при отсутствии любых других операций не получится ??? Вот все же проблема в драйвере на ПК. И ещё вопрос, с каких это пор протокол RS-232 стал пакетным ? Он всегда был байтовым. Или даже поточным. Какого бы не реального времени ни была Windows но у меня на машине работает адаптер для протокола CAN как раз через USB и на скорости как раз Мегабит в секунду. Как это объяснить ?? А он ведь тоже последовательный и даже пакетный протокол.

Спасибо Вам большое за предложение. Я пока попробую своими силами и буду иметь в виду Ваше предложение.

Спасибо Вам Большое !

Даже если в вашем тесте "ничего кроме Уарт нет" - в МК все равно вызываются как минимум прерывания по таймеру0...

это я к тому, что работая из Ардуино ИДЕ - вы не можете быть уверены, что в МК работает только ваш код

Согласен с Вашими аргументами. Но проверить все равно хочу. Думаю при установке скорости в 1 мегабод 2 килобайта в секунду слишком мало.

А если найду? :) Вот посмотрите дизассемблированную функцию Serial.flush

void HardwareSerial::flush(){
 30a:	cf 93       	push	r28
 30c:	df 93       	push	r29
 30e:	ec 01       	movw	r28, r24
 310:	88 8d       	ldd	r24, Y+24	; 0x18
 312:	88 23       	and	r24, r24
 314:	c9 f0       	breq	.+50     	; 0x348 <_ZN14HardwareSerial5flushEv+0x3e>
 316:	ea 89       	ldd	r30, Y+18	; 0x12
 318:	fb 89       	ldd	r31, Y+19	; 0x13
 31a:	80 81       	ld	r24, Z
 31c:	85 fd       	sbrc	r24, 5
 31e:	05 c0       	rjmp	.+10     	; 0x32a <_ZN14HardwareSerial5flushEv+0x20>
 320:	a8 89       	ldd	r26, Y+16	; 0x10
 322:	b9 89       	ldd	r27, Y+17	; 0x11
 324:	8c 91       	ld	r24, X
 326:	86 fd       	sbrc	r24, 6
 328:	0f c0       	rjmp	.+30     	; 0x348 <_ZN14HardwareSerial5flushEv+0x3e>
 32a:	0f b6       	in	r0, 0x3f	; 63
 32c:	07 fc       	sbrc	r0, 7
 32e:	f5 cf       	rjmp	.-22     	; 0x31a <_ZN14HardwareSerial5flushEv+0x10>
 330:	80 81       	ld	r24, Z
 332:	85 ff       	sbrs	r24, 5
 334:	f2 cf       	rjmp	.-28     	; 0x31a <_ZN14HardwareSerial5flushEv+0x10>
 336:	a8 89       	ldd	r26, Y+16	; 0x10
 338:	b9 89       	ldd	r27, Y+17	; 0x11
 33a:	8c 91       	ld	r24, X
 33c:	85 ff       	sbrs	r24, 5
 33e:	ed cf       	rjmp	.-38     	; 0x31a <_ZN14HardwareSerial5flushEv+0x10>
 340:	ce 01       	movw	r24, r28
 342:	0e 94 1d 01 	call	0x23a	; 0x23a <_ZN14HardwareSerial17_tx_udr_empty_irqEv>
 346:	e7 cf       	rjmp	.-50     	; 0x316 <_ZN14HardwareSerial5flushEv+0xc>
 348:	df 91       	pop	r29
 34a:	cf 91       	pop	r28
 34c:	08 95       	ret

Надо ещё принять во внимание, что половина этих  команд занимают 2 такта МК.   И сериал.принт  не меньше выйдет. В скетче вы уже считаете время микросом, а МК нужно отстрочить сотни тактов что-б всю эту передачу организовать.  Накладные расходы времени идут везде, да  просто положить значение микроса в переменную -как минимум 8 тактов МК. Так что с мегой нет никакого смысла работать на скоростях выше 115200, плеваться из уарта быстро она сможет, но вот "собирать слюну" будет долго :)

 

Ну не знаю, как вы считаете... на моем калькуляторе задержка в "200 с копейками микросекунд" на символ как раз и дает порядка 4кбайт скорость передачи.

А у вас в эксперименте получается 2к - что в принципе то же самое.

Ну вообще 200 микросекунд на 4 символа. Так что должно быть немножко быстрее.

 это если посылать по 4 символа.

А если посылать по одному - то будет 200 мкс на символ.

Но так или иначе - 50к, которые вы ожидаете - тут даже близко нет.

Я понял. Спасибо !

Смотрите скрин видно время приема байты 123456789+0Dh+0Ah. Через интервал 20 миллисекунд чипконтроллер отправляет строка из 12 байт, скрорость 2 Mbps.Софт Serial Port Monitor имеет значение stopwatch, с того софт получает запрос от драйвер. Драйвер работает хорошо.
Согласна со своими уважаемыми коллегами!

https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-irp-major-function-codes

Спасибо Большое! Я увидел что если отправлять через 20 миллисекунд то все отображается, но понимате, мне надо отправлять свои уведомления будет в боевом режиме возможно через 2 миллисекунды. И я все таки хотел бы увидеть максимальную скорость при отправке от чип-контроллера без задержек. Я правильно Вас понял что у драйвера минимальная задержка составляет миллисекунды ?

Я немножко устал читать всякие глупости. Нано аккуратно работает с портом и скрость совершенно нормальна.

Вот специальная программа.

Программа готовит 1000 байт случайных, ждет подтверждения о готовности приема и отсылает их в комп. Куски по 20 - это просто так, можно любые куски, можно и всю 1000, это просто опыты. Два последних байта - CRC. Комп проверяет CRC и отсылает GOOD обратно. На что ардуинка отсылает посчитанную статистику.

Скорость = 10 миллионо / время в мс. Потому, что в передаваемом байте 8 + старт + стоп = 10 бит.

вот программа для ардуинки:

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

byte dd[1000];
char ss[10];

void setup() {
 Serial.begin(1000000);
 while (!Serial);

}

void loop() {
  //static uint32_t om = millis();
  uint32_t nm, tm;

  int i;
  uint16_t crc=0;

  for(i = 0; i < 998; i++) 
     {
      dd[i] = random(255);
      crc = _crc16_update(crc, dd[i]);
     }

  dd[998] = crc & 0xff;
  dd[999] = crc >> 8;


  Serial.print("START");
  nm = millis();
  while (millis() - nm < 2000)
    if (Serial.available()) break;
  if (!Serial.available()) return; 
  i = 0;
  while (Serial.available()) ss[i++] = Serial.read();
  nm = millis();
  for (i = 0; i<1000; i+=20)
     {
      Serial.write(dd+i,20);
      Serial.flush();
     }
  while (millis() - nm < 3000)
    if (Serial.available()) break;
  if (!Serial.available()) 
    {
      Serial.println ("Transfer error END");
      return;
    } 
  if (!Serial.find("GOOD"))
    {
      Serial.println ("Transfer error END");
      return;
    } 
  tm = millis() - nm;
  Serial.println("=======");
  Serial.print ("Total time (ms):");
  Serial.println((int)tm);
  Serial.print ("Transfer rate(bod):");
  Serial.println(10000000.0/tm);
  Serial.print ("END");
  delay(1000);
}

Вот программа на Питоне. Имя порта там от Линукса, так как Виндоусом я не пользуюсь, только в виртуалках, а это будет не сильно репрезентативно.

Перечитал и решил, что некоторым может быть непонятно - на винде просто написать "COM7:" в смысле не именно7, а тот порт, накотором нанка.

import datetime
import serial


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', 1000000, timeout=4)

while 1:
    print 'Go on!'

    ff = '01234'

    while 1:
        ff = ff + ser.read(1)
        ff = ff[1:6]
        if ff == 'START':
            break

    ser.write('GO')
    starttime = datetime.datetime.now()
    bd = bytearray(ser.read(1000))
    endtime = datetime.datetime.now()
    delta = endtime - starttime
    deltam = int(delta.total_seconds() * 1000)
    crc = 0
    for i in range(998):
        crc = ucrc16(crc, bd[i])
    crcIn = (bd[999] << 8) + bd[998]
    print 'crcs:'
    print crc
    print crcIn
    if crc == crcIn:
        print 'GOOD'
        ser.write('GOOD')
    else:
        print 'BAD'

    ff = '123'
    dd = ''
    while 1:
        a = ser.read(1)
        dd = dd + a
        ff = ff + a
        ff = ff[1:4]
        if ff == 'END':
            break
    print dd
    print  'Trasfer time local =',deltam
    print 'Transfer rate local =',10000000.0 / deltam

Два последние строки статистики - локальная для компа, по тексту программы видно, что берется время ТОЛЬКО приема 1000 байт.

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

Вот вывод на моем Линухе и Нанке:

Running: /home/wlad/Python/SerialTest.py (Tue Oct  9 00:00:26 2018)

Go on!
crcs:
46708
46708
GOOD
=======
Total time (ms):13
Transfer rate(bod):769230.75
END
Trasfer time local = 11
Transfer rate local = 909090.909091

Программа закручена в бесконечный цикл. Есть косяк - нанку мне иногда приходится "передергивать" кабелем. Искать причину - лень. Нужно ловить эксепшены или ошибки передачи в Питоне. Мне было не надо. Тест делает, что просят, в космос его не запускать.

Еще забавный факт - Леонардо дает от 11  до 20 мс на этом тесте ВНЕ ЗАВИСИМОСТИ от установленной скорости порта, то есть даже на 115200. Но там не /dev/ttyUSB0, а /dev/ttyACM0, что совершенно другой драйвер. Этому драйверу насрать на скорость.

не имела написать глупости. Просто желала сказать, драйвер работает и ошибка в софт от TS

Я не про тебя. Я про ТС.

Dear sir, wdrakula! Thank you & Good Luck to you!

То есть если я правильно Вас понимаю то в putty тоже ошибка ?? Я смотрел исходник putty там тоже самое что и у меня.

[quote=wdrakula]
Спасибо Вам за развернутый ответ. Но меня интересовала ситуация именно в Windows и именно для коротких сообщений. По поводу передачи из платы в комп и у меня получалась приличная скорость. Уверен если Вы возьмёте QNX результат будет очень хорош))) В другой теме я писал что в зависимости от длины сообщения скорость меняется в Windows. А значит имеет место передача пакетная. Тест мой заключается в передаче двух байт и приеме этих двух байт обратно. Замеряю время именно это транзакции. Точнее трехсот транзакций. Поправьте если так делать нельзя. Возможно необходимо замерять скорость именно одной транзакции но тут уже нужно использовать rdtsc видимо.

И ещё, я просто спокойно задаю вопросы) Поэтому предлагаю не писать про глупости друг друга а вести себя корректно )

OK! So, I kindly ask you to keep using english when writing to me. It is easier to read english than brain breaking, bad russian! Not be offended, keep smiling!

Господа, я действительно с Ардуино не так давно работаю. Но не думаю что это повод для хамства ) Думаю что в любой ситуации возможно нормальное уважительное общение. Ну а с быдлом приходится общаться на его языке.. Тем не менее скандалы не люблю.

Я понимаю... Но хамства не терплю. Тем не менее остальных людей здесь прошу меня извинить.

Извини дорогой, но ты ошибся форумом и достаточно сильно. Тут как ты пишешь "хамящего быдла" - около 80% завсегдатаев. Щас, ближе к вечеру в гейропе понабегут и остальные. Просто полистай темки и найдешь одни и теже рожи..

(если бы они на самом деле хоть чего-то ещё и умели..)

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

Ну и по поводу Ардуино. Прекрасная плата, которая очень нас спасла по работе. Надо было быстро протестировать одну вещь и это удалось.

ТЫ про непрошенные советы не понял? Или с папкой не знаком, как я и подозревал?

Ты сам выбрал дорогу хамства, первым и добровольно. Наслаждайся!

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

Я тебе показал, максимально доказательно, что железо, как и положено, работает в соответствии с даташитом.

Любой, кто пишет "китайское говно" - дурак по определению. Микросхема, китайская, может либо не работать, быть поддельной, отбракованной, но если работает, то в соответствии с даташитом. Так как микросхема  - копия фирменной. Китайцы не разрабатывают лейаут контрофактных микросхем сами ...по понятным причинам. Хотя, ты врядли поймешь.

А раз железо работает как нужно - все остальное в голове програмиста.

Если бы ты пришел на форум с вопросом: "Господа, мне нужно отправлять некие коды от Ардуино на комп каждые 40 мкс (Два байта и скорость 50 Kbps, как ты писал), получится?" - тебе бы ответили, что  получится, если очень аккуратно писать код. Возможно многое придется оптимизировать на ассемблере. 40 мкс - это всего 640 команд, причем 10 из них уйдет на отправку самих двух байт.  Если одновременно принимать подтверджение, то важно понимать, возможен ли неблокирующий режим. И так далее...

...

Мда. Но ты пришел на форум с заявлениями, что у тебя "железо не так работает"... получи, что заслужил.

А зайчика за какие достижения лишили модераторской кнопки, не напомнишь?  Что ты умеешь - ты уже в "Меге с памятью" показал! "Все в восхищении!". А то, что я - хамло, я и не скрывал никогда.

У меня IQ 160 и МехМат МГУ в далеком 91-ом закончен, мне похеру - хамло я или нет. Я в любом случае доказательно и объективно умнее. Мне это важно. Тем, кому я помог - тоже. Если помогая я нахамлю - у человека выбор: терпеть и получить результат, или ходить в говне, но гордым...Гы! Есть такие, как ТС, ему важно быть гордым - да ради Б..га! Мне только веселее.

Ну во - первых, я уже написал выше что очень доволен платой. Во вторых, я всего лишь пытался разобраться рассматривая все варианты. И я первым делом стал грешить на свой код в Windows, но посмотрев исходники putty, понял что они делают то же самое практически. Сейчас переписав свой код без использования String я получил время приема и соответственно отправки строки из двух символов 8 и 10 микросекунд соответственно что вполне соответствует скорости задаваемой. Поэтому предлагаю перестать ругаться. Я как раз с самого начала сомневался именно в Драйвере для Windows а не в самой плате !!! И подсоединить микросхему FTDI хотел именно для того чтобы в системе заработал другой драйвер ! Я грешу на Windows а не на плату. Видимо меня неправильно поняли.

Девочки, не ссорьтесь, Б-ТЬ!

Я как раз хочу мира )))

И да, несмотря ни на что я открыт для контактов. Признать мое право хамить - можно в любой момент, и я продолжу думать над задачкой, если она все еще будет мне интересна... а это непредсказуемо (поэтому я за деньги и не работаю) ;).

ОК. Я поставлю щас вынь8 на виртуалку, чтобы было похоже... или какая у тебя Винда? Чтобы эксперимент был чистым.

Но я заранее верю в виндоус ;). Это плохая ОС, но не качеством кода, а только понтами и платностью.

Зайчик щас опять соскочит, что все вокруг - говно, один он д'Артаньян. Ему и на форуме Амперки прямо в глаза говорили, что таких зайчиков к детям - на милю подпускать нельзя. Есть такая порода людей, называется - кругом обосрамшись, предлагаю дать им нарицательное имя - архаты :)

У меня Windows 7 x64. Пишу с телефона поэтому не могу привести код для Ардуино. У меня теперь просто буфер. Использую функции Serial.readBytes и write. Посмотрел их код вроде бы ничего лишнего( я понимаю что не ассемблер но все же). На Винде использую событийную модель waitcommevent и так далее.

Да еще, на Ардуино просто принимаю два символа и отсылаю обратно.

Вот ведь все равно все клещами вытягивать надо!

Смотри - Ардуинка работает правильно и предсказуемо. Все лишнее всегда можно причесать на асме.

Поставь СВОЮ задачу: раз во сколь-ко мкс нужно передать код и что? ждать подтверждения? Откуда сам код? и т.п.

Нельзя подходить: "а как быстро оно вообще может работать?" - НЕЛЬЗЯ!

Нужно четко понимать, под какое количество времени подстраиваться с каким кодом?

Тут многие считают свои придумки - ахеренно секретными ;) Так вот это смешно... но в этом случае адекватно замени важные тебе секреты на аналогичный, по функционалу, код. Ну как-то так.

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

Критика принимается. Задача в том чтобы управлять с Ардуино двумя двигателями шаговыми и обратно получать уведомления на комп в какой позиции двигатель сейчас находится. Уведомления поступают только при вращении и через каждые 11 позиций. То есть где то через градус. Плюс ещё уведомления об успешном исполнении команды которую послали двигателям и уведомление об окончании движения. Двигатель имеет 4096 позиций с учётом редуктора. Так что при скорости даже в 70 градусов в секунду время между двумя шагами составляет около 1,2 миллисекунды. То есть в реальной задаче большого траффика не предвидится. Единственно с разницей в два два шага могут прийти уведомления об успешности команды и о достижении очередной позиции кратной 11 шагам.

Собственно я отключил само вращение и задал для двигателей нереальную скорость в 300 градусов в секунду чтобы протестировать всю систему в стрессовом режиме. И столкнулся с тем что в виндосовской части уведомления стали запаздывать. Это и побудило начать исследовать предельные характеристики.

Понял...

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

Так.

1.Как я понял, ты хочешь в реалтайме реагировать виндой на положение ШД? Вообще не получится, только на низких скоростях.

2. Дело пойдет чуть лучше, если на винде ты дашь почти максимальный приоритет своей программе.

3. И собственно на чем ты ее пишешь? Это программу.

4. И что ТОЧНО должна делать ардуинка? с таймингами, плиз.

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

Микроконтроллер, как раз и используют, чтобы увести большой комп от синхронного режима работы, поскольку на нем не РТ ОС.

То есть грамотно - заранее предполагать, что комп не сможет ответить в реалтайме. Я понятно излагаю? В комп можно счто-то скинуть, из него можно получить задание, но если хочется, чтобы именно он двигал рабочий инструмент - можно, есть же программы для CNC и Виндовые и Линуховые. Но там работают на уровне ОС, для обеспечения подобия реалтайма... до известных пределов.

Пока не станет ясно, как ты пишешь для Винды - не ясно, какие решения имеет задача.

Понял. Отвечаю на вопросы. Программу пишу на данный момент на Дельфи. Но вполне могу написать и на C++. Ардуино должна принимать команды на вращение пока по задумке текстовые. Время отработки команды не лимитировано строго но желательно вращать хотя бы на 10 градусов за секунду. То есть сейчас в Ардуино присутствует блок обработки команд от компа и блок вращения ШД. Причем ШД вращаются через заданные интервалы времени на один шаг. Интервалы вычисляются исходя из заданной скорости в градусах в секунду. Как только шаговик приходит в нужную позицию в комп шлется уведомление что вращение окончено и само вращение прекращается. Главная задача состоит в том чтобы из программы на Винде давать команду двигателям перемещаться в нужную позицию, дожидаться уведомлений об окончании вращения. Измерять в данной позиции звуковую мощность и повторять процесс для всех заданных позиций.

На Винде использую асинхронные режим работы с Com портом через ReadFile и WriteFile. Ну и WaitCommEvent, ClearCommError, GetOverlappedResult.

Trinamic делает так: ставит на мотор с энкодером контроллер с мощным процессором (они их заклеивают, а частично какой-то эпоксидкой еще заливают, но где-то я читал, что не слабже STM32), который следит за командами по RS-485 (например). Исполняет их и взаимодействует с энкодером. Т.е. PC может дать команду - повернуть на 32 градуса и сам контроллер этим займется. При движении, в обратную сторону по 485-му летят данные - скорость и позиция энкодера. Во всяком случае их софтина рисует разгонную кривую и тормозной путь. Не скажу, что рисует в рилтайме, отставание какое-то есть. Для серьезных применений у них имеется TMCL. Пишешь на нем программу, заливаешь на контроллер и он сам сутками хоть кривые выписывает, хоть резьбу с переменным шагом нарезает.

А тринамик-то в двигателях понимает.

Бля, ну и охота ж людям херней страдать?!

Ну допустим, захотелось культурному и грамотному челу узнать что в плане скорости может ftgi и ch340. Какого для этого срач на форуме  городить и кривые опыты ставить. Открой бля доки!

Все видно? Чё там еще в твоем никчемном канале обмена? Атмега - те сказали, максимум CLK/8. Толко надо правильные мозги иметь чтоб столько получить. USB - так если ты такой продвинутый по работе с ним должен знать о его режимах и ограничении скорости в CDC. А винда ниграме не реалтайм, она не обязана сообщать точное время прихода каждого байта, буферирует как считает нужным. Но над фактом того что в этот же разем USB вставленая флешка работает побыстрей чем цифры выше, можна и задуматся чтоб решить надо ли винду тестить.

Отсюда вывод: у ТС будет тормозня в атмеге т.к.  хрен напишеш код, приближающийся к её максимуму. На этом и остановимся, поскольку для способных выжать те самые CLK/8 это все не интересно, а ТС не актуально.