STM32F4 USART посылка данных, Не отсылаются все байты Опции

[BlackOps]

вот моя настройка УСАРТ:

CODE

uint32_t config_usart3(void)
{

//=============================================================================
// USART3 Related configuration
//=============================================================================
// enable clock
RCC->APB1ENR |= RCC_APB1ENR_USART3EN;


// 1) Setting UE, amd M bits
USART3-> CR1 |= 0x2000; // UE = 1

// 2) Programming number of stop bits if needed


// 3) Enable DMA if needed


// 4) set the Baud Rate
// BAUD = fck / ( 8 * (2 - OVER8) * USARTDIV )
// fck = 42MHz,
// OVER8 = 0
// Choose BAUD = 115200
// then: USARTDIV = fck / ( 8 * (2 -OVER8) * BAUD = 22.75
// BRR = (22 << 4) | ( 0.75 * 16) = 364,
// or: BRR = fck / BAUD = 42MHz / 115200 = 364
USART3->BRR = 364;


// enable transmitter
USART3->CR1 |= USART_CR1_TE;

// enable receiver
USART3->CR1 |= USART_CR1_RE;

return 0;
}

а вот собственно код отсылки:

CODE

uint8_t mem_read_gyro(USART_TypeDef *USART_ID )
{

int i=0; // loop var


//send read buffer to USART
for(i=0;i<=17281024;i++)
{
// check if TXE bit is set
while((!(USART_ID->SR & USART_SR_TXE)) );


USART_ID->DR = 0x5d;//mem_gyro_buf[i]; // sending a byte
// check if TC bit is set
while((!(USART_ID->SR & USART_SR_TC)) );

}



return 0;
}

как видите проверяю TC и TXE, цикл ожидания бесконечный, так что если с битами была бы проблема код застрял бы на цикле. Но в моем случае вся функция исполняыется в коде успешно, но когда проверяю на компе то программа регистрирует меньшее количество байт например: 15 547 966(столько же байт и вижу в бинарном файле), а должно 17 281 024 байт.

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

в чем тут еще может быть проблема? вот настройки терминала:
Baud:115200
DataSize: 8
parity: none
Handshake: off
mode: free


что тут еще может быть нетак?

Сообщение отредактировал IgorKossak - May 26 2013, 18:27

Причина редактирования: [codebox] для длинного кода, [code] - для короткого!!!

[Flexz]

А что именно на принимающей стороне? какая ОС, com-порт настоящий или перходник?
PS проверка TC - в данном случае излишество, достаточно TXE проверять.

[BlackOps]

вот кабель который я использую, USB-FTDI cable :
http://www.ftdichip.com/Support/Documents/...232R_CABLES.pdf

вот утилита которой пользуюсь:
http://www.hw-group.com/products/hercules/index_en.html

ОС: WinXP



2 IgorKossak : мой код не такой длинный, я специально поставил его в [code] чтобы было лучше видно!

[BlackOps]

я решил проверить какое минимальное количество байт посылается без проблем, так вот до 500 000 байт когда посылаю то доходят все, сли скажемпошлю 600 000 байт то я теряю байты.

я решил внедрить функцию CTS/RTS на стм32, ну и включил ее в программе терминала.

так вот, опять не получается послать надежно даже 600 000 байт.
теперь я заметил почемуто что принимаю всегда именно 597 953 байт! вместо 600 000 байт

вот конфигурация порта:

CODE

//=============================================================================
// GPIOD configuration
//=============================================================================
// enable GPIOD clock
((RCC_TypeDef *)(RCC_BASE))->AHB1ENR |= RCC_AHB1ENR_GPIODEN;


// Alternate Function
((GPIO_TypeDef *)(GPIOD_BASE))->MODER |=
(GPIO_MODER_MODER9_1 | // Alternate Function, USART3_RX
GPIO_MODER_MODER8_1 | // Alternate Function, USART3_TX
GPIO_MODER_MODER11_1 | // Alternate Function, USART3_CTS
GPIO_MODER_MODER12_1 // Alternate Function, USART3_RTS
);

// Output type
GPIOD->OTYPER = 0;
//((GPIO_TypeDef *)(GPIOD_BASE))->OTYPER |= //0;// push-pull if 0
//(
//GPIO_OTYPER_OT_11 // Open-Drain, I2C1, SCL
////GPIO_OTYPER_OT_9 // OPen-Drain, I2C1, SDA
//);


// Speed type
((GPIO_TypeDef *)(GPIOD))->OSPEEDR |=
(GPIO_OSPEEDER_OSPEEDR8_1 | // USART3 TX 50 MHz
GPIO_OSPEEDER_OSPEEDR9_1 | // USART3 RX 50 MHz
GPIO_OSPEEDER_OSPEEDR11_1 | // USART3 CTS 50 MHz
GPIO_OSPEEDER_OSPEEDR12_1 // USART3 RTS 50 MHz
);


// Push/Pull for USART3
GPIOD->PUPDR = 0;
((GPIO_TypeDef *)(GPIOD_BASE))->PUPDR |=
(
GPIO_PUPDR_PUPDR8_0 | // Pull-Up, USART3 TX
GPIO_PUPDR_PUPDR9_0 | // Pull-Up, USART3 RX
GPIO_PUPDR_PUPDR11_0 | // Pull-Up, USART3 CTS
GPIO_PUPDR_PUPDR12_0 // Pull-Up, USART3 RTS
);


((GPIO_TypeDef *)(GPIOD_BASE))->AFR[1] |= (
(7 << ((8 - 8) << 2)) | // USART3 TX, AF7
(7 << ((9 - 8) << 2)) | // USART3 RX, AF7
(7 << ((11 - 8) << 2)) | // USART3 CTS, AF7
(7 << ((12 - 8) << 2)) // USART3 RTS, AF7
);

[Genadi Zawidowsk...]

Попробуйте мою терминалку.
Настройки - Alt+F3. Начало записи файла - Alt-F4, завершение - ALt-F5. Режим поставить fast text.

А может и FTDI от себя подарочек подложить... Мне пришлось в одном проекте перейти на использование специфической FTDI-шной библиотеки, чтобы избежать ОЧЕНЬ редкого искажения данных, принимавшихся через FT2232H на скорости 3 бегабита в секунду. Искажение данных зависело от загруженности машины. Переход на D2 lib избавил от проблем.

Сообщение отредактировал Genadi Zawidowski - May 26 2013, 21:54

[BlackOps]

не могу запустить программу Вашу, говорит:
telnet32 is not a valid windows 32 application

[Genadi Zawidowsk...]

Похоже было обе 64-х битных версии... Скомпилировал-выложил под win32.

Сообщение отредактировал Genadi Zawidowski - May 26 2013, 21:56

[BlackOps]

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

[BlackOps]

я просто не понимаю в чем еще там может быть проблема?

так вот, я обновил драйвера, скачал с ФТДИ, теперь, примерно из 7 раз 3-4 раза получается передать все 600 00 байт, а так опять пропускается примерно 1000-2000 байт каждую транзакцию!

я не понимаю в чем еще может быть проблема?

раз после скачки обновленного драйвера стало хотябы иногда отсылатся нормально так значит всетаки проблема в драйвере?

не могли бы вы поделится каким именно драйвером пользуетесь?

[BlackOps]

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


Но в моем примере сейчас я ведь Отправляю данные, а не принимаю.
Я не понимаю почему при отправке данных не всегда все данные доходят до терминальной программы? (опять таки цикл отправки нормально завершается и не застревает!)

[Golikov A.]

буфер со стороны компа где то килобайта 2. Какие буферы в преобразователе порта не известно. Почему вас удивляет возможность переполнения этого буфера?

Возьмите 2 компьютера, или возьмите один компьютер и на преобразователе 2 и 3 ножку замкните, режим эхо. И с компа пошлите вашу посылку посмотрите сколько придет. Исключив проц из системы сразу поймете если проблемы в драйвере!

[BlackOps]

я сейчас сделал именно так как вы сказали, соеденил ножки 2-3, затем я создал один файл с количеством 600 001 байт.

и в терминальной программе (правда без режима CTS/RTS, но на той же скорости 115200) прогнал этот файл, а взамен получил 593 857 байт, это делает гдето 6 144 байт разницу.

дело в том что когда посылал данные с стм32 то я получал когда как, иногда все 600 001 а иногда:
591 809
593 857 (как в случае с тестом)
597 953
итд.

т.е. выходит так и есть? причина не в моем коде или каком то неверном методе отправки данных с стм32, а просто то что буфер компа/переходника переполнен?

мне просто нужно много байт (32МБайт примерно) отослать на комп, то что долго ничего, главное чтобы каждый байт до единого пришел.

какой тогда метод будет относительно надежен для отправки большого количества данных с стм32 по УСАРТУ?
например отправлять 256 байт и ждать? если да то сколько времени примерно ждать надо (так чтобы на многих компах работало)?

[DmitryM]

я сейчас сделал именно так как вы сказали, соединил ножки 2-3, затем я создал один файл с количеством 600 001 байт.
и в терминальной программе (правда без режима CTS/RTS, но на той же скорости 115200) прогнал этот файл, а взамен получил 593 857 байт, это делает гдето 6 144 байт разницу.

А с контролем RTS/CTS такой же результат? Или Xon/Xoff?

какой тогда метод будет относительно надежен для отправки большого количества данных с стм32 по УСАРТУ?
например отправлять 256 байт и ждать? если да то сколько времени примерно ждать надо (так чтобы на многих компах работало)?

Без контроля потока будет ненадежно.

[BlackOps]

замкнул контрольные пины тоже, проверил, с контролем потока тоже самое(иногда пересылаются все 600 001 байт, а в основном конечноже не все)... это нормально?

разве когда этот FTDI кабель работает в режиме замкнутом - Эхо, и в режиме контроля потока он не должен ждать пока его буфера освободятся перед тем как самому себе вновь новые данные отсылать?

[DmitryM]

замкнул контрольные пины тоже, проверил, с контролем потока тоже самое(иногда пересылаются все 600 001 байт, а в основном конечноже не все)... это нормально?

Нет, не нормально.

разве когда этот FTDI кабель работает в режиме замкнутом - Эхо, и в режиме контроля потока он не должен ждать пока его буфера освободятся перед тем как самому себе вновь новые данные отсылать?

Может это связано с терминальной программой? Например, гипертерминал вообще ничего не принимает и не передает, если включен аппаратный контроль, а сами выводы RTS/CTS не подключены. Xon/Xoff режим не пробовали?

[BlackOps]

Xon/Xoff режим вообще делает так что программа терминала зависает и вообще комп надо перезагружать.

Вы сами каку терминальную программму используете? с какой терминальной программой данный тест нормально работать будет?

[DmitryM]

Xon/Xoff режим вообще делает так что программа терминала зависает и вообще комп надо перезагружать.

Вы сами каку терминальную программму используете? с какой терминальной программой данный тест нормально работать будет?

Ну именно в таком режиме я не проверял. Использую гипертерминал (родной виндовый) или TeraTerm с протоколом Х-модем в основном.

[Golikov A.]

Погодите погодите!

когда вы замыкаете контрольные пины переходника вы не делаете никакого контроля...

Этот переходник просто транслирует состояние порта. И если компьютерный терминал считает что у него все хорошо, то он не выставит никакого сигнала о том что буфер не готов и так далее...

Дальше больше, ФТДИ не имеет никакого права вмешиваться в обмен, поэтому если его буфер наедается кексов, никаких сигналов также не появиться.

Если вас не беспокоит скорость, а волнует только надежность, то почему бы вам не применить стандартное решение и не повесить на РС232 протокол?

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

Другие методы - от лукавого....

[BlackOps]

еще такой вопрос, для того чтоб стм32 использовал CTS/RTS мне достаточно ее только включить правильно и все? никакие биты в ручную проверять не нужно? (спрашиваю т.к. вижу из мануала что в ручную тоже можно CTS проверять)


вот моя обовленная конфиурация на USART:

CODE

uint32_t config_usart3(void)
{

//=============================================================================
// USART3 Related configuration
//=============================================================================
// enable clock
RCC->APB1ENR |= RCC_APB1ENR_USART3EN;


// 1) Setting UE, amd M bits
USART3-> CR1 |= 0x2000; // UE = 1

// 2) Programming number of stop bits if needed


// 3) Enable DMA if needed


// 4) set the Baud Rate
// BAUD = fck / ( 8 * (2 - OVER8) * USARTDIV )
// fck = 42MHz,
// OVER8 = 0
// Choose BAUD = 115200
// then: USARTDIV = fck / ( 8 * (2 -OVER8) * BAUD = 22.75
// BRR = (22 << 4) | ( 0.75 * 16) = 364,
// or: BRR = fck / BAUD = 42MHz / 115200 = 364
USART3->BRR = 364;


// enable transmitter
USART3->CR1 |= USART_CR1_TE;

// enable receiver
USART3->CR1 |= USART_CR1_RE;

// enable CTS/RTS
USART3->CR3 |=
(
USART_CR3_CTSE |
USART_CR3_RTSE
);

return 0;
}

вот конфиг портов:

CODE

//=============================================================================
// GPIOD configuration
//=============================================================================
// enable GPIOD clock
((RCC_TypeDef *)(RCC_BASE))->AHB1ENR |= RCC_AHB1ENR_GPIODEN;


// Alternate Function
((GPIO_TypeDef *)(GPIOD_BASE))->MODER |=
(GPIO_MODER_MODER9_1 | // Alternate Function, USART3_RX
GPIO_MODER_MODER8_1 | // Alternate Function, USART3_TX
GPIO_MODER_MODER11_1 | // Alternate Function, USART3_CTS
GPIO_MODER_MODER12_1 // Alternate Function, USART3_RTS
);

// Output type
GPIOD->OTYPER = 0;



// Speed type
((GPIO_TypeDef *)(GPIOD))->OSPEEDR |=
(GPIO_OSPEEDER_OSPEEDR8_1 | // USART3 TX 50 MHz
GPIO_OSPEEDER_OSPEEDR9_1 | // USART3 RX 50 MHz
GPIO_OSPEEDER_OSPEEDR11_1 | // USART3 CTS 50 MHz
GPIO_OSPEEDER_OSPEEDR12_1 // USART3 RTS 50 MHz
);


// Push/Pull for USART3
GPIOD->PUPDR = 0;
((GPIO_TypeDef *)(GPIOD_BASE))->PUPDR |=
(
GPIO_PUPDR_PUPDR8_0 | // Pull-Up, USART3 TX
GPIO_PUPDR_PUPDR9_0 | // Pull-Up, USART3 RX
GPIO_PUPDR_PUPDR11_0 | // Pull-Up, USART3 CTS
GPIO_PUPDR_PUPDR12_0 // Pull-Up, USART3 RTS
);


((GPIO_TypeDef *)(GPIOD_BASE))->AFR[1] |= (
(7 << ((8 - 8) << 2)) | // USART3 TX, AF7
(7 << ((9 - 8) << 2)) | // USART3 RX, AF7
(7 << ((11 - 8) << 2)) | // USART3 CTS, AF7
(7 << ((12 - 8) << 2)) // USART3 RTS, AF7
);

и вот посылка байт:

CODE

uint8_t mem_read(USART_TypeDef *USART_ID )
{
uint32_t i=0; // loop var


//send read buffer to USART
for(i=0;i<=600000;i++)
{
// check if TXE bit is set
while((!(USART_ID->SR & USART_SR_TXE)) );

USART_ID->DR = 0x5d; // sending a byte

// check if TC bit is set
while((!(USART_ID->SR & USART_SR_TC)) );


}

return 0;
}uint8_t mem_read(USART_TypeDef *USART_ID )
{
uint32_t i=0; // loop var


//send read buffer to USART
for(i=0;i<=600000;i++)
{
// check if TXE bit is set
while((!(USART_ID->SR & USART_SR_TXE)) );

USART_ID->DR = 0x5d; // sending a byte

// check if TC bit is set
while((!(USART_ID->SR & USART_SR_TC)) );


}

return 0;
}

и еще,запустил я сейча ГиперТерминал, закоротил TX-RX, CTS-RTS выбираю файл на посылку небольшой и режим Xmodem как Вы упомянули, и ничего не отсылается..

Может еще чтото нужно там сделать?

[Golikov A.]

есть хороший терминал, называется com terrminal v1.9, может уже есть более новые не знаю.

http://avrlab.com/node/45

очень правильный, есть все что надо, и ничего лишнего

использовал CTS/RTS
по моему эти сигналы управляются руками, от активности прибора, разве нет?

[BlackOps]

Погодите погодите!

когда вы замыкаете контрольные пины переходника вы не делаете никакого контроля...

Этот переходник просто транслирует состояние порта. И если компьютерный терминал считает что у него все хорошо, то он не выставит никакого сигнала о том что буфер не готов и так далее...

Дальше больше, ФТДИ не имеет никакого права вмешиваться в обмен, поэтому если его буфер наедается кексов, никаких сигналов также не появиться.

ого... тогда все что я тут бился с ФТДИ это зря! ну ладно.

Если вас не беспокоит скорость, а волнует только надежность, то почему бы вам не применить стандартное решение и не повесить на РС232 протокол?

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

Другие методы - от лукавого....

Вы имеете ввиду взять какой нибудь MAX232 или подобное + USB-RS232 переходник отнапример Prolific, и сделать это через них?

использовал CTS/RTS
по моему эти сигналы управляются руками, от активности прибора, разве нет?

ну а толку мне тогда какого от этого терминала и этих CTS/RTS функций если вы говорите что ФТДИ не имеет никакого права вмешиваться в обмен?

[Golikov A.]

А... прошу прощения, я думал у вас так и сделано, с платы идет РС232, а ФТДИ в переходнике УСБ-РС232...

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

Ножки CTS/RTC и подобные он транслирует с ножек ком порта, сам их не меняет...

Обычно если ФТДИ на плате, то лучше работать через их драйвер, чем через драйвер виртуального ком порта. Совсем недавно у меня знакомый бился с этим драйвером и обнаружил что временами он делает паузу в обмене до 3 секунд, без каких либо объяснений, может в такие моменты ваши данные и теряются....

[BlackOps]

нет.., у меня плата Stm32Discovery, и от нее провода идут RX,TX,CTS,RTS,GND на этот кабель: http://electronix.ru/redirect.php?http://w...232R_CABLES.pdf
Это ФТДИ кабель, USART<---->USB

[Golikov A.]

Ножки РТС/CTR это ножки уровня прибора. То есть этими ножками вы сообщаете что ваш прибор готов принимать и сообщать данные, потому я и говорю что если быстродействия прибора и компьютера хватает на обработку данных, то эти ножки не помогут, и целостность надо контролировать уже протоколом...

сейчас я доку на ФТДИ найду, погляжу кое что...

[BlackOps]

так вот ворос тогда: в моем случае ФТДИ если набирается данных он через эти CTS/RTS сигналы даст знать стм32 чтоб тот притормзил с передачей?

если да то мой метод конфигурирования в предыдущем посте №19 верный?

[Golikov A.]

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

Если у вас к чипу фтди нет доступа, а так оно и есть, то никакие сигналы чипа вы контролировать не сможете. И не узнаете когда у него кончиться буфер. Ножки CTR - RTS и прочие, как я и говорил идут на прямую к компьютеру, и управляют обменом прибор - компьютер, не трогая чип ФТДИ.

Проблема где то в драйвере или самом чипе, это показывает опыт с передачей в эхо режиме.

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

[BlackOps]

странно... вот это например из мануала СТМ32

Bit 9CTSE: CTS enable
0: CTS hardware flow control disabled
1: CTS mode enabled, data is only transmitted when the nCTS input is asserted (tied to 0).
If the nCTS input is deasserted while a data is being transmitted, then the transmission is
completed before stopping. If a data is written into the data register while nCTS is asserted,
the transmission is postponed until nCTS is asserted.

т.е. я так понимаю ФТДИ если давится данными должен дать сигнал на CTS стм32, и тот притормозит подачу данных..разве нет?

[Golikov A.]

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

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


По описанию ФТДИ должен мочь прокачивать данные на больших скоростях без проблем, скорее всего беда где то в драйвере компьютера, то есть в УСБ обмене. Если на УСБ есть сильные помехи, то скорость передачи снижается, часто приходиться восстанавливать канал и прочее... думаю что в этом случае буфер ФТДИ кончиться и данные начнут теряться...

[BlackOps]

а как насчет ругих решений которые нормально работали бы и обеспечивали простую передачу данных? например Pololu адаптеры?
вы сами что еще пользовали с USART?

По описанию ФТДИ должен мочь прокачивать данные на больших скоростях без проблем, скорее всего беда где то в драйвере компьютера, то есть в УСБ обмене.

да нет, не думаю, я на двух разных компах проверял с WinXP32 и Win7 64 тоже самое.

исходя из этого выходит ФТДИ просто не выполняет своей заявленной функции? (ну или конкретно все драйвера его корявые...)... хотя незнаю

[Golikov A.]

У меня всегда УАРТ был с протоколом. Обычно РС485+МОДБАС. Или 232 + свой самописный протокол. В обоих случаях пакеты длиннее 255 байт я не передавал (ну чтобы длина в 1 байт влезала). Потому у меня нет такого мощного потока непрерывных данных, и я никогда не знал о такой проблеме.

Все таки странно что чип лажает, может все таки софт с компьютерной стороны?


А другую терминальную прожку пробовали?

еще хороший тест если есть еще такой кабелек, с одного компьютера на другой передать

[mdmitry]

вот утилита которой пользуюсь:
http://www.hw-group.com/products/hercules/index_en.html

ОС: WinXP

У Вас скорость 115200. У нас была проблема с терминальной программой (ZOC) при работе на такой скорости при непрерывном потоке данных.При использовании Realterm проблем не было, но нельзя было одновременно выводить данные в лог файл и на терминал. Банально не успевал компьютер. Наблюдалось на win xp и win7. Похоже на проблему с драйвером COM-порта. Проблемы были и напрямую с портом (честный RS-232c), и через переходник на USB.

[DmitryM]

исходя из этого выходит ФТДИ просто не выполняет своей заявленной функции? (ну или конкретно все драйвера его корявые...)... хотя незнаю

Проблема может быть в терминале, который некорректно отрабатывает состояние RTS/CTS или вообще их не опрашивает.
Может быть в драйверах, но сильно сомневаюсь. Для FTDI можно настроить достаточно параметров, например, глубину буфера и таймауты по незаполнению буфера, и проч.
Например, в системе используется ping-pong, так вот при значении по умолчанию - буфер 1024, скорость передачи/приема очень малая - буфер полностью не заполняется и прием/передача только по тайм-ауту, уменьшение буфера до минимального значения (64) и тайм-аута до 2мс (1мс для некоторых устройств приводила также к замедлению) значительно повышает скорость обмена (400 байт/с -> 2800 байт/с). Поиграйтесь этими настройками Com-порта (в винде дополнительные параметры). Также там есть и реакция на RTS/CTS, что то про неактивность, счас проверить возможности нет.

[BlackOps]

а вот и то как ФТДИ это описывает: http://www.ftdichip.com/Support/FAQs.htm#HwGen3
CTS/RTS у них впрямь не работает как положено!

а именно:

"If CTS# is logic 1 it is indicating the external device cannot accept motre data. the FTxxx will stop transmitting within 0~3 characters, depending on what is in the buffer.

This potential 3 character overrun does occasionally present problems. Customers shoud be made aware the FTxxx is a USB device and not a "normal" RS232 device as seen on a PC. As such the device operates on a packet basis as opposed to a byte basis."

это думаю все и обЪясняет, правда данная ситуация описывала вариант где ФТДИ отправлял данные прибору, но думаю аналогичное тогда будет верно и в обратном случае.

Побродил по форумам Silabs, увидел аналогичную тему тоже, и аналогичное описание проблемы с CP2102.

Так что, мне кажется тут два пути:

1) усложнить отправку и протоколизировать как вы сказали

2) просто добавить задержку после отправки скажем каждых 256 байт с СТМ32, в конце концов все эти побочные эффекты из-за того что переходник не может принять быстрый поток байт, т.е. просто сделать поток медленным должно сработать.

[DmitryM]

а вот и то как ФТДИ это описывает: http://www.ftdichip.com/Support/FAQs.htm#HwGen3

Не сходится про отправку
If RTS# is logic 0 it is indicating the FTxxx device can accept more data on the RXD pin.
If RTS# is logic 1 it is indicating the FTxxx device cannot accept more data.
RTS# changes state when the chip buffer reaches its last 32 bytes of space to allow time for the external device to stop sending data to the FTxxx device.

1) усложнить отправку и протоколизировать как вы сказали

Вот это надежнее

[Golikov A.]

странно это вообще...

неужели если это переходник подключить к порту компьютера и на порте подергать CTR RTS они не появятся на выходе ФТДИ?
Раньше вроде бы появлялись, мы ими питание организовывали для всяких мелких платок... Или там какая-то комбинированная логика, и данные сигналы появляются и когда на порту они есть и когда ФТДИ хочет?

Проверьте пожалуйста, если дергать сигнал порта (тот терминал что я приводил может делать это отдельно от передачи) они появляются на выходе ФТДИ или нет? И сотвественно дерганья ножки ФТДИ появиться на порте?


Протокол всяко надежнее, кто его знает как оно потом будет? Смените носитель или помехи на усб будут... А протокол он навека

UPD
Понятно, теперь все подругому. По описанию получается что если вы на компьютере выставите бит что данных больше не надо, этот бит не появиться на выходе ФТДИ, до тех пор пока не забьется буфер ФТДИ. То есть теперь его нельзя использовать как управление в передачи без контроля данных.

Но, опять же описание обещает что буфер фтди не забьется, даже если терминал не выставит эти биты (тут я здорово ошибался), Почему же данные теряются? Получается что они правда пропадают где то в буферах виндоус.

[Сергей Борщ]

еще такой вопрос, для того чтоб стм32 использовал CTS/RTS мне достаточно ее только включить правильно и все? никакие биты в ручную проверять не нужно? (спрашиваю т.к. вижу из мануала что в ручную тоже можно CTS проверять)

Да, должно быть достаточно включить и правильно настроить. На то оно и аппаратное управление потоком.

и еще,запустил я сейчас ГиперТерминал, закоротил TX-RX, CTS-RTS выбираю файл на посылку небольшой и режим Xmodem как Вы упомянули, и ничего не отсылается..

Читайте описание протокола xmodem. Принимающая сторона должна сообщить о готовности принимать посылкой символа 'C'. Посылайте не через xmodem, а как текстовый файл (Transfer->Sent text file). Можете одновременно записать принятое в файл (Transfer->Capture text) и сравнить с отправленным.

а вот и то как ФТДИ это описывает: http://www.ftdichip.com/Support/FAQs.htm#HwGen3
CTS/RTS у них впрямь не работает как положено!

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

1) усложнить отправку и протоколизировать как вы сказали

А разве можно делать как-то иначе?

[vptr]

Так что, мне кажется тут два пути:

1) усложнить отправку и протоколизировать как вы сказали

2) просто добавить задержку после отправки скажем каждых 256 байт с СТМ32, в конце концов все эти побочные эффекты из-за того что переходник не может принять быстрый поток байт, т.е. просто сделать поток медленным должно сработать.

1-й вариант лучше.
2-й вариант не гарантирует стабильности или придется делать задержку большой, с запасом.
У нас была похожая проблема. Гоняли по RS232 на 115200 каждые 5 мс 54 байта. Пакет был с контрольной суммой и заголовком. Так вот чтение этого пакета на компьютере, без потерь, могло зависеть от всего - число запущенных программ в виндос, скорости компьютера, приоритета потока в котором читается ком порт. На новых компьютерах потерь не было, на старых как повезет. Еще зависит как организовано чтение на компьютере, при использовании C#, на старых машинах возникает больше проблем.

[Dopler]

Удивительные вещи народ рассказывает про компьютерный RS232. Наши приборы работают на скорости 921600, поток данных 500 кБит. Протокол с заголовками и контрольными суммами, конечно, есть, но он скорее привет из 90-х, чем жизненная необходимость. Я уже и не припомню, когда последний раз данные на компьютере терялись. Достаточно только установить правильный размер приемных буферов и таймауты. Можно ли это настроить в терминалах я не знаю, а через API функцией SetupCom (http://msdn.microsoft.com/en-us/library/windows/desktop/aa363439(v=vs.85).aspx). На C# размер буфера тоже задается. Т.е. надо просто взять нормальный сканер COM-порта, и проблемы буфера Windows пропадут.

[ar__systems]

замкнул контрольные пины тоже, проверил, с контролем потока тоже самое(иногда пересылаются все 600 001 байт, а в основном конечноже не все)... это нормально?

разве когда этот FTDI кабель работает в режиме замкнутом - Эхо, и в режиме контроля потока он не должен ждать пока его буфера освободятся перед тем как самому себе вновь новые данные отсылать?

переполняется скорее всего буфер не компа, а чипа фтди, во всяком случае в варианте эха без flow-control.

[Golikov A.]

Удивительные вещи народ рассказывает про компьютерный RS232. Наши приборы работают на скорости 921600, поток данных 500 кБит. Протокол с заголовками и контрольными суммами, конечно, есть, но он скорее привет из 90-х, чем жизненная необходимость. Я уже и не припомню, когда последний раз данные на компьютере терялись. Достаточно только установить правильный размер приемных буферов и таймауты. Можно ли это настроить в терминалах я не знаю, а через API функцией SetupCom (http://msdn.microsoft.com/en-us/library/windows/desktop/aa363439(v=vs.85).aspx). На C# размер буфера тоже задается. Т.е. надо просто взять нормальный сканер COM-порта, и проблемы буфера Windows пропадут.

FTDI переходник очень далек от аппаратного РС232...
как минимум усб не фул дуплекс, а также там есть драйвер, который тоже весьма странно работает. Вроде разобрались что контроль потока ФТДИ должен устранит переполнения буфера внутри микрухи. Я грешу на драйвер...

[vptr]

Удивительные вещи народ рассказывает про компьютерный RS232. Наши приборы работают на скорости 921600, поток данных 500 кБит. Протокол с заголовками и контрольными суммами, конечно, есть, но он скорее привет из 90-х, чем жизненная необходимость.

А когда в компьютере стандартный COM порт стал штатно поддерживать скорость 921600? И как же разбирать синхронизировать и гарантировать целостность данных без привета из 90-х

Сообщение отредактировал vptr - Jun 10 2013, 11:55

[Golikov A.]

может у них 2090-ые, параллельная реальность...

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

а я вот вспоминал вспоминал, так и не вспомнил, можно задать что-то больше 115200 когда инитиш порт через вин-апи или нет, эх...

[vptr]

может у них 2090-ые, параллельная реальность...

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

а я вот вспоминал вспоминал, так и не вспомнил, можно задать что-то больше 115200 когда инитиш порт через вин-апи или нет, эх...

максимальная, которая указана сейчас 256000 http://msdn.microsoft.com/en-us/library/wi...4(v=vs.85).aspx
Раньше, по интернету народ искал самописные драйвера для COM порта, которые на некоторых материнках даже работали и позволяли взять скорость выше чем 115200. Сам когда-то такой драйвер использовал, но работает он не на всех материнках.

Сообщение отредактировал vptr - Jun 10 2013, 20:43

[jcxz]

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

Можно. И можно много больше 921кбит.
Полностью согласен с Dopler - какие-то странные проблемы тут обсуждаются.
Работаю постоянно с COM-портами на высоких скоростях (до 921кбит иногда, а на 230кбит - так вообще у меня стандарт) во многих устройствах через разные переходники USB-RS232 и USB-UART(3.3V).
В переходниках есть и FTDI и CP2102 и др.
Проблем с потерями не возникает никогда. Вот сейчас передо мной два устройства работают на 460кбит и всё ок.
Ищите проблему в кривых терминалках (или при работе с Win-API) или в работе с портом на стороне микроконтроллера.

максимальная, которая указана сейчас 256000 http://msdn.microsoft.com/en-us/library/wi...4(v=vs.85).aspx

На то что написано в свойствах порта в винде можете вообще не обращать внимание.

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

Это справедливо только для UART-чипов на материнках и PCI-платах расширения. USB-переходники используют свой драйвер и какую он скорость поддерживает зависит только от него.
Есть USB-UART-переходники поддерживающие скорости больше 921кбит (и это вполне работает).
Переходники USB-RS232 (12вольтовые) как правило имеют меньший предел по скорости, чем USB-UART (низковольтные), хотя может это мне такие попадались.
У меня USB-RS232 на FTDI имеет предел в одну сторону 230кбит, в другую - 460кбит. На USB-UART(3.3V) я получаю стабильно 921кбит.

[Golikov A.]

через драйвер или как виртуальный ком порт?

А у меня вопрос нафига рс232 так гнать? есть же усб и прочие?

[Сергей Борщ]

максимальная, которая указана сейчас 256000 http://msdn.microsoft.com/en-us/library/wi...4(v=vs.85).aspx

Неправда. Максимальная там не указана:

BaudRate

The baud rate at which the communications device operates. This member can be an actual baud rate value, or one of the following indexes.

[jcxz]

через драйвер или как виртуальный ком порт?

Драйвер. silabser.sys или mxuwdrv2.sys или ser2pl.sys (с первыми двумя работал на 921кбит, 3-й - ограничивает на 230кбит (не тянет высоковольтный формирователь сигналов RS232 12V)).

А у меня вопрос нафига рс232 так гнать? есть же усб и прочие?

Ну если применительно к работе с USB-UART переходником, то хотя-бы для отладочного ввода/вывода (в реальном времени).
Через сложный интерфейс типа USB очень неудобно отладку пускать к тому же он часто занят рабочим интерфейсом или не распаян.

[Golikov A.]

Драйвер. silabser.sys или mxuwdrv2.sys или ser2pl.sys (с первыми двумя работал на 921кбит, 3-й - ограничивает на 230кбит (не тянет высоковольтный формирователь сигналов RS232 12V)).


Ну если применительно к работе с USB-UART переходником, то хотя-бы для отладочного ввода/вывода (в реальном времени).
Через сложный интерфейс типа USB очень неудобно отладку пускать к тому же он часто занят рабочим интерфейсом или не распаян.

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


Понятно, для отладки... я больше 115200 и не гонял, как то и не надо было...

[Dopler]

через драйвер или как виртуальный ком порт?

А у меня вопрос нафига рс232 так гнать? есть же усб и прочие?

COM-порт, конечно, используется виртуальный, через переходник USB-RS232.

С USB куча сложностей. Первая и одна из основных в нашей отрасли (медтехника) - USB невозможно гальванически развязать от компьютера. Т.е. можно сделать, конечно, многопроцессорную систему, один из которых отвечает за USB, и развязать уже интерфейс к нему, смысла только большого нет. Проще поставить мост (CP2102 или FTDI) за 1$ и развязать USART двумя оптронами. Вторая очень существенная проблема - подпись драйверов на 64-х битных Windows. В 64-х битной 8-ке драйвера без подписи вообще ставятся через такие дебри, что обычному пользователю в жизни не догадаться.

[jcxz]

COM-порт, конечно, используется виртуальный, через переходник USB-RS232.

Я думаю Golikov A. под "виртуальным" понимал несколько иное, что-то типа tibbo virtual port.

С USB куча сложностей. Первая и одна из основных в нашей отрасли (медтехника) - USB невозможно гальванически развязать от компьютера.

Здорово! А к примеру ADUM4160 кто отменил??? Мы в нашей медтехнике его успешно используем.

[Dopler]

Здорово! А к примеру ADUM4160 кто отменил??? Мы в нашей медтехнике его успешно используем.

ADUM4160 появился не так давно, максимум года 3-4 назад, стоит в 10 раз дороже CP2102 и не решает проблему с драйверами.

[Golikov A.]

езернет оптику! 100% развязка от всего)

Правда не думал что УСБ в случае СР2102 можно развязать через линию УАРТА, запомним...

хотя я предпочитаю уж полноценный РС485 или 422, он как то индустриальнее выглядит, но у меня не мед техника... решения через эмулятор ком порта выглядит как то не солидно. Типа мы УСБ не осилили, вот такую заплатку приляпали...

[jcxz]

ADUM4160 появился не так давно, максимум года 3-4 назад, стоит в 10 раз дороже CP2102 и не решает проблему с драйверами.

ADUM4160+CyUSB или ADUM4160+libusb - решают

[Dopler]

хотя я предпочитаю уж полноценный РС485 или 422, он как то индустриальнее выглядит, но у меня не мед техника... решения через эмулятор ком порта выглядит как то не солидно. Типа мы УСБ не осилили, вот такую заплатку приляпали...

Для общего развития, что народ понимает под USB в устройстве? Прикинуться флешкой, или может быть мышкой? Мне казалось, что подавляющее большинство использует Communication Device (CDC), т.е. тот же виртуальный Com-порт.

ADUM4160+CyUSB или ADUM4160+libusb - решают

Проблема не в драйверах самих по себе, драйвера мы писать умеем. А в политике Microsoft по обязательной подписи драйверов на 64-х битных системах. Процедура оказалась достаточно геморойная.

[Golikov A.]

ну я бы говорил
прикинуться Масс Тораже - то есть устройством на которые можно класть данные и читать.
прикинуться HID устройство, это не обязательно мышка или клавиатура, это устройство с 3 конечными точками, 2 для интерапт обмена и контрольная.
прикинуться PID то есть физик интерфейс устройством.

Ну и на худой конец иметь свой собственный драйвер, как делают сканеры, принтеры и прочие.

Вы часто видели принтер канон или епсон или кто там еще их делает который бы подключался в систему как виртуальный ком порт? я не встречал ни одного. Может фотоаппараты, планшеты? Так что все таки подавляющее большинство устройств подключается не через ЦДЦ... ИМХО