Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: STM32F4 USART посылка данных
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Страницы: 1, 2
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



что тут еще может быть нетак?
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 Zawidowski
Попробуйте мою терминалку.
Настройки - Alt+F3. Начало записи файла - Alt-F4, завершение - ALt-F5. Режим поставить fast text.

А может и FTDI от себя подарочек подложить... Мне пришлось в одном проекте перейти на использование специфической FTDI-шной библиотеки, чтобы избежать ОЧЕНЬ редкого искажения данных, принимавшихся через FT2232H на скорости 3 бегабита в секунду. Искажение данных зависело от загруженности машины. Переход на D2 lib избавил от проблем.
BlackOps
не могу запустить программу Вашу, говорит:
telnet32 is not a valid windows 32 application
Genadi Zawidowski
Похоже было обе 64-х битных версии... Скомпилировал-выложил под win32.
BlackOps
значок поменялся, появилась иконка у программы, но выдает ту же ошибку sm.gif
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
Цитата(BlackOps @ May 27 2013, 10:11) *
я сейчас сделал именно так как вы сказали, соединил ножки 2-3, затем я создал один файл с количеством 600 001 байт.
и в терминальной программе (правда без режима CTS/RTS, но на той же скорости 115200) прогнал этот файл, а взамен получил 593 857 байт, это делает гдето 6 144 байт разницу.

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

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

разве когда этот FTDI кабель работает в режиме замкнутом - Эхо, и в режиме контроля потока он не должен ждать пока его буфера освободятся перед тем как самому себе вновь новые данные отсылать?
DmitryM
Цитата(BlackOps @ May 27 2013, 10:36) *
замкнул контрольные пины тоже, проверил, с контролем потока тоже самое(иногда пересылаются все 600 001 байт, а в основном конечноже не все)... это нормально?

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

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

Вы сами каку терминальную программму используете? с какой терминальной программой данный тест нормально работать будет?
DmitryM
Цитата(BlackOps @ May 27 2013, 11:43) *
Xon/Xoff режим вообще делает так что программа терминала зависает и вообще комп надо перезагружать.

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

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

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

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

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

Если вас не беспокоит скорость, а волнует только надежность, то почему бы вам не применить стандартное решение и не повесить на РС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
Цитата(Golikov A. @ May 27 2013, 15:02) *
Погодите погодите!

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

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

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

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

Цитата(Golikov A. @ May 27 2013, 15:02) *
Если вас не беспокоит скорость, а волнует только надежность, то почему бы вам не применить стандартное решение и не повесить на РС232 протокол?

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

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


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



Цитата(Golikov A. @ May 27 2013, 15:07) *
использовал 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?

Цитата(Golikov A. @ May 27 2013, 15:32) *
По описанию ФТДИ должен мочь прокачивать данные на больших скоростях без проблем, скорее всего беда где то в драйвере компьютера, то есть в УСБ обмене.

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

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

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


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

еще хороший тест если есть еще такой кабелек, с одного компьютера на другой передать
mdmitry
Цитата(BlackOps @ May 26 2013, 23:01) *
вот утилита которой пользуюсь:
http://www.hw-group.com/products/hercules/index_en.html

ОС: WinXP


У Вас скорость 115200. У нас была проблема с терминальной программой (ZOC) при работе на такой скорости при непрерывном потоке данных.При использовании Realterm проблем не было, но нельзя было одновременно выводить данные в лог файл и на терминал. Банально не успевал компьютер. Наблюдалось на win xp и win7. Похоже на проблему с драйвером COM-порта. Проблемы были и напрямую с портом (честный RS-232c), и через переходник на USB.
DmitryM
Цитата(BlackOps @ May 27 2013, 14:39) *
исходя из этого выходит ФТДИ просто не выполняет своей заявленной функции? (ну или конкретно все драйвера его корявые...)... хотя незнаю

Проблема может быть в терминале, который некорректно отрабатывает состояние 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
Цитата(BlackOps @ May 27 2013, 21:34) *
а вот и то как ФТДИ это описывает: http://www.ftdichip.com/Support/FAQs.htm#HwGen3

Не сходится про отправку wink.gif
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 они не появятся на выходе ФТДИ?
Раньше вроде бы появлялись, мы ими питание организовывали для всяких мелких платок... Или там какая-то комбинированная логика, и данные сигналы появляются и когда на порту они есть и когда ФТДИ хочет?

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


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

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

Но, опять же описание обещает что буфер фтди не забьется, даже если терминал не выставит эти биты (тут я здорово ошибался), Почему же данные теряются? Получается что они правда пропадают где то в буферах виндоус.
Сергей Борщ
QUOTE (BlackOps @ May 27 2013, 13:05) *
еще такой вопрос, для того чтоб стм32 использовал CTS/RTS мне достаточно ее только включить правильно и все? никакие биты в ручную проверять не нужно? (спрашиваю т.к. вижу из мануала что в ручную тоже можно CTS проверять)
Да, должно быть достаточно включить и правильно настроить. На то оно и аппаратное управление потоком.
QUOTE (BlackOps @ May 27 2013, 13:05) *
и еще,запустил я сейчас ГиперТерминал, закоротил TX-RX, CTS-RTS выбираю файл на посылку небольшой и режим Xmodem как Вы упомянули, и ничего не отсылается..
Читайте описание протокола xmodem. Принимающая сторона должна сообщить о готовности принимать посылкой символа 'C'. Посылайте не через xmodem, а как текстовый файл (Transfer->Sent text file). Можете одновременно записать принятое в файл (Transfer->Capture text) и сравнить с отправленным.

QUOTE (BlackOps @ May 27 2013, 20:34) *
а вот и то как ФТДИ это описывает: http://www.ftdichip.com/Support/FAQs.htm#HwGen3
CTS/RTS у них впрямь не работает как положено!
Все там нормально. Данные не теряются - просто после выставления RTS она может выплюнуть еще несколько байтов. Выплюнуть, но не потерять. Так делают многие УАППы и никому это не мешает - приемная сторона выставляет RTS заранее, когда в ее приемном буфере есть место более чем на один байт.

QUOTE (BlackOps @ May 27 2013, 20:34) *
1) усложнить отправку и протоколизировать как вы сказали
А разве можно делать как-то иначе?
vptr
Цитата(BlackOps @ May 27 2013, 20:34) *
Так что, мне кажется тут два пути:

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
Цитата(BlackOps @ May 27 2013, 01:36) *
замкнул контрольные пины тоже, проверил, с контролем потока тоже самое(иногда пересылаются все 600 001 байт, а в основном конечноже не все)... это нормально?

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

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

Golikov A.
Цитата(Dopler @ Jun 8 2013, 00:01) *
Удивительные вещи народ рассказывает про компьютерный 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
Цитата(Dopler @ Jun 8 2013, 00:01) *
Удивительные вещи народ рассказывает про компьютерный RS232. Наши приборы работают на скорости 921600, поток данных 500 кБит. Протокол с заголовками и контрольными суммами, конечно, есть, но он скорее привет из 90-х, чем жизненная необходимость.

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

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

а я вот вспоминал вспоминал, так и не вспомнил, можно задать что-то больше 115200 когда инитиш порт через вин-апи или нет, эх...
vptr
Цитата(Golikov A. @ Jun 10 2013, 21:13) *
может у них 2090-ые, параллельная реальность...

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

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

максимальная, которая указана сейчас 256000 http://msdn.microsoft.com/en-us/library/wi...4(v=vs.85).aspx
Раньше, по интернету народ искал самописные драйвера для COM порта, которые на некоторых материнках даже работали и позволяли взять скорость выше чем 115200. Сам когда-то такой драйвер использовал, но работает он не на всех материнках.
jcxz
Цитата(Golikov A. @ Jun 10 2013, 23:13) *
может у них 2090-ые, параллельная реальность...
в целом конечно можно поток разбить на данные, но это надо быть очень самоуверенным что в шину никто больше ничего не пошлет, и никакой наводки не сделает...
а я вот вспоминал вспоминал, так и не вспомнил, можно задать что-то больше 115200 когда инитиш порт через вин-апи или нет, эх...

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

Цитата(vptr @ Jun 11 2013, 02:32) *
максимальная, которая указана сейчас 256000 http://msdn.microsoft.com/en-us/library/wi...4(v=vs.85).aspx
На то что написано в свойствах порта в винде можете вообще не обращать внимание.

Цитата(vptr @ Jun 11 2013, 02:32) *
Раньше, по интернету народ искал самописные драйвера для 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 так гнать? есть же усб и прочие?
Сергей Борщ
QUOTE (vptr @ Jun 10 2013, 23:32) *
максимальная, которая указана сейчас 256000 http://msdn.microsoft.com/en-us/library/wi...4(v=vs.85).aspx

Неправда. Максимальная там не указана:
QUOTE
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
Цитата(Golikov A. @ Jun 11 2013, 11:16) *
через драйвер или как виртуальный ком порт?

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

Цитата(Golikov A. @ Jun 11 2013, 11:16) *
А у меня вопрос нафига рс232 так гнать? есть же усб и прочие?

Ну если применительно к работе с USB-UART переходником, то хотя-бы для отладочного ввода/вывода (в реальном времени).
Через сложный интерфейс типа USB очень неудобно отладку пускать к тому же он часто занят рабочим интерфейсом или не распаян.
Golikov A.
Цитата(jcxz @ Jun 11 2013, 12:20) *
Драйвер. silabser.sys или mxuwdrv2.sys или ser2pl.sys (с первыми двумя работал на 921кбит, 3-й - ограничивает на 230кбит (не тянет высоковольтный формирователь сигналов RS232 12V)).


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


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


Понятно, для отладки... я больше 115200 и не гонял, как то и не надо было...
Dopler
Цитата(Golikov A. @ Jun 11 2013, 09:16) *
через драйвер или как виртуальный ком порт?

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

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

С USB куча сложностей. Первая и одна из основных в нашей отрасли (медтехника) - USB невозможно гальванически развязать от компьютера. Т.е. можно сделать, конечно, многопроцессорную систему, один из которых отвечает за USB, и развязать уже интерфейс к нему, смысла только большого нет. Проще поставить мост (CP2102 или FTDI) за 1$ и развязать USART двумя оптронами. Вторая очень существенная проблема - подпись драйверов на 64-х битных Windows. В 64-х битной 8-ке драйвера без подписи вообще ставятся через такие дебри, что обычному пользователю в жизни не догадаться.
jcxz
Цитата(Dopler @ Jun 12 2013, 18:40) *
COM-порт, конечно, используется виртуальный, через переходник USB-RS232.

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

Цитата(Dopler @ Jun 12 2013, 18:40) *
С USB куча сложностей. Первая и одна из основных в нашей отрасли (медтехника) - USB невозможно гальванически развязать от компьютера.

Здорово! А к примеру ADUM4160 кто отменил??? Мы в нашей медтехнике его успешно используем. wink.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.