<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="pl-pl">
<link rel="self" type="application/atom+xml" href="https://forum.atnel.pl/feed.php?f=4&amp;t=19858&amp;mode" />

<title>ATNEL tech-forum</title>
<link href="https://forum.atnel.pl/index.php" />
<updated>2017-12-28T00:45:29+01:00</updated>

<author><name><![CDATA[ATNEL tech-forum]]></name></author>
<id>https://forum.atnel.pl/feed.php?f=4&amp;t=19858&amp;mode</id>
<entry>
<author><name><![CDATA[rskup]]></name></author>
<updated>2017-12-28T00:45:29+01:00</updated>
<published>2017-12-28T00:45:29+01:00</published>
<id>https://forum.atnel.pl/viewtopic.php?t=19858&amp;p=201149#p201149</id>
<link href="https://forum.atnel.pl/viewtopic.php?t=19858&amp;p=201149#p201149"/>
<title type="html"><![CDATA[Re: vusb linux problem z wykryciem]]></title>

<content type="html" xml:base="https://forum.atnel.pl/viewtopic.php?t=19858&amp;p=201149#p201149"><![CDATA[
Mostki z USB 3.0 są bardziej czułe na nieprawidłowe działanie podłączanego urządzenia. Musisz zagwarantować poprawne poziomy sygnałów na liniach D+ / D- oraz poprawnie przeprowadzić procedurę resetu magistrali przy podłączaniu.<br />Jakiś czas temu walczyłem z dostawcą pewnego sprzętu, który to nie działał poprawnie pod linuxem, bo ten za dużo chciał od urządzenia a ono niepoprawnie reagowało i linux w końcu je &quot;olewał&quot;. Przy okazji też wyszły problemy z podłączaniem do portów USB 3.0. Urządzenie niepoprawnie sterowało pull-upami na liniach danych i się wszystko wykładało <img src="https://forum.atnel.pl/images/smilies/icon_e_sad.gif" alt=":(" title="Smutny" />. Co ciekawe te niepoprawne sterowanie nie przeszkadzało starym mostkom USB 2.0 <img src="https://forum.atnel.pl/images/smilies/icon_e_smile.gif" alt=":)" title="Szczęśliwy" />.<br /><br />Zrób swój układ zgodnie ze schematem USBasp <!-- m --><a class="postlink" href="http://www.fischl.de/usbasp/" >http://www.fischl.de/usbasp/</a><!-- m -->. Wrzuć na początek kod oryginalny a potem zacznij modyfikować.<br /><br />-- <br />Pozdrawiam,<br />Robert<br /><br /><strong><span style="color: #808000">------------------------ [ Dodano po: 8 minutach ]</span></strong><br /><br />Zastanów się bo może warto za 10 zł zakupić na aledrogo płytkę USBasp. Może nie są one górnolotnych lotów, ale działają i do zabawy z V-USB nadają się idealnie (oczywiście nie mówię, że są to dobrze zrobione programatory ISP) <img src="https://forum.atnel.pl/images/smilies/icon_e_smile.gif" alt=":)" title="Szczęśliwy" />.<p>Statystyki: Napisane przez <a href="https://forum.atnel.pl/memberlist.php?mode=viewprofile&amp;u=3427">rskup</a> — 28 gru 2017, o 00:45</p><hr />
]]></content>
</entry>
<entry>
<author><name><![CDATA[mozerpol]]></name></author>
<updated>2017-12-27T22:05:16+01:00</updated>
<published>2017-12-27T22:05:16+01:00</published>
<id>https://forum.atnel.pl/viewtopic.php?t=19858&amp;p=201143#p201143</id>
<link href="https://forum.atnel.pl/viewtopic.php?t=19858&amp;p=201143#p201143"/>
<title type="html"><![CDATA[Re: vusb linux problem z wykryciem]]></title>

<content type="html" xml:base="https://forum.atnel.pl/viewtopic.php?t=19858&amp;p=201143#p201143"><![CDATA[
Dziekuje bardzo wszystkim za odpowiedzi <img src="https://forum.atnel.pl/images/smilies/icon_e_smile.gif" alt=":)" title="Szczęśliwy" /><br /><br /><div class="quotetitle">WoodPaker napisał(a):</div><div class="quotecontent"><br />http://forum.atnel.pl/topic6137.html?hilit=VUSB<br /></div><br />Czytalem, bardzo fajny i przydatny poradnik, co do rezystorow 68 Ohm to rowniez manipulowalem z nimi na wszystkie mozliwe sposoby.<br /><br /><div class="quotetitle">rskup napisał(a):</div><div class="quotecontent"><br />Czy na pewno masz poprawnie podefniowane descryptory?<br />Proponuję Ci wziąć na początek jakiś działający projekt oparty o V-USB i na nim się pobawić. Ja polecam projekt USBasp<br /></div><br />Probowalem juz z innymi projektami i nic to nie dało, ale z USBasp jeszcze nie, a chyba warto.<br /><br /><div class="quotetitle">roske napisał(a):</div><div class="quotecontent"><br />Co do rezystora na D+ wyjaśnienie jest w usbdrv.h:<br />&quot;... A pull-down or pull-up of 1M SHOULD be connected from D+ to +3.5V to prevent interference when no USB master is connected. If you use Zener diodes to limit the voltage on D+ and D-, you MUST use a pull-down resistor, not a pull-up....&quot;<br />I dalej:<br />&quot;Operation without an USB master:<br />The driver behaves neutral without connection to an USB master if D- reads<br />as 1. To avoid spurious interrupts, we recommend a high impedance (e.g. 1M)<br />pull-down or pull-up resistor on D+ (interrupt). If Zener diodes are used,<br />use a pull-down. If D- becomes statically 0, the driver may block in the<br />interrupt routine.&quot;<br /></div><br />Probowalem juz z roznych kombinacji, rezystor 1M do GND lub do VCC, badz tez kompletny jego brak.<br />I przepraszam najmocniej, ale nie dopisalem ze korzystam z dołączonego przeze mnie schematu + zener 3,6 V. Oczywiscie jak zasilalem uklad z 3v3 to pozbylem sie diod zenera. Mimo wszystko nic to nie zmieniło. Dziekuje za linki, skorzystałem z nich, ale niestety nic to nie pomoglo <img src="https://forum.atnel.pl/images/smilies/icon_e_sad.gif" alt=":(" title="Smutny" />.<br /><br />Co wiecej dzisiaj sprobowalem podlaczyc uklad do kilku jednostek i jest taka dziwna zależnosc<br />Jezeli komputer posiada <strong>co najmniej jeden port</strong> USB 3.0 to uklad nie dziala, nawet jezei podlacze sie do portu USB 2.0<br />Jezeli komputer <strong>nie posiada</strong> portu USB 3.0 wszystko dziala jak nalezy.<br />Nie sprawdzalem na windowsie, na linuksie taka zaleznosc wystepowala. <br />Smiem przez to twierdzic, ze moze miec na to wplyw kontroler USB na plycie glownej, ale nie dam sobie nawet wlosa z glowy za to wyrwac, bo to brzmi jak propagowanie herezji. Co wiecej jezeli projekt USBasp jest oparty na v-usb to rowniez ten programator nie powinien mi dzialac, a jest zupelnie inaczej…<br /><br />Jezli ktos na cos wpadnie, bede bardzo wdzieczny za wszystkie odpowiedzi, bo jestem ciekaw co jest nie tak.<br /><br />PS. I strasznie mocno przepraszam za RZyczenia, niech karą bedzie wstyd jakiego doznalem <img src="https://forum.atnel.pl/images/smilies/icon_e_smile.gif" alt=":)" title="Szczęśliwy" /><p>Statystyki: Napisane przez <a href="https://forum.atnel.pl/memberlist.php?mode=viewprofile&amp;u=14227">mozerpol</a> — 27 gru 2017, o 22:05</p><hr />
]]></content>
</entry>
<entry>
<author><name><![CDATA[rskup]]></name></author>
<updated>2017-12-27T16:02:44+01:00</updated>
<published>2017-12-27T16:02:44+01:00</published>
<id>https://forum.atnel.pl/viewtopic.php?t=19858&amp;p=201113#p201113</id>
<link href="https://forum.atnel.pl/viewtopic.php?t=19858&amp;p=201113#p201113"/>
<title type="html"><![CDATA[Re: vusb linux problem z wykryciem]]></title>

<content type="html" xml:base="https://forum.atnel.pl/viewtopic.php?t=19858&amp;p=201113#p201113"><![CDATA[
Czy na pewno masz poprawnie podefniowane descryptory?<br /><br />Proponuję Ci wziąć na początek jakiś działający projekt oparty o V-USB i na nim się pobawić. Ja polecam projekt USBasp, on wykorzystuje V-USB i jest prosto napisany i łatwo oddzielić warstwę USB od reszty projektu (kody i schematy dostępne na stronie projektu).<br /><br />-- <br />Pozdrawiam,<br />Robert<p>Statystyki: Napisane przez <a href="https://forum.atnel.pl/memberlist.php?mode=viewprofile&amp;u=3427">rskup</a> — 27 gru 2017, o 16:02</p><hr />
]]></content>
</entry>
<entry>
<author><name><![CDATA[WoodPaker]]></name></author>
<updated>2017-12-26T22:25:50+01:00</updated>
<published>2017-12-26T22:25:50+01:00</published>
<id>https://forum.atnel.pl/viewtopic.php?t=19858&amp;p=201083#p201083</id>
<link href="https://forum.atnel.pl/viewtopic.php?t=19858&amp;p=201083#p201083"/>
<title type="html"><![CDATA[Re: vusb linux problem z wykryciem]]></title>

<content type="html" xml:base="https://forum.atnel.pl/viewtopic.php?t=19858&amp;p=201083#p201083"><![CDATA[
Kiedyś dość dużo robiłem na V-USB. Nawet możesz gdzieś tutaj znaleźć moje poradniki o V-USB. I pierwsze co widzę to dziwaczne podłączenie do USB. Jak popatrzysz na schematy zamieszczone na stronie projektu V-USB lub jak znajdziesz mój poradnik to zobaczysz, że TYLKO linia D- podłączana jest przez rezystor do VCC. Jak poczytasz też trochę na ten temat, na forum to znajdziesz informacje, że czasem w komunikacji pomaga (na niektórych komputerach) całkowite wylutowanie tych 68Ohm rezystorów.<br /><br />No i oczywiście też Ci RZyczę WesołyH ŚwiONt  <img src="https://forum.atnel.pl/images/smilies/icon_rolleyes.gif" alt=":roll:" title="Udaje, że to nie on" /><br /><br />P.S.<br /><!-- l --><a class="postlink-local" href="http://forum.atnel.pl/topic6137.html?hilit=VUSB" >topic6137.html?hilit=VUSB</a><!-- l --><p>Statystyki: Napisane przez <a href="https://forum.atnel.pl/memberlist.php?mode=viewprofile&amp;u=1425">WoodPaker</a> — 26 gru 2017, o 22:25</p><hr />
]]></content>
</entry>
<entry>
<author><name><![CDATA[mozerpol]]></name></author>
<updated>2017-12-26T21:52:46+01:00</updated>
<published>2017-12-26T21:52:46+01:00</published>
<id>https://forum.atnel.pl/viewtopic.php?t=19858&amp;p=201082#p201082</id>
<link href="https://forum.atnel.pl/viewtopic.php?t=19858&amp;p=201082#p201082"/>
<title type="html"><![CDATA[vusb linux problem z wykryciem]]></title>

<content type="html" xml:base="https://forum.atnel.pl/viewtopic.php?t=19858&amp;p=201082#p201082"><![CDATA[
Witam<br />Moim celem jest użycie projektu vusb. Niestety napotykam na poważne problemy, z ktorymi nie jestem w stanie sobie sam poradzic. <br />zlozylem uklad wg tego schematu:<br /><a href="https://obrazkiforum.atnel.pl/14227/2becb4e618c93dbe41c9e7f847dbf626.png"  class="postlink"><img src="https://obrazkiforum.atnel.pl/thumb/14227/2becb4e618c93dbe41c9e7f847dbf626.png" alt="Obrazek" /></a><br /><br />Uklad na plytce wyglada tak:<br /><a href="https://obrazkiforum.atnel.pl/14227/3e9c6a5c5691daecee07a6c51df1491a.jpg"  class="postlink"><img src="https://obrazkiforum.atnel.pl/thumb/14227/3e9c6a5c5691daecee07a6c51df1491a.jpg" alt="Obrazek" /></a><br /><br />Procek to atmega16A taktowana zegarem 12 MHz, linia D+ (do INT0) to zielony przewod, natomiast D- (do INT1) to bialy przewod. Oba sa podlaczone przez rezystor 68 om + zener 3,6 V. Dodatkowo D+ jest podciagniety do VCC przez rezystor 1M om, a D- do VCC, przez reyzstor 1,5K om. Sam procek zasilany jest z 5 V (dzieki USB), w pliku usbconfig.h oczywiscie jest to uwzglednione.<br /><br />Wgrywam taki program do procka:<br />Plik main:<br />[syntax=c]#include&lt;avr/io.h&gt;<br />#include&lt;avr/interrupt.h&gt;<br />#include&lt;avr/wdt.h&gt;<br />#include&lt;util/delay.h&gt;<br />#include&quot;usbdrv.h&quot;<br />#define F_CPU 12000000<br /><br />#define USB_LED_OFF 0<br />#define USB_LED_ON 1<br /><br />USB_PUBLIC uchar usbFunctionSetup(uchar data&#91;8&#93;)//funkcja obslugujaca wywolania USB, mozna ja wykorzystac do wysylania danych satycznych. Natomiast<br />{//jesli chcemy przesyłać dane odczytywane &quot;w locie&quot; winnismy użyć funkcji usbFunctionRead.<br />usbRequest_t *rq = (void *)data;<br />switch(rq-&gt;bRequest) // custom command is in the bRequest field<br />{<br />    case USB_LED_ON:<br />        PORTB |= 1; // turn LED on<br />        return 0;<br />    case USB_LED_OFF:<br />        PORTB &amp;= ~1; // turn LED off<br />        return 0;<br />    }<br /><br />return 0;// Narazie nic nie rób<br />}<br /><br />int main()<br />{<br />uchar i;<br />DDRB = 1; // PB0 as output<br /><br />wdt_enable(WDTO_1S);// uaktywnij jednosekundowy watchdog<br /><br />usbInit();//inicjuje biblioteke VUSB<br /><br />usbDeviceDisconnect();// Wymuś przenumerowanie<br />for(i =0; i&lt;250; i++)<br />{// Odczekaj około 500 ms<br />wdt_reset();// Poinformuj watchdog, ze procesor działa<br />_delay_ms(2);<br />}<br />usbDeviceConnect();<br /><br />sei();// Aktywuj przerwania po renumeracji<br /><br />while(1){<br />wdt_reset();// wiadomo, jak wyżej<br />usbPoll();<br />}<br /><br />return 0;<br />}[/syntax]<br /><br />Plik usbconfig.h:<br />[syntax=c]#ifndef __usbconfig_h_included__<br />#define __usbconfig_h_included__<br /><br />/*<br />General Description:<br />This file is an example configuration (with inline documentation) for the USB<br />driver. It configures V-USB for USB D+ connected to Port D bit 2 (which is<br />also hardware interrupt 0 on many devices) and USB D- to Port D bit 4. You may<br />wire the lines to any other port, as long as D+ is also wired to INT0 (or any<br />other hardware interrupt, as long as it is the highest level interrupt, see<br />section at the end of this file).<br />+ To create your own usbconfig.h file, copy this file to your project's<br />+ firmware source directory) and rename it to &quot;usbconfig.h&quot;.<br />+ Then edit it accordingly.<br />*/<br /><br />/* ---------------------------- Hardware Config ---------------------------- */<br /><br />#define USB_CFG_IOPORTNAME      D<br />/* This is the port where the USB bus is connected. When you configure it to<br /> * &quot;B&quot;, the registers PORTB, PINB and DDRB will be used.<br /> */<br />#define USB_CFG_DMINUS_BIT      3<br />/* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected.<br /> * This may be any bit in the port.<br /> */<br />#define USB_CFG_DPLUS_BIT       2<br />/* This is the bit number in USB_CFG_IOPORT where the USB D+ line is connected.<br /> * This may be any bit in the port. Please note that D+ must also be connected<br /> * to interrupt pin INT0! &#91;You can also use other interrupts, see section<br /> * &quot;Optional MCU Description&quot; below, or you can connect D- to the interrupt, as<br /> * it is required if you use the USB_COUNT_SOF feature. If you use D- for the<br /> * interrupt, the USB interrupt will also be triggered at Start-Of-Frame<br /> * markers every millisecond.&#93;<br /> */<br />#define F_CPU 12000000<br />#define USB_CFG_CLOCK_KHZ       (F_CPU/1000)<br />/* Clock rate of the AVR in kHz. Legal values are 12000, 12800, 15000, 16000,<br /> * 16500, 18000 and 20000. The 12.8 MHz and 16.5 MHz versions of the code<br /> * require no crystal, they tolerate +/- 1% deviation from the nominal<br /> * frequency. All other rates require a precision of 2000 ppm and thus a<br /> * crystal!<br /> * Since F_CPU should be defined to your actual clock rate anyway, you should<br /> * not need to modify this setting.<br /> */<br />#define USB_CFG_CHECK_CRC       0<br />/* Define this to 1 if you want that the driver checks integrity of incoming<br /> * data packets (CRC checks). CRC checks cost quite a bit of code size and are<br /> * currently only available for 18 MHz crystal clock. You must choose<br /> * USB_CFG_CLOCK_KHZ = 18000 if you enable this option.<br /> */<br /><br />/* ----------------------- Optional Hardware Config ------------------------ */<br /><br />/* #define USB_CFG_PULLUP_IOPORTNAME   D */<br />/* If you connect the 1.5k pullup resistor from D- to a port pin instead of<br /> * V+, you can connect and disconnect the device from firmware by calling<br /> * the macros usbDeviceConnect() and usbDeviceDisconnect() (see usbdrv.h).<br /> * This constant defines the port on which the pullup resistor is connected.<br /> */<br />/* #define USB_CFG_PULLUP_BIT          4 */<br />/* This constant defines the bit number in USB_CFG_PULLUP_IOPORT (defined<br /> * above) where the 1.5k pullup resistor is connected. See description<br /> * above for details.<br /> */<br /><br />/* --------------------------- Functional Range ---------------------------- */<br /><br />#define USB_CFG_HAVE_INTRIN_ENDPOINT    0<br />/* Define this to 1 if you want to compile a version with two endpoints: The<br /> * default control endpoint 0 and an interrupt-in endpoint (any other endpoint<br /> * number).<br /> */<br />#define USB_CFG_HAVE_INTRIN_ENDPOINT3   0<br />/* Define this to 1 if you want to compile a version with three endpoints: The<br /> * default control endpoint 0, an interrupt-in endpoint 3 (or the number<br /> * configured below) and a catch-all default interrupt-in endpoint as above.<br /> * You must also define USB_CFG_HAVE_INTRIN_ENDPOINT to 1 for this feature.<br /> */<br />#define USB_CFG_EP3_NUMBER              3<br />/* If the so-called endpoint 3 is used, it can now be configured to any other<br /> * endpoint number (except 0) with this macro. Default if undefined is 3.<br /> */<br />/* #define USB_INITIAL_DATATOKEN           USBPID_DATA1 */<br />/* The above macro defines the startup condition for data toggling on the<br /> * interrupt/bulk endpoints 1 and 3. Defaults to USBPID_DATA1.<br /> * Since the token is toggled BEFORE sending any data, the first packet is<br /> * sent with the oposite value of this configuration!<br /> */<br />#define USB_CFG_IMPLEMENT_HALT          0<br />/* Define this to 1 if you also want to implement the ENDPOINT_HALT feature<br /> * for endpoint 1 (interrupt endpoint). Although you may not need this feature,<br /> * it is required by the standard. We have made it a config option because it<br /> * bloats the code considerably.<br /> */<br />#define USB_CFG_SUPPRESS_INTR_CODE      0<br />/* Define this to 1 if you want to declare interrupt-in endpoints, but don't<br /> * want to send any data over them. If this macro is defined to 1, functions<br /> * usbSetInterrupt() and usbSetInterrupt3() are omitted. This is useful if<br /> * you need the interrupt-in endpoints in order to comply to an interface<br /> * (e.g. HID), but never want to send any data. This option saves a couple<br /> * of bytes in flash memory and the transmit buffers in RAM.<br /> */<br />#define USB_CFG_INTR_POLL_INTERVAL      10<br />/* If you compile a version with endpoint 1 (interrupt-in), this is the poll<br /> * interval. The value is in milliseconds and must not be less than 10 ms for<br /> * low speed devices.<br /> */<br />#define USB_CFG_IS_SELF_POWERED         0<br />/* Define this to 1 if the device has its own power supply. Set it to 0 if the<br /> * device is powered from the USB bus.<br /> */<br />#define USB_CFG_MAX_BUS_POWER           100<br />/* Set this variable to the maximum USB bus power consumption of your device.<br /> * The value is in milliamperes. &#91;It will be divided by two since USB<br /> * communicates power requirements in units of 2 mA.&#93;<br /> */<br />#define USB_CFG_IMPLEMENT_FN_WRITE      0<br />/* Set this to 1 if you want usbFunctionWrite() to be called for control-out<br /> * transfers. Set it to 0 if you don't need it and want to save a couple of<br /> * bytes.<br /> */<br />#define USB_CFG_IMPLEMENT_FN_READ       0<br />/* Set this to 1 if you need to send control replies which are generated<br /> * &quot;on the fly&quot; when usbFunctionRead() is called. If you only want to send<br /> * data from a static buffer, set it to 0 and return the data from<br /> * usbFunctionSetup(). This saves a couple of bytes.<br /> */<br />#define USB_CFG_IMPLEMENT_FN_WRITEOUT   0<br />/* Define this to 1 if you want to use interrupt-out (or bulk out) endpoints.<br /> * You must implement the function usbFunctionWriteOut() which receives all<br /> * interrupt/bulk data sent to any endpoint other than 0. The endpoint number<br /> * can be found in 'usbRxToken'.<br /> */<br />#define USB_CFG_HAVE_FLOWCONTROL        0<br />/* Define this to 1 if you want flowcontrol over USB data. See the definition<br /> * of the macros usbDisableAllRequests() and usbEnableAllRequests() in<br /> * usbdrv.h.<br /> */<br />#define USB_CFG_DRIVER_FLASH_PAGE       0<br />/* If the device has more than 64 kBytes of flash, define this to the 64 k page<br /> * where the driver's constants (descriptors) are located. Or in other words:<br /> * Define this to 1 for boot loaders on the ATMega128.<br /> */<br />#define USB_CFG_LONG_TRANSFERS          0<br />/* Define this to 1 if you want to send/receive blocks of more than 254 bytes<br /> * in a single control-in or control-out transfer. Note that the capability<br /> * for long transfers increases the driver size.<br /> */<br />/* #define USB_RX_USER_HOOK(data, len)     if(usbRxToken == (uchar)USBPID_SETUP) blinkLED(); */<br />/* This macro is a hook if you want to do unconventional things. If it is<br /> * defined, it's inserted at the beginning of received message processing.<br /> * If you eat the received message and don't want default processing to<br /> * proceed, do a return after doing your things. One possible application<br /> * (besides debugging) is to flash a status LED on each packet.<br /> */<br />/* #define USB_RESET_HOOK(resetStarts)     if(!resetStarts){hadUsbReset();} */<br />/* This macro is a hook if you need to know when an USB RESET occurs. It has<br /> * one parameter which distinguishes between the start of RESET state and its<br /> * end.<br /> */<br />/* #define USB_SET_ADDRESS_HOOK()              hadAddressAssigned(); */<br />/* This macro (if defined) is executed when a USB SET_ADDRESS request was<br /> * received.<br /> */<br />#define USB_COUNT_SOF                   0<br />/* define this macro to 1 if you need the global variable &quot;usbSofCount&quot; which<br /> * counts SOF packets. This feature requires that the hardware interrupt is<br /> * connected to D- instead of D+.<br /> */<br />/* #ifdef __ASSEMBLER__<br /> * macro myAssemblerMacro<br /> *     in      YL, TCNT0<br /> *     sts     timer0Snapshot, YL<br /> *     endm<br /> * #endif<br /> * #define USB_SOF_HOOK                    myAssemblerMacro<br /> * This macro (if defined) is executed in the assembler module when a<br /> * Start Of Frame condition is detected. It is recommended to define it to<br /> * the name of an assembler macro which is defined here as well so that more<br /> * than one assembler instruction can be used. The macro may use the register<br /> * YL and modify SREG. If it lasts longer than a couple of cycles, USB messages<br /> * immediately after an SOF pulse may be lost and must be retried by the host.<br /> * What can you do with this hook? Since the SOF signal occurs exactly every<br /> * 1 ms (unless the host is in sleep mode), you can use it to tune OSCCAL in<br /> * designs running on the internal RC oscillator.<br /> * Please note that Start Of Frame detection works only if D- is wired to the<br /> * interrupt, not D+. THIS IS DIFFERENT THAN MOST EXAMPLES!<br /> */<br />#define USB_CFG_CHECK_DATA_TOGGLING     0<br />/* define this macro to 1 if you want to filter out duplicate data packets<br /> * sent by the host. Duplicates occur only as a consequence of communication<br /> * errors, when the host does not receive an ACK. Please note that you need to<br /> * implement the filtering yourself in usbFunctionWriteOut() and<br /> * usbFunctionWrite(). Use the global usbCurrentDataToken and a static variable<br /> * for each control- and out-endpoint to check for duplicate packets.<br /> */<br />#define USB_CFG_HAVE_MEASURE_FRAME_LENGTH   0<br />/* define this macro to 1 if you want the function usbMeasureFrameLength()<br /> * compiled in. This function can be used to calibrate the AVR's RC oscillator.<br /> */<br />#define USB_USE_FAST_CRC                0<br />/* The assembler module has two implementations for the CRC algorithm. One is<br /> * faster, the other is smaller. This CRC routine is only used for transmitted<br /> * messages where timing is not critical. The faster routine needs 31 cycles<br /> * per byte while the smaller one needs 61 to 69 cycles. The faster routine<br /> * may be worth the 32 bytes bigger code size if you transmit lots of data and<br /> * run the AVR close to its limit.<br /> */<br /><br />/* -------------------------- Device Description --------------------------- */<br /><br />#define  USB_CFG_VENDOR_ID       0xc0, 0x16 /* = 0x16c0 = 5824 = voti.nl */<br />/* USB vendor ID for the device, low byte first. If you have registered your<br /> * own Vendor ID, define it here. Otherwise you may use one of obdev's free<br /> * shared VID/PID pairs. Be sure to read USB-IDs-for-free.txt for rules!<br /> * *** IMPORTANT NOTE ***<br /> * This template uses obdev's shared VID/PID pair for Vendor Class devices<br /> * with libusb: 0x16c0/0x5dc.  Use this VID/PID pair ONLY if you understand<br /> * the implications!<br /> */<br />#define  USB_CFG_DEVICE_ID       0xdc, 0x05 /* = 0x05dc = 1500 */<br />/* This is the ID of the product, low byte first. It is interpreted in the<br /> * scope of the vendor ID. If you have registered your own VID with usb.org<br /> * or if you have licensed a PID from somebody else, define it here. Otherwise<br /> * you may use one of obdev's free shared VID/PID pairs. See the file<br /> * USB-IDs-for-free.txt for details!<br /> * *** IMPORTANT NOTE ***<br /> * This template uses obdev's shared VID/PID pair for Vendor Class devices<br /> * with libusb: 0x16c0/0x5dc.  Use this VID/PID pair ONLY if you understand<br /> * the implications!<br /> */<br />#define USB_CFG_DEVICE_VERSION  0x00, 0x01<br />/* Version number of the device: Minor number first, then major number.<br /> */<br />#define USB_CFG_VENDOR_NAME     'm', 'o', 'z', 'e', 'r', 'p', 'o', 'l'<br />#define USB_CFG_VENDOR_NAME_LEN 8<br />/* These two values define the vendor name returned by the USB device. The name<br /> * must be given as a list of characters under single quotes. The characters<br /> * are interpreted as Unicode (UTF-16) entities.<br /> * If you don't want a vendor name string, undefine these macros.<br /> * ALWAYS define a vendor name containing your Internet domain name if you use<br /> * obdev's free shared VID/PID pair. See the file USB-IDs-for-free.txt for<br /> * details.<br /> */<br />#define USB_CFG_DEVICE_NAME     'm', 'o', 'z', 'z', 'z', 'z', 'e', 'r'<br />#define USB_CFG_DEVICE_NAME_LEN 8<br />/* Same as above for the device name. If you don't want a device name, undefine<br /> * the macros. See the file USB-IDs-for-free.txt before you assign a name if<br /> * you use a shared VID/PID.<br /> */<br />/*#define USB_CFG_SERIAL_NUMBER   'N', 'o', 'n', 'e' */<br />/*#define USB_CFG_SERIAL_NUMBER_LEN   0 */<br />/* Same as above for the serial number. If you don't want a serial number,<br /> * undefine the macros.<br /> * It may be useful to provide the serial number through other means than at<br /> * compile time. See the section about descriptor properties below for how<br /> * to fine tune control over USB descriptors such as the string descriptor<br /> * for the serial number.<br /> */<br />#define USB_CFG_DEVICE_CLASS        0xff    /* set to 0 if deferred to interface */<br />#define USB_CFG_DEVICE_SUBCLASS     0<br />/* See USB specification if you want to conform to an existing device class.<br /> * Class 0xff is &quot;vendor specific&quot;.<br /> */<br />#define USB_CFG_INTERFACE_CLASS     0   /* define class here if not at device level */<br />#define USB_CFG_INTERFACE_SUBCLASS  0<br />#define USB_CFG_INTERFACE_PROTOCOL  0<br />/* See USB specification if you want to conform to an existing device class or<br /> * protocol. The following classes must be set at interface level:<br /> * HID class is 3, no subclass and protocol required (but may be useful!)<br /> * CDC class is 2, use subclass 2 and protocol 1 for ACM<br /> */<br />/* #define USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH    42 */<br />/* Define this to the length of the HID report descriptor, if you implement<br /> * an HID device. Otherwise don't define it or define it to 0.<br /> * If you use this define, you must add a PROGMEM character array named<br /> * &quot;usbHidReportDescriptor&quot; to your code which contains the report descriptor.<br /> * Don't forget to keep the array and this define in sync!<br /> */<br /><br />/* #define USB_PUBLIC static */<br />/* Use the define above if you #include usbdrv.c instead of linking against it.<br /> * This technique saves a couple of bytes in flash memory.<br /> */<br /><br />/* ------------------- Fine Control over USB Descriptors ------------------- */<br />/* If you don't want to use the driver's default USB descriptors, you can<br /> * provide our own. These can be provided as (1) fixed length static data in<br /> * flash memory, (2) fixed length static data in RAM or (3) dynamically at<br /> * runtime in the function usbFunctionDescriptor(). See usbdrv.h for more<br /> * information about this function.<br /> * Descriptor handling is configured through the descriptor's properties. If<br /> * no properties are defined or if they are 0, the default descriptor is used.<br /> * Possible properties are:<br /> *   + USB_PROP_IS_DYNAMIC: The data for the descriptor should be fetched<br /> *     at runtime via usbFunctionDescriptor(). If the usbMsgPtr mechanism is<br /> *     used, the data is in FLASH by default. Add property USB_PROP_IS_RAM if<br /> *     you want RAM pointers.<br /> *   + USB_PROP_IS_RAM: The data returned by usbFunctionDescriptor() or found<br /> *     in static memory is in RAM, not in flash memory.<br /> *   + USB_PROP_LENGTH(len): If the data is in static memory (RAM or flash),<br /> *     the driver must know the descriptor's length. The descriptor itself is<br /> *     found at the address of a well known identifier (see below).<br /> * List of static descriptor names (must be declared PROGMEM if in flash):<br /> *   char usbDescriptorDevice&#91;&#93;;<br /> *   char usbDescriptorConfiguration&#91;&#93;;<br /> *   char usbDescriptorHidReport&#91;&#93;;<br /> *   char usbDescriptorString0&#91;&#93;;<br /> *   int usbDescriptorStringVendor&#91;&#93;;<br /> *   int usbDescriptorStringDevice&#91;&#93;;<br /> *   int usbDescriptorStringSerialNumber&#91;&#93;;<br /> * Other descriptors can't be provided statically, they must be provided<br /> * dynamically at runtime.<br /> *<br /> * Descriptor properties are or-ed or added together, e.g.:<br /> * #define USB_CFG_DESCR_PROPS_DEVICE   (USB_PROP_IS_RAM | USB_PROP_LENGTH(18))<br /> *<br /> * The following descriptors are defined:<br /> *   USB_CFG_DESCR_PROPS_DEVICE<br /> *   USB_CFG_DESCR_PROPS_CONFIGURATION<br /> *   USB_CFG_DESCR_PROPS_STRINGS<br /> *   USB_CFG_DESCR_PROPS_STRING_0<br /> *   USB_CFG_DESCR_PROPS_STRING_VENDOR<br /> *   USB_CFG_DESCR_PROPS_STRING_PRODUCT<br /> *   USB_CFG_DESCR_PROPS_STRING_SERIAL_NUMBER<br /> *   USB_CFG_DESCR_PROPS_HID<br /> *   USB_CFG_DESCR_PROPS_HID_REPORT<br /> *   USB_CFG_DESCR_PROPS_UNKNOWN (for all descriptors not handled by the driver)<br /> *<br /> * Note about string descriptors: String descriptors are not just strings, they<br /> * are Unicode strings prefixed with a 2 byte header. Example:<br /> * int  serialNumberDescriptor&#91;&#93; = {<br /> *     USB_STRING_DESCRIPTOR_HEADER(6),<br /> *     'S', 'e', 'r', 'i', 'a', 'l'<br /> * };<br /> */<br /><br />#define USB_CFG_DESCR_PROPS_DEVICE                  0<br />#define USB_CFG_DESCR_PROPS_CONFIGURATION           0<br />#define USB_CFG_DESCR_PROPS_STRINGS                 0<br />#define USB_CFG_DESCR_PROPS_STRING_0                0<br />#define USB_CFG_DESCR_PROPS_STRING_VENDOR           0<br />#define USB_CFG_DESCR_PROPS_STRING_PRODUCT          0<br />#define USB_CFG_DESCR_PROPS_STRING_SERIAL_NUMBER    0<br />#define USB_CFG_DESCR_PROPS_HID                     0<br />#define USB_CFG_DESCR_PROPS_HID_REPORT              0<br />#define USB_CFG_DESCR_PROPS_UNKNOWN                 0<br /><br /><br />#define usbMsgPtr_t unsigned short<br />/* If usbMsgPtr_t is not defined, it defaults to 'uchar *'. We define it to<br /> * a scalar type here because gcc generates slightly shorter code for scalar<br /> * arithmetics than for pointer arithmetics. Remove this define for backward<br /> * type compatibility or define it to an 8 bit type if you use data in RAM only<br /> * and all RAM is below 256 bytes (tiny memory model in IAR CC).<br /> */<br /><br />/* ----------------------- Optional MCU Description ------------------------ */<br /><br />/* The following configurations have working defaults in usbdrv.h. You<br /> * usually don't need to set them explicitly. Only if you want to run<br /> * the driver on a device which is not yet supported or with a compiler<br /> * which is not fully supported (such as IAR C) or if you use a differnt<br /> * interrupt than INT0, you may have to define some of these.<br /> */<br />/* #define USB_INTR_CFG            MCUCR */<br />/* #define USB_INTR_CFG_SET        ((1 &lt;&lt; ISC00) | (1 &lt;&lt; ISC01)) */<br />/* #define USB_INTR_CFG_CLR        0 */<br />/* #define USB_INTR_ENABLE         GIMSK */<br />/* #define USB_INTR_ENABLE_BIT     INT0 */<br />/* #define USB_INTR_PENDING        GIFR */<br />/* #define USB_INTR_PENDING_BIT    INTF0 */<br />/* #define USB_INTR_VECTOR         INT0_vect */<br /><br />#endif /* __usbconfig_h_included__ */[/syntax]<br /><br />Po poprawnym wgraniu podaczam sie do portu USB w swoim laptopie. Otrzymuje niestety taki wynik w dmesg:<br />[ 4137.610467] usb 3-1: new low-speed USB device number 3 using xhci_hcd<br />[ 4137.730530] usb 3-1: device descriptor read/64, error -71<br />[ 4137.958523] usb 3-1: device descriptor read/64, error -71<br />[ 4138.186535] usb 3-1: new low-speed USB device number 4 using xhci_hcd<br />[ 4138.306564] usb 3-1: device descriptor read/64, error -71<br />[ 4138.534613] usb 3-1: device descriptor read/64, error -71<br />[ 4138.762559] usb 3-1: new low-speed USB device number 5 using xhci_hcd<br />[ 4138.763103] usb 3-1: Device not responding to setup address.<br />[ 4138.971147] usb 3-1: Device not responding to setup address.<br />[ 4139.178661] usb 3-1: device not accepting address 5, error -71<br />[ 4139.298650] usb 3-1: new low-speed USB device number 6 using xhci_hcd<br />[ 4139.299190] usb 3-1: Device not responding to setup address.<br />[ 4139.507196] usb 3-1: Device not responding to setup address.<br />[ 4139.714658] usb 3-1: device not accepting address 6, error -71<br />[ 4139.714707] usb usb3-port1: unable to enumerate USB device<br />[ 4140.430730] usb 3-1: new low-speed USB device number 7 using xhci_hcd<br />[ 4140.550777] usb 3-1: device descriptor read/64, error -71<br />[ 4140.778791] usb 3-1: device descriptor read/64, error -71<br />[ 4141.006811] usb 3-1: new low-speed USB device number 8 using xhci_hcd<br />[ 4141.126845] usb 3-1: device descriptor read/64, error -71<br />[ 4141.354859] usb 3-1: device descriptor read/64, error -71<br /><br />Komenda lsusb nie pokazuje, aby podlaczono nowe urzadzenie. <br /><br />Nie mam najmniejszego pojecia co zrobic, aby wszystko dzialalo jak nalezy. <br />Co zrobilem do tej pory:<br />- wgranie programu do swiecenia dioda, aby sprawdzic, czy fusy sa ok oraz same podlaczenie, to dziala<br />- wymiana kwarcu na 16 Mhz<br />- zmiana rezystora 1,5K om na mniejsze inne wartosci<br />- dołożenie kondensatorow 100 nF, 10 nF, 10 uF przy linii zasilajacej, tzn przy &quot;+&quot; oraz &quot;-&quot; z USB<br />- zasilanie ukladu z programatora i uwzglednienie tego w usbconfig.h<br />- zasilenie 3v3 i wyrzucenie zenera<br />- wgrywanie gotowych projektow z vusb, zeby wykluczyc moje bledy<br />- kombinacje z wszystkim powyzszym<br /><br />Odpalilem rowniez inny system z live cd, ten sam efekt, czyli dmesg wywala blad, a lsusb nic nie pokazuje. Kolejna proba bylo podlaczenie urzadzenia do kompa, ktory jest sprzed dobrych dziesieciu lat, na ktorym smiga debian net install (czyli absolutne minimum, ktore je 8 MB ramu) i oto co uzyskalem: <br /><a href="https://obrazkiforum.atnel.pl/14227/b94ae7d9884961f57e9dec2776feaafc.jpg"  class="postlink"><img src="https://obrazkiforum.atnel.pl/thumb/14227/b94ae7d9884961f57e9dec2776feaafc.jpg" alt="Obrazek" /></a><br /><br />I to jest najlepsze, ze po wielu dniach walki z vusb, okazalo sie ze wszystko dziala <img src="https://forum.atnel.pl/images/smilies/icon_e_biggrin.gif" alt=":D" title="Bardzo szczęśliwy" /><br />Laptop, na ktorym vusb nie dziala posiada dwa porty USB 3.0 i jeden USB 2.0, na kazdym ten sam efekt, <br />Komputer na ktorym dzialalo ma wylacznie porty USB 2.0<br />Dystrybucje obu jednostek roznia sie wylacznie tym, ze laptop ma pelna wersje debiana, a komputer net install. <br />Teraz mam dwa pytania.<br />Jak zyc, zeby wszystko dzialalo na moim laptopie? <br />Czy ktos uzywal vusb z portem USB 3.0 (ale osobiscie uzywal, a nie kolega kolegi lub pan na forum kupil u chinczyka...)<br />I chce uniknac sprzetowego usb, poki co... <br /><br />Dziekuje za udzielona mi pomoc <img src="https://forum.atnel.pl/images/smilies/icon_e_smile.gif" alt=":)" title="Szczęśliwy" /><br />I wszystkim rzycze wesołych świat <img src="https://forum.atnel.pl/images/smilies/icon_e_smile.gif" alt=":)" title="Szczęśliwy" /><p>Statystyki: Napisane przez <a href="https://forum.atnel.pl/memberlist.php?mode=viewprofile&amp;u=14227">mozerpol</a> — 26 gru 2017, o 21:52</p><hr />
]]></content>
</entry>
</feed>