[anonymous 0]

Здраствуйте.

 

Необходимо собрать схемку, в которой будет использоваться usb.

Решил делать программно...

 

И для начала решил собрать простой usb-rs232 преобразователь...

 

Так вот собственно в чем проблема... не могу въехать с какой стороны к этому всему подходить...

 

Где брать и куда писать данные, которые надо передать по USB?

 

может подкините минимальный скелет исходников для начала. (т.е. не законченную прошивку, а только то, что нужно для работы usb. например main.с без всего лишено...)

 

PowerSwitch смотрел... как понял менять под себя надо функцию usbFunctionSetup(uchar data[8]).

Это верно?

 

Заранее благодарен

[otrog 0]

Может и не совсем в тему, но посмотрите в сторону IgorPlug-USB

http://www.cesko.host.sk/IgorPlugUSB/IgorP...20(AVR)_eng.htm

[prottoss 0]

Может и не совсем в тему, но посмотрите в сторону IgorPlug-USB

http://www.cesko.host.sk/IgorPlugUSB/IgorP...20(AVR)_eng.htm

ИМХО obdev намного привлекательнее, т.к. написана на Си, что облегчает внедрение в свой проект. К тому же я читал где то в сети, по-моему даже на этом форуме, что в IgorPlug-USB нет проверки CRC. Счас как раз планирую занятся этой штуковиной, на работе все руки не доходили))), а в отпуске, вечерком можно повозится. Может тоже возникнут вопросы...

[anonymous 0]

Может и не совсем в тему, но посмотрите в сторону IgorPlug-USB

http://www.cesko.host.sk/IgorPlugUSB/IgorP...20(AVR)_eng.htm

 

увы действительно не совсем в тему :(

так как было решено остановиться на реализации USB от obdev.at

 

К тому же я читал где то в сети, по-моему даже на этом форуме, что в IgorPlug-USB нет проверки CRC.

 

насколько мне известно в реализации от obdev.at так же не считается CRC. Не успевают...

 

ЗЫ все же преимужества на вариантом от Игоря есть...

[prottoss 0]

насколько мне известно в реализации от obdev.at так же не считается CRC. Не успевают...

ЗЫ все же преимужества на вариантом от Игоря есть...

 

Если не брать в счет Си, и ему сопутствующее, какие?

[anonymous 0]

насколько мне известно в реализации от obdev.at так же не считается CRC. Не успевают...

ЗЫ все же преимужества на вариантом от Игоря есть...

 

Если не брать в счет Си, и ему сопутствующее, какие?

 

Вообщем то на obdev.at этот вопрос раскрыт:

A similar driver for the AVR series of microcontrollers is available from Igor Češko. Our USB driver has the following advantages over Igor's driver:

 

* All customizable code written in ANSI-C and thus easier to maintain.

* Modular concept: easier to integrate into existing designs.

* Slightly smaller code size in spite of high level language modules.

* Faster: All encoding/decoding (USB requires NRZI coding and bit stuffing) is done in real-time, not in the main loop after storing away the raw data stream.

* AVR-USB comes with a free shared Vendor- / Product-ID pair.

* The level of standards conformance is documented (description of limitations and potential problems).

* Available for free with Open Source license. (See the file License.txt in the distribution.)

 

для меня особенно значимы пункты 4,5,7

 

ЗЫ а по теме кто-нибудь может что-нибудь подсказать?

Изменено 23 июня, 2006 пользователем anonymous

[prottoss 0]

2anonymous извините, что в Вашей ветке задаю вопросы, но, может быть, это и Вам как то поможет)

 

Что то я дров под Win32 не вижу на их сайте, как с этим быть? Свои написать? Или я не там смотрю?

[anonymous 0]

2anonymous извините, что в Вашей ветке задаю вопросы, но, может быть, это и Вам как то поможет)

 

Что то я дров под Win32 не вижу на их сайте, как с этим быть? Свои написать? Или я не там смотрю?

 

не там :)

смотреть надо тут: http://libusb-win32.sourceforge.net/

и еще поможет вот это: http://www.mingw.org/

 

Просто надо было скачать например PowerSwitch и внимательно посмотреть ReadMe

 

еще можно использовать HID класс устройств, тогда драйверов вообще не нужно...

 

а еще есть CDC класс... драйвера идут стандартные начиная с win2k (про linux вообще не говорю)...

в результате получаете заместо работы с usb, работу с виртуальным com портом...

 

пример есть тут: http://www.recursion.jp/mitou17/forcy-avr2.html

только я по японски не понимю (но исходники прилагаются)

 

ссылку на проект с дровами увы не помню, но если нужно будет, то могу вылужить сюда. Это проект на attiny45: преобровователь uart<->usb (все софтовое) с дровами...

[aleksey_gregul 0]

prottoss, посмотрите эту ветку:

http://electronix.ru/forum/index.php?showtopic=13883&st=30

 

 

 

К anonymous_у!

<<Это проект на attiny45: преобровователь uart<->usb (все софтовое) с дровами...>>

Это очень интересно! Как бы посмотреть?

[proba 0]

http://www.recursion.jp/avrcdc/index.html

[anonymous 0]

так кто-нибудь может подсказать, где и что надо написать, что-бы сделать самое простое с использованием avr-usb?

 

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

[prottoss 0]

так кто-нибудь может подсказать, где и что надо написать, что-бы сделать самое простое с использованием avr-usb?

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

 

Вроде по англицки читаешь, а в простом разобраться не можешь) В общем то в usbdrv.h этот вопрос раскрыт:

 

....usbFunctionSetup(uchar data[8]);

/* This function is called when the driver receives a SETUP transaction from

* the host which is not answered by the driver itself (in practice: class and

* vendor requests). All control transfers start with a SETUP transaction where

* the host communicates the parameters of the following (optional) data

* transfer. The SETUP data is available in the 'data' parameter which can

* (and should) be casted to 'usbRequest_t *' for a more user-friendly access

* to parameters.

*

* If the SETUP indicates a control-in transfer, you should provide the

* requested data to the driver. There are two ways to transfer this data:

* (1) Set the global pointer 'usbMsgPtr' to the base of the static RAM data

* block and return the length of the data in 'usbFunctionSetup()'. The driver

* will handle the rest. Or (2) return 0xff in 'usbFunctionSetup()'. The driver

* will then call 'usbFunctionRead()' when data is needed. See the

* documentation for usbFunctionRead() for details.

*

* If the SETUP indicates a control-out transfer, the only way to receive the

* data from the host is through the 'usbFunctionWrite()' call. If you

* implement this function, you must return 0xff in 'usbFunctionSetup()' to

* indicate that 'usbFunctionWrite()' should be used. See the documentation of

* this function for more information. If you just want to ignore the data sent

* by the host, return 0 in 'usbFunctionSetup()'.

*

* Note that calls to the functions usbFunctionRead() and usbFunctionWrite()

* are only done if enabled by the configuration in usbconfig.h.

*/

 

 

 

... usbFunctionWrite(uchar *data, uchar len);

/* This function is called by the driver to provide a control transfer's

* payload data (control-out). It is called in chunks of up to 8 bytes. The

* total count provided in the current control transfer can be obtained from

* the 'length' property in the setup data. If an error occurred during

* processing, return 0xff (== -1). The driver will answer the entire transfer

* with a STALL token in this case. If you have received the entire payload

* successfully, return 1. If you expect more data, return 0. If you don't

* know whether the host will send more data (you should know, the total is

* provided in the usbFunctionSetup() call!), return 1.

* NOTE: If you return 0xff for STALL, 'usbFunctionWrite()' may still be called

* for the remaining data. You must continue to return 0xff for STALL in these

* calls.

* In order to get usbFunctionWrite() called, define USB_CFG_IMPLEMENT_FN_WRITE

* to 1 in usbconfig.h and return 0xff in usbFunctionSetup()..

*/

 

 

 

....usbFunctionRead(uchar *data, uchar len);

/* This function is called by the driver to ask the application for a control

* transfer's payload data (control-in). It is called in chunks of up to 8

* bytes each. You should copy the data to the location given by 'data' and

* return the actual number of bytes copied. If you return less than requested,

* the control-in transfer is terminated. If you return 0xff, the driver aborts

* the transfer with a STALL token.

* In order to get usbFunctionRead() called, define USB_CFG_IMPLEMENT_FN_READ

* to 1 in usbconfig.h and return 0xff in usbFunctionSetup()..

*/

 

 

 

Со стороны хоста (РС) пока добился связи с устройством через usb_control_msg(....) из libusb

[prottoss 0]

Работа с драйвером от obdev доволно проста и встроить его в проект на Си оказалось довольно просто. Больше возни c usblib от sourceforge ( http://libusb.sourceforge.net ) Минимум комментариев к функциям и корявый хедер(((

 

 

 

Привожу тестовый код для работы с ИАР (файл main.c)

 

 

uchar usbFunctionSetup(uchar data[8])
{ 
   TX_LED_OFF();
   RX_LED_OFF();
   SETUP_LED_ON();

// почему data[1], а не, например, data[0], еще не разобрался, кое какие подозрения есть, 

// но пока скромно промолчу дабы не вводить публику в заблуждения



    if(data[1] == 0)
    { 

       // здесь может быть код, который должен выполняться только этой функцией 

       return 0;
    }

    return 255; // хотим вызвать функции записи/чтения
}


uchar usbFunctionRead(uchar *data, uchar len)
{ 
   TX_LED_OFF();
   SETUP_LED_OFF();
   RX_LED_ON();
   return 0; // ОК
}

uchar usbFunctionWrite(uchar *data, uchar len)
{ 
   RX_LED_OFF();
   SETUP_LED_OFF();
   TX_LED_ON();
   return 1; // ОК

}


void main(void)
{ 
    usbInit();
    asm("sei");

    do
    { 
       usbPoll();
    }
    while(1);

 

Кроме того драйверу надо указать, что будут использоваться функции записи/чтения. Для этого надо в файле usbconfig.h установить макросы USB_CFG_IMPLEMENT_FN_WRITE и USB_CFG_IMPLEMENT_FN_READ в 1

 

 

 

Мне с эти кодом удалось, пока, уложится в 1775 байт, что вполне достаточно для тини2313)))

 

 

 

А это кусок исходника для C++ Borland Builder, чтобы можно было поморгать светодиодами

CBB.txt

[anonymous 0]

2 prottoss

 

вот спасибо... как то просмотрел я это все...

[prottoss 0]

В продолжении темы...А как то можно избавится от дров от source forge, сделать, допустим, CDC класс? Правда, по этому поводу меня терзают сомнения, по моему odev-avr заточен именно под эти дрова...