Передача данных с ATmega8 на COM порт ПК

[OneTech]

TWI (I2C) тормознутый интерфейс, для скоростных задач стоит применять USB и SPI интерфейсы. Причем для последнего SPI интерфейса существует режим когда считывание и передача бита информации идёт как по спаду тактового импульса, так и по фронту, что вдвое повышает скорость "общения" по каналу. Как по мне, если вдаваться в подробности Вашей задачи, то я бы применил 2 контроллера, один считывает АЦП, тут же выдаёт его в SPI на максимально необходимой скорости, второй контроллер принимает данные, обрабатывает (скорее всего сжимает) и относительно неспеша передаёт посредством UART-а через преобразовать UART-USB на ПК. Ну и совсем "круто" можно взять какой-нить ARM или AVR32 контроллер у которого почти на всей переферии висят DMA-каналы, и выдавать это всё сразу через USB-канал.

Жаль до AVR32 никак руки и деньги не дойдут.

[ilya_sh]

И всё-таки, лучше ТЗ от автора. Возможно и не нужно 10к выборок. А на одном МК всё ж дешевле будет.

[neiver]

Можно в сторону V-USB (бывший AVR-USB) посмотреть. Делал на ней осциллограф.
Где-то 14-18 кб/с скорость передачи получается.
http://github.com/KonstantinChizhov/...master/K-Scope
- прошивка - на WinAvr.
- хост программа на Qt 4.5
- драйвер - LibUsb Win32

[marera]

1. Преобразование (50 мкс, с трудом, но 10 бит)
2. Передача двух байт при 115200 (1/115200 и * 16 ~ 150 мкс)
3. Итого 200 мкс - это 5000 отсчетов в секунду, вполне сносно.
4. Мега и 256 кБит по СОМ легко сделает, только с регистрами СОМ порта ПК нужно поиграться.
5. И лучше бы Ноль ловить компаратором и по его прерыванию запускать цикл преобразования и передачи с расчетом на чуть больше периода (20 мС) - более 100 преобразований.
6. Поскольку памяти в данной задаче достаточно, то по тому же прерыванию ни что не запрещает залить данными АЦП массив в 200 отсчетов (400 байт) и потом его передать, уже с любой удобной скоростью.
Только АЦП притормозить, чтобы этими отсчетами захватить чуть больше периода.
Хотя, почти все это уже Вам предлагали, простите за OFFTOP.

[=GM=]

Автор хочет, чтобы за него сделали его курсовую или что там у него. Я ему написал 4 замечания к его программе, не говоря уж о 3 предложениях, которые решают задачу, а в ответ тишина.

Казалось, чего проще, исправь, да проверь, ан нет. В своём следующем посте он за каким-то чёртом спрашивает о TWI и I2C, и "не могли бы вы поправить мою программу".

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

[sergx1300]

Автор хочет, чтобы за него сделали его курсовую или что там у него. Я ему написал 4 замечания к его программе, не говоря уж о 3 предложениях, которые решают задачу, а в ответ тишина.

Во первих у меня не курсовая а диплом.
Во вторих-по поводу 4 замечаний - СМОТРЁЛ.
В настоящий момент разбираюсь с буфером. Относительно ADCSRA - без него неработает. Убрать printf и putchar - но как без них? Из асамблером вообще незнакомый.
И на конец: у меня из АЦП все нормально. Тормозить передача данных, соответственно рассматриваю другие интерфейсы. Запись данных в буфер - думаю пустая трата времени, на таких скоростях нереально.

[marera]

Давно работает простенький анализатор сетевого напряжения на ATM48 в купе с ПК через COM. (Частота, напряжение, низкочастотные гармоники до 1 кГц).
И суть упрощенно:
unsigned char RegChH[128],RegChL[128]; //глобальный буфер (проще работать с двумя, но байтными)
//кстати, в таких приложениях как правило достаточно 8-ми битного преобразования, тогда и массив потребуется один.
// Оцифровка данных
unsigned int read_adc(unsigned char adc_input)
{
ADMUX=adc_input | (ADC_VREF_TYPE & 0xff);
// Delay needed for the stabilization of the ADC input voltage
delay_us(10);
// Start the AD conversion
ADCSRA|=0x40;
// Wait for the AD conversion to complete
while ((ADCSRA & 0x10)==0);
ADCSRA|=0x10;
return ADCW;
}

// передача данных
void USART_PUT(void)
{ unsigned char i,k;
k=0;
for (i=0;i‹128;i++)
{
while (!(UCSRA & 0x20));
UDR=RegChH[i];
while (!(UCSRA & 0x20));
UDR=RegChL[i];
k++;
if (k›7) // передаем блоками по 16 байт, чтобы не было потерь данных
//если с кварцем, то это необязательно.
{k=0;
delay_ms(1)
};
};
};
// Прерывание от компаратора
interrupt [ANA_COMP] void ana_comp_isr(void)
{unsigned char ad;
unsigned int reg;
#asm("cli") //Запретить прерывания
for (ad=0;ad‹128;ad++) //Заполнение буфера 256 байт данными с АЦП
{reg=read_adc(0);
RegChH[ad]=(reg››8 ) ; //Запись старшего байта
RegChL[ad]=(reg & 0xff); //Запись младшего байта
// и затратите вы на это 128*60мкс=менее 8 милисекунд,
// так что нужно добавить задержку для захвата периода сетевого напряжения
// и лучше это сделать в модуле АЦП.
}
USART_PUT();
#asm("sei") //Разрешить прерывания
//Можно это делать и в главном модуле, по условиям, когда Вам потребуются данные.
//Не думаю, что Вам необходим непрерывный, неуправляемый поток данных на ПК
};

[mike7815]

Prime прав во всем. так и надо делать. работать с FTDI очень просто. никаких драйверов писать не нужно. Единственное надо придумать простенький протокол для синхронизации приема данных и контроля ошибок. Я так часто отладку делаю. В прерывании по таймеру выкидываю дамп памяти МК на комп. А там простой программкой его раскидываю, графики рисую и т.п. удобно.

[UserM]

А там простой программкой его раскидываю, графики рисую и т.п. удобно.

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

[marera]

Скажу тоже пару слов автору топика...
Если хочешь получить скорость передачи повыше ( а для твоей задачи без всяких сжатий данных и прочая надо как теоретический минимум 10000 * 2 * 10 = 200000 кБит/с), попробуй глянуть на скорости на USART выше 115200. Стандартный COM-порт может такое не потянуть, зато виртуальный, создаваемые при использовании той же самой FT232 (подробнее читай на сайте производителя) и USB - вполне позволит такие скорости. Мы разгоняли до 1.5 МБит, и всё работало. Удачи в начинаниях!

Чтобы увлечь женщину нужно знать все языки и всех поэтов, примерно так можно понять Вашу мысль! А можно просто шептать глупости и сработает!
Чтобы анализировать, нужны данные, но чтобы анализировать нужно время! И то и другое и вместе и одновременно - не делают. Получите данные для анализа (сто-двести точек), спокойно (подчеркнуто) передайте и "развлекайтесь". Не понравилось - получите еще и т.д.
СОМ при желании обеспечит и пару мегабит (обычно об этом знают), но в этой задаче такая скорость совершенно ни к чему. АЦП крректно работает не быстрее 50 мкс (строго - 80 мкс) и анализировать сетевое напряжение по гармоникам выше 2 кгц бессмысленно. Выбирать для анализа непрерывный поток? И куда? Возьмите чуть больше периода и столько раз, сколько потребуется. Зачем усложнять изначально довольно простую задачу, или по принципу, если сервер, то всероссийский (хоть и домашний).
Целесообразность - штука полезная.