[BlackOps 0]

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

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

 

 

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

	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

 

 

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

Изменено 26 мая, 2013 пользователем IgorKossak
[codebox] для длинного кода, [code] - для короткого!!!

[Flexz 0]

А что именно на принимающей стороне? какая ОС, com-порт настоящий или перходник?

PS проверка TC - в данном случае излишество, достаточно TXE проверять.

[BlackOps 0]

вот кабель который я использую, 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 : мой код не такой длинный, я специально поставил его в

 чтобы было лучше видно!

[BlackOps 0]

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

 

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

 

так вот, опять не получается послать надежно даже 600 000 байт.

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

 

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

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

[GenaSPB 11]

Попробуйте мою терминалку.

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

 

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

Изменено 26 мая, 2013 пользователем Genadi Zawidowski

[BlackOps 0]

не могу запустить программу Вашу, говорит:

telnet32 is not a valid windows 32 application

[GenaSPB 11]

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

Изменено 26 мая, 2013 пользователем Genadi Zawidowski

[BlackOps 0]

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

[BlackOps 0]

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

 

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

 

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

 

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

 

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

[BlackOps 0]

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

 

 

Но в моем примере сейчас я ведь Отправляю данные, а не принимаю.

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

[Golikov 0]

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

 

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

[BlackOps 0]

я сейчас сделал именно так как вы сказали, соеденил ножки 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 0]

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

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

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

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

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

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

[BlackOps 0]

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

 

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

[DmitryM 0]

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

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

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

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