[BlackOps 0]

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

 

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

[DmitryM 0]

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

 

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

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

[Golikov 0]

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

 

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

 

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

 

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

 

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

 

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

 

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

[BlackOps 0]

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

 

 

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

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;
}

 

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

//=============================================================================
// 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
);

 

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

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 0]

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

 

http://avrlab.com/node/45

 

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

 

использовал CTS/RTS

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

[BlackOps 0]

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

 

 

использовал CTS/RTS

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

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

[Golikov 0]

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

 

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

 

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

 

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

 

 

 

 

 

[BlackOps 0]

нет.., у меня плата Stm32Discovery, и от нее провода идут RX,TX,CTS,RTS,GND на этот кабель: http://electronix.ru/redirect.php?http://w...232R_CABLES.pdf

Это ФТДИ кабель, USART<---->USB

[Golikov 0]

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

 

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

[BlackOps 0]

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

 

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

[Golikov 0]

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

 

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

 

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

 

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

[BlackOps 0]

странно... вот это например из мануала СТМ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 0]

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

 

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

 

 

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

 

 

[BlackOps 0]

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

вы сами что еще пользовали с USART?

 

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

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

 

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

[Golikov 0]

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

 

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

 

 

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

 

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