Search in topic
Самодельный передатчик (часть 1)

Кстати, смотрю на варианты схем - даже кварцы стоят по 12MHz. Но почему в этих схемах никто не нарисовал подключение PC по USB? Ведь это - пара мелких деталей при таком раскладе.

При этом появляется возможность:

конфигурирования устройства с PC по USB (графические редакторы кривых и т.п.);
загрузки-выгрузки описания и настроек моделей (кто там обсуждал единый формат данных?);
использования пульта для симуляторов (очевидное применение);
управления чем-то с PC (для мазохистов);
обновления прошивок непосредственно по USB (при использовании USB boot loader’а);
чего-то еще, что я просто не учел.

Это можно не поддерживать в базовой версии софта, но схемотехнически это предусмотреть, IMHO, абсолютно необходимо и полезно. USB, само собой, софтверный.

а ссылочку на что-то подобное? в частности на софтверный USB-лоадер, для примера.

osnwt:

Кстати, смотрю на варианты схем - даже кварцы стоят по 12MHz. Но почему в этих схемах никто не нарисовал подключение PC по USB? Ведь это - пара мелких деталей при таком раскладе.

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

а вот ссылка на софтовый USB

lucky75:

а ссылочку на что-то подобное? в частности на софтверный USB-лоадер, для примера.

На что-то подобное - на что именно?

Редактор кривых - частный случай конфигурирования по USB. Я это делал для других проектов.
См. выше. Реально есть возможность читать и писать блоки данных по USB - значит, можно что угодно конфигурировать и чем угодно управлять.
См. rcdesign.ru - USB адаптар передатчика на ATmega8.
Аналогично первым двум пунктам.

В целом, есть прекрасный программный USB драйвер с открытыми исходными текстами. Для данных задач его более чем достаточно. Если делать устройство, как HID, то писать драйвер на PC тоже не надо - Windows определяет устройство автоматически. Остается только написать утилиту конфигурирования или управления.

Что касается пункта 5 - загрузчика, то я реализовал такой для ATmega32 и выше (нужен бут-блок размером от 4-х килобайт, так как весь код написан на C). Он реализован также как HID устройство, поддерживает шифрование прошивок, обновление версий по тому же USB с помощью утилиты с PC, и ряд специальных функций. То есть, я вполне аргументированно могу утверждать, что это возможно, так как сам им пользуюсь для своих поделок. В процессе работы над ним был найден (и исправлен в сотрудничестве с автором usb-drv) ряд ошибок в упомянутом драйвере, добавилась функциональность и родился его порт для компилятора IAR, который стал частью официальной версии (см. оригинальное readme драйвера).

Однако, такой boot - это закрытый проект, поскольку делался не для данной темы. Потому я только упомянул, что такое возможно, но не имею возможности привести пример в виде ссылки. Это не исключает того, что кто-то напишет аналогичный. Знаю точно, что, как минимум, еще один человек пишет такой, но сам с ним не общался.

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

Ser_bil:

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

Советую обратить внимание на ту ссылку, что дал я. Драйвер от Objective Development не сравнить с первым таковым от Игоря Цеско (автора упомянутого аппноута атмела). Он написан на C под GCC/WinAVR (кроме time-critical секций, написанных на ассемблере), имеет открытый исходный код с гуманной лицензией и полностью документирован, включая особенности и ограничения. С ним основной код пишется на раз два, вот так, к примеру (кусок из кода адаптера RC аппаратуры к схеме с rcdesign):

//
// Execution starts here
//
__C_task void main(void)
{
	wdInit();			   // initialize watchdog timer
	usbInit();			  // initialize USB driver
	bootInit();			 // initialize boot loader interface
	inDecoderInit();		// initialize input decoder
	usbDeviceConnect();	 // connect USB device to the bus
	__enable_interrupt();

	while (1)
	{
		wdReset();		  // reset watchdog timer
		inDecoderPoll();	// poll for input data
		outSendData();	  // return data via USB Interrupt In endpoint
		usbPoll();		  // process USB requests

#if BOOT_SUPPORT_ENABLED
		if (bootRequest())		  // jump to boot loader if switch is pressed
		{
			usbDeviceDisconnect();  // disconnect the USB device from the bus
			inDecoderStop();		// stop the input decoder interrupts
			bootJump();			 // jump to boot loader
		}
#endif
	}
}

А вот, собственно, всё, что необходимо и почти достаточно (не считая формирования блока данных и HID Report Descriptor’а) для обработки USB запросов HID джойстика. Не правда ли, куда менее cryptic, чем ассемблерные варианты? Да к тому же еще и обработка USB данных в этом драйвере выполняется в реальном времени, а не после приема в буфер. Ровно 8 команд на бит - интересная статья о том, как это удалось, есть на сайте автора драйвера.

//
// USB setup request processing
//
uchar usbFunctionSetup(uchar data[8])
{
	usbRequest_t *rq = (void *)data;

	if ((rq->bmRequestType & USBRQ_TYPE_MASK) == USBRQ_TYPE_CLASS)
	{
		// Return the report if host requests it without USB interrupt
		if (rq->bRequest == USBRQ_HID_GET_REPORT)
		{
			// wValue: ReportType (highbyte), ReportID (lowbyte)
			// we only have one report type, so don't look at wValue
			usbMsgPtr = usbBuildReport();
			return sizeof(usbReport);
		}
	}
	return 0;
}

//-----------------------------------------------------------------------------

//
// Check if the USB Interrupt In point buffer is empty and return
// the data buffer for the following host request via USB interrupt
//
void outSendData(void)
{
	if (usbInterruptIsReady())
	{
		// fill in the report buffer and return the
		// data pointer (Report ID is not used)
		usbSetInterrupt(usbBuildReport(), sizeof(usbReport));
	}
}

Все это здорово конечно… но, коль скоро разговор вернулся в конструктивное русло, давайте не будем распыляться. Эта “рюшечка” по сложности и требованию к ресурсам не далеко уходит от самого передатчика. Лучше направить усилия на создание того, что мы, собственно, собираемся ей конфигурировать 😃

2 osnwt:
Очень ценная и дельная информация, жаль немного преждевременная 😦 Хотя было бы здорово, если бы кто-то, руководствуясь ей, начал бы, как Вы говорите, отдельный проект по реализации конкретно этой фичи 😃

С софтверным обработчиком USB есть вот какие грабли - хост может подвесить контроллер на произвольное время, не говоря уж о проблемах с другими критичными прерываниями. Так что управлять моделью с подключенным хостом я бы не стал совершенно точно :о).
Вообще, применение софтверного USB для сложных real-time систем мне представляется малоперспективной затеей. Тем более, что уже достаточно недорогих контроллеров с аппаратной поддержкой USB. Мне, например, очень понравилось работать с AT91SAM7S64 - 64 кб флеш, 16 кБ ОЗУ, ARM ядро, отличная периферия и честный full-speed USB. По цене сравним с ATmega64.

lucky75:

Очень ценная и дельная информация, жаль немного преждевременная 😦 Хотя было бы здорово, если бы кто-то, руководствуясь ей, начал бы, как Вы говорите, отдельный проект по реализации конкретно этой фичи 😃

Информация как раз своевременная: надо закладывать интерфейс в железо. Пусть даже там пара деталек. При этом я ничего не говорил про реализацию фичи немедленно.

Vad64:

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

В принципе, при проблемах с хостом он точно может подвесить. Потому и рекомендуется ставить пуллап на int, чтобы не было дрожания инта при отключенном хосте и, соответственно, девайс мог работать автономно. Если хост без проблем, то он может подвесить не на произвольное, а на вполне документированное в драйвере время (которое, увы, больше того, что можно позволить себе в реалтайме). Управление с хоста моделью - согласен, это больше из области теории. Но все остальное не является критичным в плане подвеса, а потому вполне имеет право на жизнь. Да, были проблемы с драйвером в ранних версиях, в т.ч. и в этом плане, но сейчас их не видно. Я достаточно много экспериментировал с ним в разных аппаратных конфигурациях, и он работает (медленно, но работает) даже там, где промышленное (фирменное) USB устройство (фотоаппарат Olympus) работать вообще отказалось (в определенной конфигурации аппаратуры).

Насчет SAM7 - да, я смотрю на него как на кандидата для своего парапланерного прибора. Мне лично все равно, на какой контроллер что писать. Но народный - это почему-то именно AVR. Потому я всего лишь сказал, что уже имея такой девайс, как предложенные схемы, просто смешно не сделать пары ног для USB. А будет ли этим кто-то пользоваться или нет - вопрос личного предпочтения. Я бы пользовался.

Не обязательно реализовывать одновременное функционирование USB и других функций передатчика. Можно сделать определение подключения компьютера при включении передатчика и далее две ветки: одна – работа с USB (апдейт прошивки, работа с моделями, режим симулятора), вторая – непосредственно передатчик с меню, настройками, и так далее. Определение может быть как автоматическое, так при помощи пользователя (зажать при включении кнопку, например).

toxa:

Не обязательно реализовывать одновременное функционирование USB и других функций передатчика.

Именно так! Если запрещены прерывания от USB (Int 0/1), то драйвер ничем себя не проявляет и, соответственно, его функции не работают (и не мешают).

Ну, а автодетект сделать - вообще проблем нет. Ведь с USB поступает также +5 вольт. Достаточно увидеть присутствие их на схеме, и можно, во первых, питать от этого источника при работе без ВЧ. Во вторых, в текущей версии драйвера добавлены функции usbDeviceConnect()/usbDeviceDisconnect() (при наличии аппаратного соединения пуллап-резистора не с плюсом, а с пином). То есть, увидели +5 вольт на шине - выдали usbDeviceConnect(). А до того никто никого не повесит, так как хост вообще не будет считать, что подключено какое-то устройство.

В общем, вариантов множество.

Апдейт прошивки через USB в этом проце - тоже с граблями. Что, если нужно устранить ошибку в самом обработчике USB или изменить дескрипторы или еще что-то? Единственный вариант тут, наверное, держать два обработчика - один в бутлоадере (без возможности обновления), а другой - для аппликейшна. Связь по USB, безусловно, классная фича. Но софтверное решение на AVR мне лично не нравится - извращение. Если бы я делал все с нуля, не стал бы на него закладываться. Также ломает решать любые лицензионные вопросы.

2 Vad64:
А как Вы смотрите на идею использования двух AVRов для решения подобных проблем? Не конкретно USB, а в принципе.

lucky75:

2 Vad64:
А как Вы смотрите на идею использования двух AVRов для решения подобных проблем? Не конкретно USB, а в принципе.

А зачем два АВРа, какие функции параллелить и как? У меня при максимальной загрузке (формирование Futaba РСМ1024) есть еще запас производительности, процентов 50. В режиме РРМ запас вообще многократный. Причем поскольку выходной сигнал формируется по прерыванию, я уверен, что никто эту задачу не притормозит. Мне кажется, мощности одного АВРа вполне достаточно для реализации базовых функций передатчика. А если надо, проще взять более мощный процессор.

Запас не вечен, когда-нибудь иссякнет 😃 А параллелить на мой взгляд стоит, как тут уже вроде предлагалось, рилтайм и не-рилтайм части. Т.е. грубо говоря “АЦП/миксер/формирователь” и “UI/другие интерфейсы/прочие рюшечки”.

Vad64:

Апдейт прошивки через USB в этом проце - тоже с граблями. Что, если нужно устранить ошибку в самом обработчике USB или изменить дескрипторы или еще что-то? Единственный вариант тут, наверное, держать два обработчика - один в бутлоадере (без возможности обновления), а другой - для аппликейшна.

Как я когда-то писал в личной переписке, именно так и сделано у меня. Загрузчик размещается в boot area флэша и совершенно автономен и защищен фьюзом от стирания и модификации, получает управление по BOOTRST (также фьюз) и имеет собственный дескриптор. Таблица векторов прерываний также при работе бута перемещается в соответствующую область. Так что проблема надуманная (“А если надо устранить ошибку в масочном ПЗУ загрузчика” - мы в более выигрышном положении).

Связь по USB, безусловно, классная фича. Но софтверное решение на AVR мне лично не нравится - извращение. Если бы я делал все с нуля, не стал бы на него закладываться.

Все профессионалы так считают. Но если говорить о народной аппаратуре, то AVR все же более популярен, а варианты с аппаратным USB достаточно куцые по остальным возможностям (я про AVR). В данном случае решение “дешевое и сердитое”.

А еще профи против использования кооперативных RTOS, хотя в данном случае опять же все очень красивенько ложится в рамки той же jacos, бесплатной, кстати.

Также ломает решать любые лицензионные вопросы.

Вопрос один: лицензия требует публикации схем и исходников в интернете. Если аппаратура - “народная”, то так и есть. А если код закрыт, то другое дело.

Привет Всем!
Читал, читал, устал. Может модулятор всеж ктото напишет? А то Фокус в одиночестве пучится и экзамены сдает.

rulll:

Может модулятор всеж ктото напишет? А то Фокус в одиночестве пучится и экзамены сдает.

я пишу…
вот прямо сейчас и пишу …
недели через 2 думаю будет более менее рабочая прошивка…

Да на Сях ведь пишите и все равно каждый сам себе. Объединили бы усилия и быстрее бы дело пошло.

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

от знакосинтезирующего однозначно стоит отказаться.

в принципе получается даже с ним неплохо
только вот никакие кривые не задать и триммеры графически изображаются прогрессбарами

былы бы возможность поставить хороший графический а бы его поставил 😉

кривые можно, только не визуально. к примеру тот же MC-18 имеет экпоненты/миксеры и знакосинтезирующий дисплей, но это не пример для подражания.

графический дисплей от сотового - не такая уж редкая и дорогая вещь, найти можно.