ATNEL tech-forum

Re: V-USB - ATMEGA1284 - intx

2021-01-27T21:59:10+01:00

Slawek napisał(a):

Uważam ze dostałem od ciebie po uszach

Ja pierdziu! gdzie ja tobie po uszach dawałem, gdzie ja cię krytykowałem? - podpowiadam coś z dobrego serca a ten mi tu spazmów dostaje - no ja pierdziu. Idź pan .... nie powiem gdzie - nie mam zamiaru dalej dyskutować w takim tonie.

Slawek napisał(a):

, czego się zresztą spodziewałem na początku.

a niby po czym się spodziewałeś ... no chore podejście.

I weź tu człowieku staraj się pomóc - zawsze się znajdzie taki jeden co to napisze że go opierdzielam chociaż nawet mi przez myśl to nie przeszło bo i za co miałbym to robić - ale już po pierwszym twoim poście widziałem że jakoś tak zadziornie zaczynasz pisać.

Statystyki: Napisane przez mirekk36 — 27 sty 2021, o 21:59

Re: V-USB - ATMEGA1284 - intx

2021-01-27T20:01:49+01:00

Nie zgadzam się z tym co napisałeś.
Niemniej to ty piszesz na forum że asynchroniczne przerwania nie działają i potem w suplemencie też ty to powtarzasz.
Skoro wymagasz ode mnie rzetelności w pisaniu posta, czym się nawet zgadzam. Uważam ze dostałem od ciebie po uszach, czego się zresztą spodziewałem na początku. Co prawda myślałem że jak zapytam wprost na forum zamiast siedzenia nad notami będzie łatwej. Zresztą nie pisałem że nie rozumiem tekstu tylko że nie rozumiem różnicy w wymienionych przerwaniach , a to jednak co innego. Dla jasności doczytałem głębiej, więc teraz już wiem.
To cichłbym abyś teraz sam był fair i powiedział dlaczego tak piszesz i potem mówisz. Czy sprawdzałeś to, że asynchroniczne nie działają, skąd masz taką wiedzę. Bo nie tłumacząc co masz namyśli masz mój poziom, który skrytykowałeś w delikatny wprawdzie sposób.

Statystyki: Napisane przez Slawek — 27 sty 2021, o 20:01

Re: V-USB - ATMEGA1284 - intx

2021-01-26T20:15:52+01:00

Slawek napisał(a):

Ktoś (w takim sensie ktoś, osoba bo chyba nie potrzebujesz tu imienia bo i tak nie pamiętam) opisywała jak w dokumentacji atmela opisane są przerwania. Co innego w datasheet, co innego w przykładach i dopiero w erracie co nieco się wyjaśnia.

Oczywiście że mi nie są potrzebne ani imiona ani numery butów ani inne dane osobowe - a po choinkę. Nadal jednak twierdzę, żebyś ty zamiast się skupiać na tym co ktoś tam napisał i że jak czegoś nie zrozumiał to pisał dziwne rzeczy - to sam zajrzyj do noty, zobacz, porównaj i napisz czego nie rozumiesz. Bo teraz to już dziwnie piszesz po tym co na górze starałem się wyjaśnić i podać ci trop co i jak jest opisane w nocie - a ty dalej swoje, że ktoś coś tam napisał sobie. W internecie jest mnóstwo bzdur i nic na to nie poradzisz.

W ogóle nie rozumiem co tu wyjaśniać jak chodzi o różnice w działaniu tych przerwań skoro w nocie PDF jest to opisane jasno i prosto jak byk. A i tak w 99% przypadków nikt nie wykorzystuje w jakiś zaawansowany sposób różnic jakie niosą za sobą działania tych przerwań.

Slawek napisał(a):

Jaki wpływ na pracę biblioteki V-USB to mam.

Wpływu nie ma - skoro ktoś przewidział w swojej bibliotece że mogą być użyte tylko przerwania synchroniczne no to co na to poradzisz. Poza tym biblioteka V-USB wykorzystuje w sposób drastycznie zaawansowany zależności czasowe, dlatego spora jej część napisana jest w asemblerze i co ciekawe w zależności od częstotliwości taktowania wstawki asemblerowe również drastycznie muszą się różnić, bo rozkazy asm dobierane są tak aby zgadzały się czasówki do prawie pojedynczych taktów zegara.

Poza tym pokazałem ci wyżej fragment noty - możesz sobie ten tekst wrzucić do gogle translate zawsze - jeśli np do końca coś tam po angielsku nie rozumiesz - co za problem?

Ale ok jest tam napisane że przerwania od zbocza narastającego czy opadającego dla przerwania wyzwalane są asynchronicznie czyli niezależnie od sygnału CLK, za to muszą się zmieścić zgodnie z podaną tam tabelą w odpowiedniej ilości cykli zegara. W związku z tym, np krótsze impulsy mogą nie być w ogóle "zauważone" przez procka.

Ja wprawdzie nie analizowałem na poziomie asemblera wykorzystania przerwań INTx w V-USB - spojrzałem tylko na dostępne bity konfiguracyjne do ustawienia dla przerwań i po tym widać, że autorzy V-USB zdecydowali się na synchroniczne przerwania jeśli chodzi o INTx. Trzeba byłoby posiedzieć nad analizą kodu asemblera i ręcznie liczyć cykle i co robi kod - a jednocześnie poznać od podszewki czysty protokół USB żeby sobie odpowiedzieć na takie pytanie - tylko czy jest sens ? Ja nie widzę takiego sensu. Jeśli ty widzisz - to już wiesz co musisz zrobić żeby zaspokoić ciekawość dalej.

Statystyki: Napisane przez mirekk36 — 26 sty 2021, o 20:15

Re: V-USB - ATMEGA1284 - intx

2021-01-26T19:34:30+01:00

Wydawało się proste pytanie a się skomplikowało.
"Ludzie" to było spontaniczne wtrącenie. Mało ważne kto i co, ale szukając informacji o przerwaniach natrafiłem na ciekawy wpis na AVRFreaks. Ktoś (w takim sensie ktoś, osoba bo chyba nie potrzebujesz tu imienia bo i tak nie pamiętam) opisywała jak w dokumentacji atmela opisane są przerwania. Co innego w datasheet, co innego w przykładach i dopiero w erracie co nieco się wyjaśnia.

Mnie chodziło o to dlaczego piszesz

mirekk36 napisał(a):

musisz sprawdzić ale z tego co pamiętam to to przerwanie się nie nadaje bo jest asynchroniczne

Jaki wpływ na pracę biblioteki V-USB to mam.
Jeśli nie doczytałem tego w orangebooku to przepraszam i proszę o podanie na której stronie to jest, jeśli nie ma to proszę wyjaśnij dlaczego tak mówisz.

Statystyki: Napisane przez Slawek — 26 sty 2021, o 19:34

Re: V-USB - ATMEGA1284 - intx

2021-01-26T09:59:31+01:00

Slawek napisał(a):

i nawet ludzie opisują że Atmel wprowadził pewne zamieszanie w nich (myli ich opisy w stosunku do pinów)

Przepraszam ale co to za ludzie ? Bez żadnej złośliwości ale najczęściej to jakieś początkujące osoby jak już, które nie dostrzegają tego, że praktycznie w każdym procku AVR działają one IDENTYCZNIE, że praktycznie notę z jednego procka można używać prawie bez kłopotów do innego jak chodzi o opisy modułów. Oczywiście nie zawsze bo bywają różnice. Poza tym czasem drobne pomyłki się mogą zdarzyć ale i tak Atmel to robił zawsze NAJLEPSZE noty PDF, najbardziej czytelne ... porównaj sobie to do Microchipa dawnego to zrozumiesz.

Co się tyczy samych przerwań to czemu nie zajrzysz do noty PDF żeby zobaczyć czym się różnie przerwanie INT2 od przerwań INT0 albo INT1? Przecież tam jak byk widać, że w przypadku INT0 i INT1 masz już na pierwszy rzut oka więcej możliwości co do samego WYZWALANIA przerwań. W tabelce za pomocą dwóch bitów ISCxn ustawia się czy przerwanie ma być wyzwalane:

1. zboczem opadającym
2. zboczem narastającym
3. poziomem niskim
4. poziomem wysokim

a w przypadku INT2 masz do dyspozycji TYLKO i wyłącznie

1. zboczem opadającym
2. zboczem narastającym

Przerwania są rejestrowane asynchronicznie zboczami ale długość impulsów musi się mieścić w odpowiednim przedziale czasowym o czym dalej jest w nocie.

I jest to napisane wyraźnie w każdej nocie które posiada akurat takie przerwanie. W czym problem? Po co czytasz co piszą ludzie, którzy akurat tego nie rozumieją?

Slawek napisał(a):

ale jaki wpływ mają
te przerwania w stosunku do biblioteki V-USB?

Jeśli chodzi o INT2 na ATmega1284 to właśnie sprawdziłem i jednak się myliłem - bo V-USB spokojnie działa nawet na INT2 dlatego że w tym procku to normalne przerwanie synchroniczne jednak a ja myślałem tak na szybko, że podobnie jak w m32 będzie asynchroniczne. I tu się właśnie zawsze kłania sięganie do noty PDF. A zatem krótko mówiąc na m1284P można odpalać na kilka sposobów na pinie PB2 bo i na INT2 i na PCINT10

Code:

#define USB_INTR_CFG            EICRA
#define USB_INTR_CFG_SET        ((1 << ISC20) | (1 << ISC21))
#define USB_INTR_CFG_CLR        0
#define USB_INTR_ENABLE         EIMSK
#define USB_INTR_ENABLE_BIT     INT2
#define USB_INTR_PENDING        EIFR
#define USB_INTR_PENDING_BIT    INTF2
#define USB_INTR_VECTOR         INT2_vect

Statystyki: Napisane przez mirekk36 — 26 sty 2021, o 09:59

Re: V-USB - ATMEGA1284 - intx

2021-01-26T07:13:31+01:00

Wiem że zostanę pogryziony za pytanie, ale może nie.
Pewnie też to było opisane, ale jak szukam to nie potrafię znaleźć

O co dokładniej chodzi z tym przerwaniem synchronicznym i asynchronicznym.
Doszukałem się różnicy o co w nich ogólnie tylko chodzi i nawet ludzie opisują że Atmel wprowadził pewne zamieszanie w nich (myli ich opisy w stosunku do pinów), ale jaki wpływ mają
te przerwania w stosunku do biblioteki V-USB?
Tak ogólnie to dopiero teraz po suplemencie uświadomiłem sobie o takiej różnicy, zastanawiam się też jaki ma to wpływ na inne programy wykorzystujące przerwania zewnętrzne?

Statystyki: Napisane przez Slawek — 26 sty 2021, o 07:13

Re: V-USB - ATMEGA1284 - intx

2021-01-24T18:37:41+01:00

proszę:

iframe

Statystyki: Napisane przez mirekk36 — 24 sty 2021, o 18:37

Re: V-USB - ATMEGA1284 - intx

2021-01-24T14:44:20+01:00

jeszcze dzisiaj pokażę że wszystko działa z książki - KAŻDY przykład - a dodatkowo odpalę na twoich ustawieniach czyli PB1,2 czyli na PCINT10 oczywiście na ATmega1284P

Statystyki: Napisane przez mirekk36 — 24 sty 2021, o 14:44

Re: V-USB - ATMEGA1284 - intx

2021-01-15T18:36:29+01:00

tak sorki sprzętowo jednak się nie różnią

Statystyki: Napisane przez mirekk36 — 15 sty 2021, o 18:36

Re: V-USB - ATMEGA1284 - intx

2021-01-15T18:03:44+01:00

Wrzucę jak będę przy drugim kompie.

Mam m1284.

Na pewno to są różne procki ? wersja P oznacza Picopower czyli niższe zużycie prądu i ma dołożone jedyne co jakieś dodatkowe pierdoły oszczędzające energie.

Statystyki: Napisane przez drakston — 15 sty 2021, o 18:03

Re: V-USB - ATMEGA1284 - intx

2021-01-15T12:24:04+01:00

ty masz procka ATmega1284P czy ATmega1284 ? bo to różne procki

Poza tym podeślij mi ten kod z tego 1-go ćwiczenia który ci nie działa - bo u mnie śmiga że aż miło, więc na razie jedyne co przychodzi mi do głowy to złe połączenia niestety. Oczywiście mówię o procku m32.

Ale sprawdzę niedługo na m1284P i nawet spróbuję się podłączyć na INt2 jak ty próbowałeś

Statystyki: Napisane przez mirekk36 — 15 sty 2021, o 12:24

Re: V-USB - ATMEGA1284 - intx

2021-01-15T12:02:17+01:00

Przy obojętnie jakiej kombinacji podpięcia z odpowiednim konfigiem - komunikat nie znaleziono urzadzenia

Statystyki: Napisane przez drakston — 15 sty 2021, o 12:02

Re: V-USB - ATMEGA1284 - intx

2021-01-15T11:31:43+01:00

drakston napisał(a):

Przykład 1 podstawowy z książki nie działa na żadnym porcie w przypadku Atmega1284.

To niemożliwe - aż sam sprawdzę

Statystyki: Napisane przez mirekk36 — 15 sty 2021, o 11:31

Re: V-USB - ATMEGA1284 - intx

2021-01-15T10:40:24+01:00

Przykład 4 z HID działa na konfigu z przykładu i na moich ustawieniach i pozostałych czyli standardowo wejścia INT

Przykład 1 podstawowy z książki nie działa na żadnym porcie w przypadku Atmega1284.

Generalnie problem z usb w projekcie rozwiązałem w inny sposób także dzięki za pomoc.

Statystyki: Napisane przez drakston — 15 sty 2021, o 10:40

Re: V-USB - ATMEGA1284 - intx

2021-01-09T22:37:35+01:00

drakston napisał(a):

Jutro rozpruje płytkę i przepnę usb na INT0

A nie no to spoko jak ci już działało to najważniejsze - bo właśnie znaczy że np wyeliminowane są błędy np połączeń

Weź zatem na żywca CAŁY plilk usbconfig.h np z klawiatury HID ok i zmień na swoje piny PB 1 i 2 z przerwaniem PCINT10

ale ważne żebyś wziął ten plik z ćwiczenia z książki a nie na czysto i go przerabiał ok?

i daj znać

Statystyki: Napisane przez mirekk36 — 9 sty 2021, o 22:37

Re: V-USB - ATMEGA1284 - intx

2021-01-09T21:26:07+01:00

Po 1 ile tego schematu ma być? widać na nim złącze, jego numery pinów i cały tor usb do procesora, przecież więcej nie trzeba... ten sam tor był sprawdzany na atmega328p i komunikacja wg pierwszego przykładu z książki działała bez problemów.

po 2, Pisałem że chce przerobić pierwszy przykład, że lecę wszystko wg. niego - pierwszy przykład to nie jest hid, tak? Sam Pan pisał w książce o przekopiowaniu czystego konfigu i konfiguracji wg tego pierwszego przykładu co sprowadzało się tylko do ustawienia portów, czestotliwości i nazwy ... zakładając że podłączamy się pod INT0 w wybranym procku.

Jak dobrze pamiętam to w książce widniała informacja że każdy port typu INTx może być użyty do v-usb dlatego na tej bazie u mnie w projekcie wybrałem INT2 bo szczerze mówiąc nic innego wolnego nie mam.

Przeleciałem przykład pierwszy z książki ale nie działało, sugestia od Pana z ustawieniem konfigu przerwań, z poprawka o poprawną konfiguracje z noty procka który też nic nie daje. Pan mówi o przykładzie który jest na stronie 203 książki tak? czyli w teorii mam dobrze to wpisane.

Jutro rozpruje płytkę i przepnę usb na INT0 a potem INT1, jak będzie działać to krótko mówiąc INT2 w atmega1284 nie nadaje się pod usb/albo trzeba czegoś więcej.

Statystyki: Napisane przez drakston — 9 sty 2021, o 21:26

Re: V-USB - ATMEGA1284 - intx

2021-01-09T19:55:24+01:00

wiesz, troszkę łapię się za głowę jak widzę ten konfig ... oczywiście jeśli masz Orangebook'a - bo z tego co piszesz wygląda że masz OB.....

No to po jasny gwint sam sobie robisz podwójne salto-mortale z pętlą na szyi ?

Ja np spróbowałbym najpierw DOKŁADNIE tak jak jest w książce jakiś przykład - a masz przykład na m644P (to jest IDENTIKO to samo co m1284P) i z V-USB na tych pinach co w książce żeby mi ruszyło ....

Jakby mi ruszyło to zmieniłbym tylko piny i przerwanie

.... a nawet jakbym się uparł i nie chciał przetestować tego co w książce - to Qurczę tyle pracy włożyłem i w wyjaśnienie całego konfiga linia po linii ... (ale ok nawet mogę zrozumieć, że i tu można się pomylić gdy się człowiek bierze pierwszy raz za to) ...

A ty nie ... Widzę, że wziąłeś sobie czysty fabryczny usbconfig.h i zajeżdżasz go po swojemu - wiedząc że możesz popełnić w nim błędy jeszcze w wielu miejscach. Po co tak ? Zobacz ile się już "kopiesz z koniem"

Dlaczego nie użyjesz przykładu z książki (kody do książki) czyli jakiegoś folderu z biblioteką i tym plikiem cfg ? zmieniając tylko te piny i przerwania ?

Na pierwszy rzut oka widzę, że mogą być w tym co pokazałeś babole ale to jest chore tak analizować to w ciemno - jaki to ma sens ? Tak możemy pisać przez 100 tys postów.

Poza tym ja założyłem że ty chcesz to odpalić w trybie HID ... ale teraz się zastanawiam czy na pewno w HID ? czy nie ? też chyba jasno to nie wyniknęło z postów

i na koniec - pokazałeś mikrofragmencik swojego schematu - ale nawet na schemacie nie widać która to u ciebie linia D+ a która D- .... czy ty już na tym etapie nie poległeś?

-------------------------

Mówię ci - zacznij od przykładu/kodu z książki tzn z któregoś dowolnego ćwiczenia bo tam masz PRZEŚLICZNIE przygotowane usbconfig.h i na dodatek z ładnymi sekcjami do przełączania dla pinów i różnych przerwań dla kilku różnych procków - tak warto sobie samemu w kodach robić, żeby później uniwersalnie móc to przenosić na różne procki - a ty robisz to po linuxowemu. Zajrzyj pan do tych ćwiczeń kilku do tych plików usbconfig.h i przeanalizuj jak to przygotowałem - zobaczysz że doznasz olśnienia

Statystyki: Napisane przez mirekk36 — 9 sty 2021, o 19:55

Re: V-USB - ATMEGA1284 - intx

2021-01-09T19:32:40+01:00

Kod main jest wpis wyżej, sama próba połączenia.

cały usbconfig
[syntax=c]/* Name: usbconfig.h
* Project: V-USB, virtual USB port for Atmel's(r) AVR(r) microcontrollers
* Author: Christian Starkjohann
* Creation Date: 2005-04-01
* Tabsize: 4
* Copyright: (c) 2005 by OBJECTIVE DEVELOPMENT Software GmbH
* License: GNU GPL v2 (see License.txt), GNU GPL v3 or proprietary (CommercialLicense.txt)
*/

#ifndef __usbconfig_h_included__
#define __usbconfig_h_included__

/*
General Description:
This file is an example configuration (with inline documentation) for the USB
driver. It configures V-USB for USB D+ connected to Port D bit 2 (which is
also hardware interrupt 0 on many devices) and USB D- to Port D bit 4. You may
wire the lines to any other port, as long as D+ is also wired to INT0 (or any
other hardware interrupt, as long as it is the highest level interrupt, see
section at the end of this file).
+ To create your own usbconfig.h file, copy this file to your project's
+ firmware source directory) and rename it to "usbconfig.h".
+ Then edit it accordingly.
*/

/* ---------------------------- Hardware Config ---------------------------- */

#define USB_CFG_IOPORTNAME B
/* This is the port where the USB bus is connected. When you configure it to
* "B", the registers PORTB, PINB and DDRB will be used.
*/
#define USB_CFG_DMINUS_BIT 1
/* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected.
* This may be any bit in the port.
*/
#define USB_CFG_DPLUS_BIT 2
/* This is the bit number in USB_CFG_IOPORT where the USB D+ line is connected.
* This may be any bit in the port. Please note that D+ must also be connected
* to interrupt pin INT0! [You can also use other interrupts, see section
* "Optional MCU Description" below, or you can connect D- to the interrupt, as
* it is required if you use the USB_COUNT_SOF feature. If you use D- for the
* interrupt, the USB interrupt will also be triggered at Start-Of-Frame
* markers every millisecond.]
*/
#define USB_CFG_CLOCK_KHZ 16000
/* Clock rate of the AVR in kHz. Legal values are 12000, 12800, 15000, 16000,
* 16500, 18000 and 20000. The 12.8 MHz and 16.5 MHz versions of the code
* require no crystal, they tolerate +/- 1% deviation from the nominal
* frequency. All other rates require a precision of 2000 ppm and thus a
* crystal!
* Since F_CPU should be defined to your actual clock rate anyway, you should
* not need to modify this setting.
*/
#define USB_CFG_CHECK_CRC 0
/* Define this to 1 if you want that the driver checks integrity of incoming
* data packets (CRC checks). CRC checks cost quite a bit of code size and are
* currently only available for 18 MHz crystal clock. You must choose
* USB_CFG_CLOCK_KHZ = 18000 if you enable this option.
*/

/* ----------------------- Optional Hardware Config ------------------------ */

/* #define USB_CFG_PULLUP_IOPORTNAME D */
/* If you connect the 1.5k pullup resistor from D- to a port pin instead of
* V+, you can connect and disconnect the device from firmware by calling
* the macros usbDeviceConnect() and usbDeviceDisconnect() (see usbdrv.h).
* This constant defines the port on which the pullup resistor is connected.
*/
/* #define USB_CFG_PULLUP_BIT 4 */
/* This constant defines the bit number in USB_CFG_PULLUP_IOPORT (defined
* above) where the 1.5k pullup resistor is connected. See description
* above for details.
*/

/* --------------------------- Functional Range ---------------------------- */

#define USB_CFG_HAVE_INTRIN_ENDPOINT 0
/* Define this to 1 if you want to compile a version with two endpoints: The
* default control endpoint 0 and an interrupt-in endpoint (any other endpoint
* number).
*/
#define USB_CFG_HAVE_INTRIN_ENDPOINT3 0
/* Define this to 1 if you want to compile a version with three endpoints: The
* default control endpoint 0, an interrupt-in endpoint 3 (or the number
* configured below) and a catch-all default interrupt-in endpoint as above.
* You must also define USB_CFG_HAVE_INTRIN_ENDPOINT to 1 for this feature.
*/
#define USB_CFG_EP3_NUMBER 3
/* If the so-called endpoint 3 is used, it can now be configured to any other
* endpoint number (except 0) with this macro. Default if undefined is 3.
*/
/* #define USB_INITIAL_DATATOKEN USBPID_DATA1 */
/* The above macro defines the startup condition for data toggling on the
* interrupt/bulk endpoints 1 and 3. Defaults to USBPID_DATA1.
* Since the token is toggled BEFORE sending any data, the first packet is
* sent with the oposite value of this configuration!
*/
#define USB_CFG_IMPLEMENT_HALT 0
/* Define this to 1 if you also want to implement the ENDPOINT_HALT feature
* for endpoint 1 (interrupt endpoint). Although you may not need this feature,
* it is required by the standard. We have made it a config option because it
* bloats the code considerably.
*/
#define USB_CFG_SUPPRESS_INTR_CODE 0
/* Define this to 1 if you want to declare interrupt-in endpoints, but don't
* want to send any data over them. If this macro is defined to 1, functions
* usbSetInterrupt() and usbSetInterrupt3() are omitted. This is useful if
* you need the interrupt-in endpoints in order to comply to an interface
* (e.g. HID), but never want to send any data. This option saves a couple
* of bytes in flash memory and the transmit buffers in RAM.
*/
#define USB_CFG_INTR_POLL_INTERVAL 10
/* If you compile a version with endpoint 1 (interrupt-in), this is the poll
* interval. The value is in milliseconds and must not be less than 10 ms for
* low speed devices.
*/
#define USB_CFG_IS_SELF_POWERED 0
/* Define this to 1 if the device has its own power supply. Set it to 0 if the
* device is powered from the USB bus.
*/
#define USB_CFG_MAX_BUS_POWER 100
/* Set this variable to the maximum USB bus power consumption of your device.
* The value is in milliamperes. [It will be divided by two since USB
* communicates power requirements in units of 2 mA.]
*/
#define USB_CFG_IMPLEMENT_FN_WRITE 0
/* Set this to 1 if you want usbFunctionWrite() to be called for control-out
* transfers. Set it to 0 if you don't need it and want to save a couple of
* bytes.
*/
#define USB_CFG_IMPLEMENT_FN_READ 0
/* Set this to 1 if you need to send control replies which are generated
* "on the fly" when usbFunctionRead() is called. If you only want to send
* data from a static buffer, set it to 0 and return the data from
* usbFunctionSetup(). This saves a couple of bytes.
*/
#define USB_CFG_IMPLEMENT_FN_WRITEOUT 0
/* Define this to 1 if you want to use interrupt-out (or bulk out) endpoints.
* You must implement the function usbFunctionWriteOut() which receives all
* interrupt/bulk data sent to any endpoint other than 0. The endpoint number
* can be found in 'usbRxToken'.
*/
#define USB_CFG_HAVE_FLOWCONTROL 0
/* Define this to 1 if you want flowcontrol over USB data. See the definition
* of the macros usbDisableAllRequests() and usbEnableAllRequests() in
* usbdrv.h.
*/
#define USB_CFG_DRIVER_FLASH_PAGE 0
/* If the device has more than 64 kBytes of flash, define this to the 64 k page
* where the driver's constants (descriptors) are located. Or in other words:
* Define this to 1 for boot loaders on the ATMega128.
*/
#define USB_CFG_LONG_TRANSFERS 0
/* Define this to 1 if you want to send/receive blocks of more than 254 bytes
* in a single control-in or control-out transfer. Note that the capability
* for long transfers increases the driver size.
*/
/* #define USB_RX_USER_HOOK(data, len) if(usbRxToken == (uchar)USBPID_SETUP) blinkLED(); */
/* This macro is a hook if you want to do unconventional things. If it is
* defined, it's inserted at the beginning of received message processing.
* If you eat the received message and don't want default processing to
* proceed, do a return after doing your things. One possible application
* (besides debugging) is to flash a status LED on each packet.
*/
/* #define USB_RESET_HOOK(resetStarts) if(!resetStarts){hadUsbReset();} */
/* This macro is a hook if you need to know when an USB RESET occurs. It has
* one parameter which distinguishes between the start of RESET state and its
* end.
*/
/* #define USB_SET_ADDRESS_HOOK() hadAddressAssigned(); */
/* This macro (if defined) is executed when a USB SET_ADDRESS request was
* received.
*/
#define USB_COUNT_SOF 0
/* define this macro to 1 if you need the global variable "usbSofCount" which
* counts SOF packets. This feature requires that the hardware interrupt is
* connected to D- instead of D+.
*/
/* #ifdef __ASSEMBLER__
* macro myAssemblerMacro
* in YL, TCNT0
* sts timer0Snapshot, YL
* endm
* #endif
* #define USB_SOF_HOOK myAssemblerMacro
* This macro (if defined) is executed in the assembler module when a
* Start Of Frame condition is detected. It is recommended to define it to
* the name of an assembler macro which is defined here as well so that more
* than one assembler instruction can be used. The macro may use the register
* YL and modify SREG. If it lasts longer than a couple of cycles, USB messages
* immediately after an SOF pulse may be lost and must be retried by the host.
* What can you do with this hook? Since the SOF signal occurs exactly every
* 1 ms (unless the host is in sleep mode), you can use it to tune OSCCAL in
* designs running on the internal RC oscillator.
* Please note that Start Of Frame detection works only if D- is wired to the
* interrupt, not D+. THIS IS DIFFERENT THAN MOST EXAMPLES!
*/
#define USB_CFG_CHECK_DATA_TOGGLING 0
/* define this macro to 1 if you want to filter out duplicate data packets
* sent by the host. Duplicates occur only as a consequence of communication
* errors, when the host does not receive an ACK. Please note that you need to
* implement the filtering yourself in usbFunctionWriteOut() and
* usbFunctionWrite(). Use the global usbCurrentDataToken and a static variable
* for each control- and out-endpoint to check for duplicate packets.
*/
#define USB_CFG_HAVE_MEASURE_FRAME_LENGTH 0
/* define this macro to 1 if you want the function usbMeasureFrameLength()
* compiled in. This function can be used to calibrate the AVR's RC oscillator.
*/
#define USB_USE_FAST_CRC 0
/* The assembler module has two implementations for the CRC algorithm. One is
* faster, the other is smaller. This CRC routine is only used for transmitted
* messages where timing is not critical. The faster routine needs 31 cycles
* per byte while the smaller one needs 61 to 69 cycles. The faster routine
* may be worth the 32 bytes bigger code size if you transmit lots of data and
* run the AVR close to its limit.
*/

/* -------------------------- Device Description --------------------------- */

#define USB_CFG_VENDOR_ID 0xc0, 0x16 /* = 0x16c0 = 5824 = voti.nl */
/* USB vendor ID for the device, low byte first. If you have registered your
* own Vendor ID, define it here. Otherwise you may use one of obdev's free
* shared VID/PID pairs. Be sure to read USB-IDs-for-free.txt for rules!
* *** IMPORTANT NOTE ***
* This template uses obdev's shared VID/PID pair for Vendor Class devices
* with libusb: 0x16c0/0x5dc. Use this VID/PID pair ONLY if you understand
* the implications!
*/
#define USB_CFG_DEVICE_ID 0xdc, 0x05 /* = 0x05dc = 1500 */
/* This is the ID of the product, low byte first. It is interpreted in the
* scope of the vendor ID. If you have registered your own VID with usb.org
* or if you have licensed a PID from somebody else, define it here. Otherwise
* you may use one of obdev's free shared VID/PID pairs. See the file
* USB-IDs-for-free.txt for details!
* *** IMPORTANT NOTE ***
* This template uses obdev's shared VID/PID pair for Vendor Class devices
* with libusb: 0x16c0/0x5dc. Use this VID/PID pair ONLY if you understand
* the implications!
*/
#define USB_CFG_DEVICE_VERSION 0x00, 0x01
/* Version number of the device: Minor number first, then major number.
*/
#define USB_CFG_VENDOR_NAME 'o', 'b', 'd', 'e', 'v', '.', 'a', 't'
#define USB_CFG_VENDOR_NAME_LEN 8
/* These two values define the vendor name returned by the USB device. The name
* must be given as a list of characters under single quotes. The characters
* are interpreted as Unicode (UTF-16) entities.
* If you don't want a vendor name string, undefine these macros.
* ALWAYS define a vendor name containing your Internet domain name if you use
* obdev's free shared VID/PID pair. See the file USB-IDs-for-free.txt for
* details.
*/
#define USB_CFG_DEVICE_NAME 'T', 'e', 'm', 'p', 'l', 'a', 't', 'e'
#define USB_CFG_DEVICE_NAME_LEN 8
/* Same as above for the device name. If you don't want a device name, undefine
* the macros. See the file USB-IDs-for-free.txt before you assign a name if
* you use a shared VID/PID.
*/
/*#define USB_CFG_SERIAL_NUMBER 'N', 'o', 'n', 'e' */
/*#define USB_CFG_SERIAL_NUMBER_LEN 0 */
/* Same as above for the serial number. If you don't want a serial number,
* undefine the macros.
* It may be useful to provide the serial number through other means than at
* compile time. See the section about descriptor properties below for how
* to fine tune control over USB descriptors such as the string descriptor
* for the serial number.
*/
#define USB_CFG_DEVICE_CLASS 0xff /* set to 0 if deferred to interface */
#define USB_CFG_DEVICE_SUBCLASS 0
/* See USB specification if you want to conform to an existing device class.
* Class 0xff is "vendor specific".
*/
#define USB_CFG_INTERFACE_CLASS 0 /* define class here if not at device level */
#define USB_CFG_INTERFACE_SUBCLASS 0
#define USB_CFG_INTERFACE_PROTOCOL 0
/* See USB specification if you want to conform to an existing device class or
* protocol. The following classes must be set at interface level:
* HID class is 3, no subclass and protocol required (but may be useful!)
* CDC class is 2, use subclass 2 and protocol 1 for ACM
*/
/* #define USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH 42 */
/* Define this to the length of the HID report descriptor, if you implement
* an HID device. Otherwise don't define it or define it to 0.
* If you use this define, you must add a PROGMEM character array named
* "usbHidReportDescriptor" to your code which contains the report descriptor.
* Don't forget to keep the array and this define in sync!
*/

/* #define USB_PUBLIC static */
/* Use the define above if you #include usbdrv.c instead of linking against it.
* This technique saves a couple of bytes in flash memory.
*/

/* ------------------- Fine Control over USB Descriptors ------------------- */
/* If you don't want to use the driver's default USB descriptors, you can
* provide our own. These can be provided as (1) fixed length static data in
* flash memory, (2) fixed length static data in RAM or (3) dynamically at
* runtime in the function usbFunctionDescriptor(). See usbdrv.h for more
* information about this function.
* Descriptor handling is configured through the descriptor's properties. If
* no properties are defined or if they are 0, the default descriptor is used.
* Possible properties are:
* + USB_PROP_IS_DYNAMIC: The data for the descriptor should be fetched
* at runtime via usbFunctionDescriptor(). If the usbMsgPtr mechanism is
* used, the data is in FLASH by default. Add property USB_PROP_IS_RAM if
* you want RAM pointers.
* + USB_PROP_IS_RAM: The data returned by usbFunctionDescriptor() or found
* in static memory is in RAM, not in flash memory.
* + USB_PROP_LENGTH(len): If the data is in static memory (RAM or flash),
* the driver must know the descriptor's length. The descriptor itself is
* found at the address of a well known identifier (see below).
* List of static descriptor names (must be declared PROGMEM if in flash):
* char usbDescriptorDevice[];
* char usbDescriptorConfiguration[];
* char usbDescriptorHidReport[];
* char usbDescriptorString0[];
* int usbDescriptorStringVendor[];
* int usbDescriptorStringDevice[];
* int usbDescriptorStringSerialNumber[];
* Other descriptors can't be provided statically, they must be provided
* dynamically at runtime.
*
* Descriptor properties are or-ed or added together, e.g.:
* #define USB_CFG_DESCR_PROPS_DEVICE (USB_PROP_IS_RAM | USB_PROP_LENGTH(18))
*
* The following descriptors are defined:
* USB_CFG_DESCR_PROPS_DEVICE
* USB_CFG_DESCR_PROPS_CONFIGURATION
* USB_CFG_DESCR_PROPS_STRINGS
* USB_CFG_DESCR_PROPS_STRING_0
* USB_CFG_DESCR_PROPS_STRING_VENDOR
* USB_CFG_DESCR_PROPS_STRING_PRODUCT
* USB_CFG_DESCR_PROPS_STRING_SERIAL_NUMBER
* USB_CFG_DESCR_PROPS_HID
* USB_CFG_DESCR_PROPS_HID_REPORT
* USB_CFG_DESCR_PROPS_UNKNOWN (for all descriptors not handled by the driver)
*
* Note about string descriptors: String descriptors are not just strings, they
* are Unicode strings prefixed with a 2 byte header. Example:
* int serialNumberDescriptor[] = {
* USB_STRING_DESCRIPTOR_HEADER(6),
* 'S', 'e', 'r', 'i', 'a', 'l'
* };
*/

#define USB_CFG_DESCR_PROPS_DEVICE 0
#define USB_CFG_DESCR_PROPS_CONFIGURATION 0
#define USB_CFG_DESCR_PROPS_STRINGS 0
#define USB_CFG_DESCR_PROPS_STRING_0 0
#define USB_CFG_DESCR_PROPS_STRING_VENDOR 0
#define USB_CFG_DESCR_PROPS_STRING_PRODUCT 0
#define USB_CFG_DESCR_PROPS_STRING_SERIAL_NUMBER 0
#define USB_CFG_DESCR_PROPS_HID 0
#define USB_CFG_DESCR_PROPS_HID_REPORT 0
#define USB_CFG_DESCR_PROPS_UNKNOWN 0

#define usbMsgPtr_t unsigned short
/* If usbMsgPtr_t is not defined, it defaults to 'uchar *'. We define it to
* a scalar type here because gcc generates slightly shorter code for scalar
* arithmetics than for pointer arithmetics. Remove this define for backward
* type compatibility or define it to an 8 bit type if you use data in RAM only
* and all RAM is below 256 bytes (tiny memory model in IAR CC).
*/

/* ----------------------- Optional MCU Description ------------------------ */

/* The following configurations have working defaults in usbdrv.h. You
* usually don't need to set them explicitly. Only if you want to run
* the driver on a device which is not yet supported or with a compiler
* which is not fully supported (such as IAR C) or if you use a differnt
* interrupt than INT0, you may have to define some of these.
*/
#define USB_INTR_CFG PCMSK1
#define USB_INTR_CFG_SET (1<#define USB_INTR_CFG_CLR 0
#define USB_INTR_ENABLE PCICR
#define USB_INTR_ENABLE_BIT PCIE1
#define USB_INTR_PENDING PCIFR
#define USB_INTR_PENDING_BIT PCIF1
#define USB_INTR_VECTOR PCINT1_vect

#endif /* __usbconfig_h_included__ */[/syntax]

Statystyki: Napisane przez drakston — 9 sty 2021, o 19:32

Re: V-USB - ATMEGA1284 - intx

2021-01-09T19:06:35+01:00

Pokaż obydwie części konfiga twojego teraz - czyli jak masz PINY i te przerwania

Poza tym czy wgrywasz jakąś najprostszą konfigurację do testu czy kombinujesz od razu z czymś ciężkim i nie wiadomo gdzie masz błąd

Statystyki: Napisane przez mirekk36 — 9 sty 2021, o 19:06

Re: V-USB - ATMEGA1284 - intx

2021-01-09T18:30:01+01:00

wg. noty powinno być tak

[syntax=c]#define USB_INTR_CFG PCMSK1
#define USB_INTR_CFG_SET (1<#define USB_INTR_CFG_CLR 0
#define USB_INTR_ENABLE PCICR
#define USB_INTR_ENABLE_BIT PCIE1
#define USB_INTR_PENDING PCIFR
#define USB_INTR_PENDING_BIT PCIF1
#define USB_INTR_VECTOR PCINT1_vect[/syntax]

efekt taki że co pare sekund odświeża listę urządzeń w menedżerze i wyświetla okienko nie rozpoznano urządzenia.

Statystyki: Napisane przez drakston — 9 sty 2021, o 18:30

Re: V-USB - ATMEGA1284 - intx

2021-01-09T13:40:12+01:00

drakston napisał(a):

O czym zapomniałem?

nie wiem ale jak ja pokazywałem w przykładzie PCINT27 to był np PCMSK3 .... natomiast PCINT10 jest daleko od niego - na pewno o 8 bitów - więc wątpię (nie zaglądając teraz do noty PDF - ty sobie zajrzyj) bo pisałem ci żebyś zwrócił uwagę na wszyskie PCMSKx i tak dalej - a ty sobie niefrasobliwie przepisałeś wszędzie z trójką.

Zajrzyj do mojego postu wyżej

Statystyki: Napisane przez mirekk36 — 9 sty 2021, o 13:40

Re: V-USB - ATMEGA1284 - intx

2021-01-09T12:57:00+01:00

no to tak od początku
kawałek schematu z usb

Chciałem przerobić przerwszy przykład komunikacji z książki, czyli po prostu żeby PC wykrył mi urządzenie. Biblioteka wykorzystana czysta, domyśla konfiguracja, lecę wg przykładu.

Przy pierwszych próbach miałem podłączoną ścieżkę D+ do dwóch pinów, wywalało cały czas nie znalezione urządzenie. Dzisiaj jak się wyspałem w końcu kapnąłem że przecież nie obsługuje tego pinu nigdzie w kodzie więc stoi tam stan niski albo hi-z i pewnie wali mi transmisje do masy...

Ścieżka ucięta, kod jak niżej
[syntax=c]#define USB_CFG_IOPORTNAME B
/* This is the port where the USB bus is connected. When you configure it to
* "B", the registers PORTB, PINB and DDRB will be used.
*/
#define USB_CFG_DMINUS_BIT 1
/* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected.
* This may be any bit in the port.
*/
#define USB_CFG_DPLUS_BIT 2
/* This is the bit number in USB_CFG_IOPORT where the USB D+ line is connected.
* This may be any bit in the port. Please note that D+ must also be connected
* to interrupt pin INT0! [You can also use other interrupts, see section
* "Optional MCU Description" below, or you can connect D- to the interrupt, as
* it is required if you use the USB_COUNT_SOF feature. If you use D- for the
* interrupt, the USB interrupt will also be triggered at Start-Of-Frame
* markers every millisecond.]
*/
#define USB_CFG_CLOCK_KHZ 16000[/syntax]
[syntax=c]#define USB_INTR_CFG PCMSK3
#define USB_INTR_CFG_SET (1<#define USB_INTR_CFG_CLR 0
#define USB_INTR_ENABLE PCICR
#define USB_INTR_ENABLE_BIT PCIE3
#define USB_INTR_PENDING PCIFR
#define USB_INTR_PENDING_BIT PCIF3
#define USB_INTR_VECTOR PCINT3_vect[/syntax]
[syntax=c]#include
#include
#include
#include
#include
#include
//#include "light_ws2812.h"
//#include "LCD4x40.h"
#include "usbdrv.h"

void usb_reset( void );

//struct cRGB led[8];

usbMsgLen_t usbFunctionSetup(uchar data[8]){

return 0;
}

int main()
{
//LCD_wlaczE2();
//LCD_Initalize();
//LCD_Clear_0();
//LCD_Clear_1();
//LCD_EkranPowitalny();
wdt_enable(WDTO_1S);// aktywacja watchdoga na 1 s
usbInit();// inicjalizacja V-USB
usb_reset();// reset urządzenia na magistrali USB

sei();

/*

led[0].r=50;led[0].g=00;led[0].b=00;
led[1].r=00;led[1].g=40;led[1].b=00;
led[2].r=00;led[2].g=40;led[2].b=00;
led[3].r=00;led[3].g=40;led[3].b=00;
led[4].r=00;led[4].g=40;led[4].b=00;
led[5].r=00;led[5].g=40;led[5].b=00;
led[6].r=00;led[6].g=40;led[6].b=00;
led[7].r=00;led[7].g=40;led[7].b=00;
ws2812_setleds(led,8);
_delay_ms(10);
*/
while (1);
{
usbPoll();// zdarzenie do obsługi USB
wdt_reset();// resetuj watchdog
}

}

void usb_reset( void ) {
usbDeviceDisconnect();
uint8_t i = 0;
while(--i){ // odłączenie się do magistrali USB
wdt_reset(); // na czas większy niż ok 250 ms
_delay_ms(1); //
}
usbDeviceConnect();
}

#ifdef WDIF
void __init3( void ) __attribute__ (( section( ".init3" ), naked, used ));
void __init3( void )
{
/* wyłączenie watchdoga (w tych mikrokontrolerach, w których watchdog
* ma możliwość generowania przerwania pozostaje on też aktywny po
* resecie) */
MCUSR = 0;
_WD_CONTROL_REG = 1 << _WD_CHANGE_BIT | 1 << WDE;
_WD_CONTROL_REG = 0;
}
#endif[/syntax]

i zima... nie ma nawet że nie rozpoznano urządzenia... Sprawdziłem na oscyloskopie to D- widać że jest trochę ponad 200ms stan niski, potem ramki informacji i i tak w kółko. na D+ lecą 3 krótkie ramki razem co jakiś czas.

O czym zapomniałem?

aha sprawdziłem też bez dodatkowej konfiguracji przerwania i też brak reakcji.

dodam jeszcze że na pozostałych PORTB mam piny z danymi do LCD ale jest odpięte wszystko i kod do lcd zakomentowany więc nie powinno to robić problemu.

Zegar leci na 16mhz, gdzie trzeba zdefiniowany. Brak błędów przy kompilacji, działam w AVRstudio. Robiłem ten przykład na atmega328p z wykorzystaniem portu INT0 i śmigało.

Statystyki: Napisane przez drakston — 9 sty 2021, o 12:57

Re: V-USB - ATMEGA1284 - intx

2021-01-09T04:05:46+01:00

drakston napisał(a):

Jak rozumiem muszę się wokół tego w pliku zakręcić?

W kodach przykładowych do książki masz ładnie wszystkie najpotrzebniejsze sekcje w tym tą którą tu pokazałeś - wystarczy że inną tzn dla innego procka zakomentujesz a odkomentujesz właśnie tą - i już będzie ci śmigać. Tu w tym wypadku będzie używany PCINT27 zamiast INTx

Jeśli się upierasz na INT2 to hmmm musisz sprawdzić ale z tego co pamiętam to to przerwanie się nie nadaje bo jest asynchroniczne w porównaniu do INT0 albo INT1 ... ale ponieważ to procek m1284p to spokojnie możesz użyć przerwania PCINTx tylko sprawdź jaki to numerek PCINT w nocie PDF i ew podmień pozostałe nazwy jak

PCMSKx
PCIEx
PCIFx
PCINTx_vect

Statystyki: Napisane przez mirekk36 — 9 sty 2021, o 04:05

Re: V-USB - ATMEGA1284 - intx

2021-01-08T22:18:41+01:00

usb mam podpięte pod poniższe piny

Quote:

#define USB_CFG_IOPORTNAME B
/* This is the port where the USB bus is connected. When you configure it to
* "B", the registers PORTB, PINB and DDRB will be used.
*/
#define USB_CFG_DMINUS_BIT 1
/* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected.
* This may be any bit in the port.
*/
#define USB_CFG_DPLUS_BIT 2

Wrócilem do ksiązki i doczytałem tą sekcje

Quote:

jeśli zechcemy
użyć mikrokontrolerów ATmega644P lub ATmega1284P (odpowiednik, jeśli
chodzi o wyprowadzenia, tak jak ATmega32), to proponujemy w ramach
ćwiczeń wykorzystać przerwanie PCINTx dostępne również na pinie INT1,
czyli PCINT27. W takim przypadku konfiguracja będzie wyglądała tak:
/* -------------------------- Hardware Config ------------------------ */
#define USB_CFG_IOPORTNAME D
#define USB_CFG_DMINUS_BIT 5 // pin PD5
#define USB_CFG_DPLUS_BIT 3 // pin PCINT27 (PD3) dla ATmega644/1284
/* -------------------- Optional MCU Description --------------------- */
#define USB_INTR_CFG PCMSK3
#define USB_INTR_CFG_SET (1 << PCINT27)
#define USB_INTR_CFG_CLR 0
#define USB_INTR_ENABLE PCICR
#define USB_INTR_ENABLE_BIT PCIE3
#define USB_INTR_PENDING PCIFR
#define USB_INTR_PENDING_BIT PCIF3
#define USB_INTR_VECTOR PCINT3_vect

Jak rozumiem muszę się wokół tego w pliku zakręcić?

Można gdzieś znaleźć opis/rozwinięcie powyższych definicji ?

Statystyki: Napisane przez drakston — 8 sty 2021, o 22:18

Re: V-USB - ATMEGA1284 - intx

2021-01-08T22:07:47+01:00

pamiętaj że to nie tylko sekcja INTx ale i piny - na początku pliku

Statystyki: Napisane przez mirekk36 — 8 sty 2021, o 22:07