abcminiuser / lufa Goto Github PK
View Code? Open in Web Editor NEWLUFA - the Lightweight USB Framework for AVRs.
Home Page: http://www.lufa-lib.org
LUFA - the Lightweight USB Framework for AVRs.
Home Page: http://www.lufa-lib.org
I noticed this while moving a program written elsewhere over to Atmel Studio. When I tried to use the ASF version of LUFA, there was a mismatch in the definition of CALLBACK_USB_GetDescriptor
between my descriptors.c and the version of device.h brought into the project by ASF.
The relevant change is commit 92e9cb7. In the version of LUFA downloaded from fourwalledcubicle wIndex
is a uint16
, whereas the version in AS is a uint8
- as it was before the commit.
This seems to appear both when adding the LUFA USB module through ASF wizard, and when opening the CLASS CDC demo project included in the LUFA extension. The easiest way to reproduce it is to open the CDC demo and look at the definition in descriptors.h and devices.h
I have not looked to see if anything else is out of date.
Hi Dean,
I'm writing a firmware that emulates a dualshock 4 controller. The goal of this firmware is only to pair a specific bluetooth address with a PS4 (Sony blocked USB inputs...).
The source code is available at https://github.com/matlo/GIMX-firmwares/tree/master/EMUPS4
The issue I'm running into is that there is a problem during the enumeration that only occurs with the PS4 (it works fine with my PC). The USB device hangs waiting for an OUT packet after sending the response to the second get device descriptor request. The loop is at line 74 of the Template_Endpoint_Control_W.c file.
https://github.com/abcminiuser/lufa/blob/master/LUFA/Drivers/USB/Core/AVR8/Template/Template_Endpoint_Control_W.c#L74
Adding the following code before the closing brace seems to work-around the issue:
else if (Endpoint_IsSETUPReceived())
return ENDPOINT_RWCSTREAM_HostAborted;
Does this seem a valid fix to you?
Regards
Since I've forked out a modified version of the LUFA build system as DMBS, it would be better maintenance-wise if I can integrate DMBS with some extra modifications in LUFA rather than having duplicated code.
I see that USB_Descriptor_Device_t
has a field called NumberOfConfigurations
, and I see the USB_Descriptor_Configuration_t
stuct, but I'm not sure how I specify that a USB_Descriptor_Configuration_t
belongs to a USB_Descriptor_Device_t
.
Does the compiler or the running program somehow automatically associate NumberOfConfigurations
USB_Descriptor_Configuration_t
s with a USB_Descriptor_Device_t
? If so, do they get associated in the order defined?
Maybe I just don't know enough about USB yet, but I was expecting USB_Descriptor_Device_t
to contain USB_Descriptor_Configuration_t
s (or an array of pointers to them).
If i try to compile the CDC bootloader with 2kb setting (for 32u4) I get a compile error.
For the HID I dont get a compile error.
It would be nice to a) get an error and b) maybe improve the error, so one know whats going on.
I was reading from forums that making OUT endpint for HID class devices is a burden. I have XMega project where I am using generic HID device for sending and receiving up to 20 bytes of data telegrams. My controller is composite device including 3 different USB HID logical devices and using 4 endpoints. One of the logical devices needs OUT endpoint. So, I invested some time to implement possibility to have also OUT endpoint available fro HID class device.
The feature can be turned on in Config/LUFAConfig.h with
#elif (ARCH == ARCH_XMEGA)
#define HID_HAVE_OUT_ENDPOINT
It is implemented only for XMEGA in this diff. Without the define it works as before.
The xmega controller USB hardware is haveing register for reading out how many bytes was sent in the OUT transfer, the mega ones seem not to have it. When dealing with telegrams and not with streams, the amount of bytes is not a big problem, as telegram needs to have protocol for reading and handling of the contents.
It seems I can not attach the patch but must include in this description, UPS and it seems to be reverse.
diff -r 8e76cf8ff108 -r 5b1ce1d1573c Drivers/USB/Class/Device/HIDClassDevice.c
--- a/Drivers/USB/Class/Device/HIDClassDevice.c Mon May 12 16:00:37 2014 +0300
+++ b/Drivers/USB/Class/Device/HIDClassDevice.c Thu May 01 20:16:51 2014 +0300
@@ -145,10 +145,6 @@
if (!(Endpoint_ConfigureEndpointTable(&HIDInterfaceInfo->Config.ReportINEndpoint, 1)))
return false;
-#ifdef HID_HAVE_OUT_ENDPOINT
- if (!(Endpoint_ConfigureEndpointTable(&HIDInterfaceInfo->Config.ReportOUTEndpoint, 1)))
- return false;
-#endif
return true;
}
@@ -205,41 +201,6 @@
HIDInterfaceInfo->State.PrevFrameNum = USB_Device_GetFrameNumber();
}
-
-#ifdef HID_HAVE_OUT_ENDPOINT
- bool CALLBACK_HID_Device_ProcessHIDoutReport( USB_ClassInfo_HID_Device_t* const HIDInterfaceInfo,
- const void* ReportData,
- const uint16_t ReportSize );
-
- if( HIDInterfaceInfo->Config.ReportOUTEndpoint.Address != 0 )
- {
- Endpoint_SelectEndpoint(HIDInterfaceInfo->Config.ReportOUTEndpoint.Address);
-
- /* Check to see if a packet has been sent from the host */
- if (Endpoint_IsOUTReceived())
- {
- uint8_t* ReportData = HIDInterfaceInfo->Config.ReportOUTBuffer;
- uint16_t ReportSize = 0;
-
- while ( Endpoint_IsReadWriteAllowed() )
- {
- uint8_t b = Endpoint_Read_8();
- if( ReportSize < HIDInterfaceInfo->Config.ReportOUTBufferSize )
- {
- // avoid over filling of the buffer
- *ReportData = b;
- ReportSize++;
- ReportData++;
- }
- }
-
- /* Process Report Data */
- if( CALLBACK_HID_Device_ProcessHIDoutReport( HIDInterfaceInfo, ReportData, ReportSize ) )
- Endpoint_ClearOUT();
- }
- }
-
-#endif
}
#endif
diff -r 8e76cf8ff108 -r 5b1ce1d1573c Drivers/USB/Class/Device/HIDClassDevice.h
--- a/Drivers/USB/Class/Device/HIDClassDevice.h Mon May 12 16:00:37 2014 +0300
+++ b/Drivers/USB/Class/Device/HIDClassDevice.h Thu May 01 20:16:51 2014 +0300
@@ -86,11 +86,6 @@
uint8_t InterfaceNumber; /**< Interface number of the HID interface within the device. */
USB_Endpoint_Table_t ReportINEndpoint; /**< Data IN HID report endpoint configuration table. */
-#ifdef HID_HAVE_OUT_ENDPOINT
- USB_Endpoint_Table_t ReportOUTEndpoint; /**< Data OUT HID report endpoint configuration table. */
- void* ReportOUTBuffer; /**< Pointer to the reserved memory for out report buffer */
- uint8_t ReportOUTBufferSize; /**< Size of the out report buffer. This amount of bytes will be filled from USB device */
-#endif // HID_HAVE_OUT_ENDPOINT
void* PrevReportINBuffer; /**< Pointer to a buffer where the previously created HID input report can be
* stored by the driver, for comparison purposes to detect report changes that
avrdude does not allow programming of "flash" via flip. I had to modify LUFA/Build/lufa_avrdude.mk to allow me to select the "application" memory. I suggest either adding a variable as I did, or adding a separate target, ie: avrdude-application.
...
# Default values of optionally user-supplied variables
AVRDUDE_PROGRAMMER ?= jtagicemkii
AVRDUDE_PORT ?= usb
AVRDUDE_FLAGS ?=
AVRDUDE_MEMORY ?= flash
...
# Programs in the target FLASH memory using AVRDUDE
avrdude: $(TARGET).hex $(MAKEFILE_LIST)
@echo $(MSG_AVRDUDE_CMD) Programming device \"$(MCU)\" FLASH using \"$(AVRDUDE_PROGRAMMER)\" on port \"$(AVRDUDE_PORT)\"
avrdude $(BASE_AVRDUDE_FLAGS) -U $(AVRDUDE_MEMORY):w:$< $(AVRDUDE_FLAGS)
...
I tried to compile with the newest winavr patch with avr-gcc 4.9.2 from here and this totally breaks the bootloader:
http://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/
It compiles with 200 bytes less kb but wont work at all. Just want to note it here, if anyone else rans into the problem. 4.9.2 is really the most up to date compiler, not even sure if its declared stable.
4.8.1 worked for me. (under linux)
But it could be that my winavr installation is broken.
edit: it really seems that the patch isnt working as it is supposed to do.
https://github.com/abcminiuser/lufa/blob/master/LUFA/Version.h
Is this used somehere? I cannot find a real use case, also the variables are zero and dont contain a version. Setting a version could be useful for further projects that rely on a specific lufa version.
I tried the c program which seems to work now. However I got serious bootloader problems now:
The sketch will not load. It seems to be a magic key problem but I noticed several weird errors. It must be something simple i guess? I even tried a fixed bootkey address which the arduino team uses:
//uint16_t MagicBootKey ATTR_NO_INIT;
volatile uint8_t *const MagicBootKeyPtr = (volatile uint8_t *)0x8000;
#define MagicBootKey *MagicBootKeyPtr
/** Special startup routine to check if the bootloader was started via a watchdog reset, and if the magic application
* start key has been loaded into \ref MagicBootKey. If the bootloader started via the watchdog and the key is valid,
* this will force the user application to start via a software jump.
*/
void Application_Jump_Check(void)
{
LEDs_Init();
LEDs_SetAllLEDs(0);
if(MCUSR & (1 << WDRF))
LEDs_TurnOnLEDs(LEDS_LED1); //rx
if(MagicBootKey == MAGIC_BOOT_KEY)
LEDs_TurnOnLEDs(LEDS_LED2); //tx
/* If the reset source was the bootloader and the key is correct, clear it and jump to the application */
if ((MCUSR & (1 << WDRF)) && (MagicBootKey == MAGIC_BOOT_KEY))
{
MagicBootKey = 0;
// cppcheck-suppress constStatement
((void (*)(void))0x0000)();
}
}
But only the first led goes on.
MCU = atmega32u4
ARCH = AVR8
BOARD = LEONARDO
F_CPU = 16000000
F_USB = $(F_CPU)
OPTIMIZATION = s
TARGET = BootloaderHID
SRC = $(TARGET).c Descriptors.c $(LUFA_SRC_USB)
LUFA_PATH = ../../LUFA
CC_FLAGS = -DUSE_LUFA_CONFIG_HEADER -IConfig/
LD_FLAGS = -Wl,--section-start=.text=$(BOOT_START_OFFSET)
# Flash size and bootloader section sizes of the target, in KB. These must
# match the target's total FLASH size and the bootloader size set in the
# device's fuses.
FLASH_SIZE_KB := 32
BOOT_SECTION_SIZE_KB := 4
[...]
avrdude:
avrdude -patmega32u4 -cstk500v1 -P/dev/ttyACM0 -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0xCB:m -Uhfuse:w:0xD8:m -Ulfuse:w:0xFF:m
avrdude -patmega32u4 -cstk500v1 -P/dev/ttyACM0 -b19200 -Uflash:w:./$(TARGET).hex:i -Ulock:w:0x2F:m
Edit: The leds were off because of my wrong bootkey address "fix". The problem was something different, see PR #77
Bug report from a user. The LowLevel AudioOutput demo fails to set the requested audio parameters:
# aplay -v -D front:CARD=Demo,DEV=0 /usr/share/sounds/alsa/test.wav
Playing WAVE '/usr/share/sounds/alsa/test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
aplay: set_params:1297: Unable to install hw params:
ACCESS: RW_INTERLEAVED
FORMAT: S16_LE
SUBFORMAT: STD
SAMPLE_BITS: 16
FRAME_BITS: 32
CHANNELS: 2
RATE: 44100
PERIOD_TIME: (125011 125012)
PERIOD_SIZE: 5513
PERIOD_BYTES: 22052
PERIODS: (3 4)
BUFFER_TIME: 500000
BUFFER_SIZE: 22050
BUFFER_BYTES: 88200
TICK_TIME: 0
The ClassDriver, on the contrary, says:
# aplay -v -D front:CARD=Demo,DEV=0 /usr/share/sounds/alsa/test.wav
Playing WAVE '/usr/share/sounds/alsa/test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
Hardware PCM card 3 'LUFA Audio Out Demo' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 22050
period_size : 5513
period_time : 125011
tstamp_mode : NONE
period_step : 1
avail_min : 5513
period_event : 0
start_threshold : 22050
stop_threshold : 22050
silence_threshold: 0
silence_size : 0
boundary : 6206523236469964800
appl_ptr : 0
hw_ptr : 0
#!/usr/bin/python
as first line of the python file.http://bialix.com/intelhex/
I used this instead: https://pypi.python.org/pypi/IntelHexhttps://github.com/abcminiuser/lufa/blob/master/Projects/USBtoSerial/Descriptors.c#L46
vs
https://github.com/abcminiuser/lufa/blob/master/Bootloaders/CDC/Descriptors.c
Currently searching what has to be changed in order to fix this. But it seems just the PROGMEM is missing.
Or is there any reason for this???
Edit:
Those variables also sit in RAM:
00800208 D ProductString
0080022a D ManufacturerString
0080023e D LanguageString
Adding PROGMEM saves ~150 bytes of ram.
NicoHood/HoodLoader2@fc2d90a
The weird thing is, that my program stops working after adding the PROGMEM
This is related to that. However I do need those bytes for my bootloader. Why does a bootloader not support PROGMEM and a normal program does?
http://www.avrfreaks.net/forum/lufa-hid-bootloader-name
http://www.avrfreaks.net/forum/using-dynamic-serial-string-lufa-usb-descriptor
This issue has nothing to do with issue #42.
The story:
I am developing a 16u2 CDC Bootloader variation and I got a very weird error. I tried with my arduino leonardo now. There is no such an error (with the official bootloader). Then I recompiled the CDC Bootloader from lufa and the bug appeared.
The bug:
Use a USB3 port on your pc (tried with two pcs) and connect a usb 2.0 hub to it(usb 3 wont cause the bug). plug in the arduino with the cdc bootloader and try to upload a sketch via the ide. The verification will fail. Now do the same and connect a second device to the usb port like a mouse. For some reason the uploading now doesnt fail.
The sketch will upload anyways but the verification wont fail. I tried with 2 different pcs and different os. (win7, win8, ubuntu). I tried 4 different usb 2 hubs (usb 3 works). I did not try usb 2 pc host ports because i only have usb3 ports. I tried different drivers for windows (shouldnt matter cause linux has this bug too).
There are also different errors like a "dead" usb port until you plug in/out another device on the hub. As long as you dont do this, the cdc bootloader usb port will be dead, you can replug it as long as you want.
It seems that the old CDC bootloader from the Arduino team (with older lufa) has not this problem. I am now searching for the error. If it is the lufa version or the code of the bootloader.
Fuses used (tested with 16u2, 32u2 and 32u4):
#fuses (HoodLoader2 only, not suitable for DFU)
HoodLoader2atmega16u2.bootloader.low_fuses=0xFF
HoodLoader2atmega16u2.bootloader.high_fuses=0xD8
HoodLoader2atmega16u2.bootloader.extended_fuses=0xCB (0xFC for 32u4)
HoodLoader2atmega16u2.bootloader.unlock_bits=0x3F
HoodLoader2atmega16u2.bootloader.lock_bits=0x2F
To recreate this you only need an Arduino Uno/Mega (16u2) board or a leonardo/(pro)micro(32u4) board and test one of the versions. To upload sketches to the 16u2 you need my hid project and hoodloader2 project on github. It'd be easier to test the 32u4 though.
edit: @dean: any idea where the bug could be located, where i have to start searching?
Trying to develop my own library for CAN controllers and write/adapt CANopen stack, all using LUFA build system (and unfortunatelly also strongly coupled to it) I found that the first asignment of BASE_CC_FLAGS varible in lufa_build.mk prevents me from seamlessly adding (concatenating) more compiler options, like -I or -D necessary in my own library without changing the LUFA makefiles. I add my own source files and specific variables in a [libname]_sources.mk makefile which looks similarly to lufa_sources.mk.
The easy workaround is to change the operator in the first asignment to the BASE_CC_FLAGS variable from := to +=
The more proper way imho would be to decouple lufa_build.mk from LUFA library, that is to move F_USB and LUFA_PATH variables out of lufa_build.mk into lufa_sources.mk. As a result we would get a general extendable biuld system initially configured to compile with LUFA library.
Regards! And thanks for the great library.
Is it possible to make a MSC-CDC Composite Bootloader for ATmega32u4 that can switch in between MSC and CDC mode on certain event (like rapidly pressing reset button twice)
@watterott have a similar implementation based on ATSAMD21
User request:
New config directive
USE_FLASH_FAR_DESCRIPTORS
to enable FLASH descriptors anywhere, i.e. read memorypgm_*_far
fuctions. It's not needed for main program but for large chip bootloaders when RAMPZ register is needed to access bootloader's FLASH. CurrentlyUSE_RAM_DESCRIPTORS
must be used which allocates sligtly more RAM for consts. It's rather minor problem but I got it when developing bootloader for AT90USB1286.
Report from user, AVR32 host mode fails to enumerate. Re-test of latest code on the EVK1101 required to confirm.
Bug report from a user.
An XMEGA128A1 fails to program EEPROM using Atmel Studio 6.1.2730 unless the chip is erased first. This points to the EEPROM not being erased correctly on some XMEGA parts (targeted memory erase procedure).
Quote from the user:
This procedure works for me (PROGRAM FLASH or PRODUCTION FILE PROGRAM)
At first i must do: Memories->Device=Erase chip,
even always ERASE MEMORY BEFORE PROGRAMMING is checked.
After then i can programming ic (if i use PRODUCTION FILE PROGRAM mode)
(must uncheck EEPROM), if i don`t do that i always receive error:
Verifying EEPROM...Failed! address=0x0000 expected=0x41 actual=0x00...
I get the following error when I try to follow the instructions for using Doxygen to generate the documentation.
Executing "make doxygen" on all LUFA library elements.
/Library/Developer/CommandLineTools/usr/bin/make -C LUFA doxygen
grep: /Version.h: No such file or directory
[DOXYGEN] : Configuration file "doxyfile" with parameters "QUIET=YES PROJECT_NUMBER="
if ( ( cat doxyfile ; echo "QUIET=YES" ; echo "PROJECT_NUMBER=" ) | doxygen - 2>&1 | grep -v "warning: ignoring unsupported tag" ;); then exit 1; fi;
warning: Tag `CLANG_ASSISTED_PARSING' at line 1010 of file `-' belongs to an option that was not enabled at compile time.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u", or recompile doxygen with this feature enabled.
warning: Tag `CLANG_OPTIONS' at line 1018 of file `-' belongs to an option that was not enabled at compile time.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u", or recompile doxygen with this feature enabled.
make[1]: *** [doxygen] Error 1
make: *** [doxygen] Error 2
OSX 10.11, built against 10.11 SDK, it states "unable to open device" Not really sure how to proceed.
Hi,
Was wondering if anyone know if the bytes for UNIQUE SERIAL NUMBER for some devices (eg ATMEGA16U2) mentioned in the datasheet,
Unique Serial Number From 0x000E to 0x0018
are displayed in ,
High Nibble First
0x1A, display as 1A
or
Low Nibble First
0x1A, display as A1
From LUFA's Device_AVR8.h,
uint8_t SerialByte = boot_signature_byte_get(SigReadAddress);
if (SerialCharNum & 0x01)
{
SerialByte >>= 4;
SigReadAddress++;
}
SerialByte &= 0x0F;
Seems like the LOW nibble were displayed first.
When checking the UNIQUE SERIAL NUMBER using AVR STUDIO, the bytes were displayed HIGH nibble first.
Serial Number Read from AVR Studio
Serial Number returned by Arduino Serial Port that is using LUFA's code
From AVR Studio
Serial Number = 5732373336361511181F
From LUFA
Serial Number = 752373336363511181F1
I can't seems to find documents from ATMEL about this. If anyone know how this works, please share some light.
Cheers
JP
I get significantly different versions of LUFA-111009 depending on where I download it from.
If I download LUFA-111009.zip from googlecode.com, it has a sha1sum of fe6abf1cef6fb924d58f9158c5297e305b169a8f
and it defines ENDPOINT_DIR_IN
to be 0x80 in USBController.h:
/** Endpoint address direction mask for an IN direction (Device to Host) endpoint. This may be ORed with
* the index of the address within a device to obtain the full endpoint address.
*/
#define ENDPOINT_DIR_IN 0x80
//@}
If I go to LUFA on fourwalledcubicle.com, the link for LUFA-111009 points to http://www.github.com/abcminiuser/lufa/archive/LUFA-111009.zip, which means I get the files in the commit tagged with LUFA-111009. Currently the LUFA-111009 tag points at commit b838991, which defines ENDPOINT_DIR_IN
to be 0x01 in Endpoint_AVR8.h:
/** Endpoint data direction mask for \ref Endpoint_ConfigureEndpoint(). This indicates that the endpoint
* should be initialized in the IN direction - i.e. data flows from device to host.
*/
#define ENDPOINT_DIR_IN (1 << EPDIR)
//@}
I think the git tag for LUFA-111009 was placed on the wrong commit. Perhaps it should be moved from b838991 to either c5a05ed or beb069b, since both of those claim to be the "Commit for the 111009 release.".
Regardless of where the git tag points to, I would suggest that the link on fourwalledcubicle.com should point to the original LUFA-111009.zip (which has a sha1sum of fe6abf1cef6fb924d58f9158c5297e305b169a8f
). The reason is that the top-level folder in your original ZIP file is named "LUFA-111009" but the ZIP file created by github uses "lufa-LUFA-111009" instead. This difference makes it hard for people to communicate about LUFA-111009 and write correct instructions for how to extract it and use it. Old instructions that were based on the original ZIP file will generally not work.
Currently there is only HID_REPORT_ITEM_Feature
which is used to generate the RAWHID report descriptor. However with HID you can also differentiate between In, Out, Feature inside the Get/Set_Report Request. Those values differ from the definition above (+1). Something like HID_REPORT_TYPE_Feature
is wished.
Currently available:
http://www.fourwalledcubicle.com/files/LUFA/Doc/151115/html/group___group___u_s_b_class_h_i_d_common.html#gga3c0de6e2f6380c88937a5f09bcbf022ea468b3fdb884153aaefb634c9823f64bb
Requested:
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/libraries/HID/src/HID.h#L57
Source in the USB Spec:
HID Request Type HID1.11 Page 51 7.2.1 Get_Report Request
Please add those 3 values, as it is really helpful.
I tried to compile the latest CDC BootLoader for my Pro Micro(well not a leo but a 32u4) and it turn out that i cannot reupload sketches to the board. The Arduino software tries to touch the Serial at 1200 and tries to reupload the Code. But its not working:
Connecting to programmer: .avrdude: Send: . [1b]
avrdude: Send: S [53]
avrdude: ser_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
Problem uploading to board. See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.
With the older Pro Micro source (recompiled with the older Lufa) its working fine.
I am trying to figure out why this happens.
I also have a similar problem with my HoodLoader2 project. After a serial touch the leds start flickering, usb is detached but no sketch and no bootloader starts. Just the leds are flickering. I am wondering if i set the Watchdog timer wrong in my source.
Any Idea?
The command for programming EEPROM memory with dfu-programmer has changed in newer versions.
The one I have 0.6.2, uses 'flash-eeprom' instead of 'eeprom-flash'.
This still works in the latest version, but the recommended way appears to be 'flash --eeprom'
Also an erase command is needed before programming EEPROM (at least on atmega devices), which will leave the program memory blank.
make doxygen complains of an unknown command in KnownIssues.txt \cB on line 43. I think it should be "\c BOARD" rathern than "\cB OARD" but I am not familiar with doxygen.
Fixing this moves things along, but then is complains:-
/home/david/git/lufa/Demos/Device/ClassDriver/DualMIDI/Descriptors.h:56: warning: unable to resolve reference to `USB_MIDI_Descriptor_Jack_Endpoint_t' for \ref command
../../../../LUFA/Build/lufa_doxygen.mk:86: recipe for target 'doxygen' failed
and I am unsure how to fix this.
Thanks
David
As found by @NicoHood, the current core init code violates the best practice instructions in the datasheet for the U2 series (at a minimum). The PLL and pad regulators should be initialized before enabling the USB core.
There's been a payload minor revision change, but that alone doesn't fix the broken communication. I suspect there has been an extension to the protocol that I need to add to the existing clone firmware to make it compatible with AS7.
I'm doing binary transfers using the LUFA serial port. I can send 0x00 from the AVR to my PC via the USB serial port no problem but going the other way 0x00 get blocked, all other values seem to get through.
Have I got some configuration wrong or is it a bug? All advice gratefully received!
Hey,
I'm wondering what is going on with XMega support with this library. XMega's are better than the regular AVR8s in many ways in my opinion and they aren't exactly new anymore.
I noticed there is a pull request from 2013 for some XMega Bootloader support, but not merged here yet. Any plans of doing that?
Anyway, I would be glad to hear your thoughts on XMega series support with this library and I hope there will be some. Especially the Bootloaders.
Thanks!
Hi,
there are four bytes which should be output as signature:
30h Read Manufacturer Code
31h Read Family Code
60h Read Product Name
61h Read Product Revision
in BootloaderDFU.c I see (in todays Git-download):
const uint8_t SignatureInfo[4] = {0x58, AVR_SIGNATURE_1, AVR_SIGNATURE_2, AVR_SIGNATURE_3};
...
ResponseByte = SignatureInfo[DataIndexToRead - 0x60 + 3];
Questions:
a) Isn't the manufacture always 0x1E for Atmel, i.e. the AVR_SIGNATURE_1 value? What I see missing is the Product Revision where we might need an arbitrary value, but at the end of the list?
b) To cover access to the values which should be replied for the offset 0x60 and 0x61: maybe + 3 should read + 2 only. 0x61 would otherwise point behind the array when we add 3.
-- Reuti.
In lufa-LUFA-140302/LUFA/Drivers/Peripheral/XMEGA/TWI_XMEGA.c it looks like the capitalization of twi (in the function body) vs TWI (arguments) is mismatched.
Causes compilation errors like "XMEGA TWI_XMEGA.c - error: 'twi' undeclared (first use in this function)".
The code compiles once the capitalization is normalized.
Hello,
I've forked LUFA in order to modify it to work specifically with the Arduino UNO R3 (e.g. make the Board folder and the files within, modify the makefiles, etc). My intention is to keep the master branch of my fork identical to the master branch here, then do my modifications on a separate branch called arduino-uno-r3. Whenever the repo here gets updated, I'd pull into master, then merge those changes into arduino-uno-r3 and update as necessary.
How would you recommend to handle this situation? Is my fork a suitable way to develop for a specific board? Or is there some other way you'd recommend?
Hello,
I'm trying to add LUFA to a firmware that is built using several modules, each built in a separate static library, and linked together to produce the final elf file, but I encounter a link error with CALLBACK_USB_GetDescriptor
.
In order to keep it simple, I tried to replicate the project's structure using the ClassDriver MIDI Device demo in your repository, using my build system (based on CMake).
The whole project looks like this:
LUFA/Drivers/USB
are compiled.main
function has been removed from MIDI.c, and its contents have been spread out to two functions, init
and process
(one to be called before the loop, and the other one within).init
and process
have been added in MIDI.hmain
function calling init
and process
as described.LUFA and lufa-demo-core each compile to liblufa.a and liblufa-demo-core.a, C static libraries.
lufa-demo-firmware links against these static libs to produce the final elf, but fails to find the CALLBACK_USB_GetDescriptor
symbol, implemented in Descriptors.c, from its usage in USB_Device_ProcessControlRequest
in the file DeviceStandardReq.c.
All LUFA components use the same LUFAConfig.h file (the one from the demo), and the signature for CALLBACK_USB_GetDescriptor
matches in both the implementation and the call (so it's not a signature issue).
Please note that when building the demo files as-is in a single executable target, the link step succeeds.
I can't attach archives on GitHub, so here's a link to the modified demo files:
https://drive.google.com/file/d/0B7AbgN8zxRh0SmE0UDBoV0dWQTA/view?usp=sharing
More details if it helps:
Any insight would be most welcome !
Best regards,
Francois.
before I go ahead and start working on it, do you already have planned support for it? Can you think of any reason why it wouldn't work?
Thanks
https://github.com/abcminiuser/lufa/blob/master/Bootloaders/DFU/Descriptors.h#L121
https://github.com/abcminiuser/lufa/blob/master/Bootloaders/CDC/Descriptors.h#L87
Might also be in different bootloaders.
Should be 0x93 instead of 0x94 (8kb flash, not 16).
Page 246 http://www.atmel.com/images/doc7707.pdf
Issue found here:
NicoHood/HoodLoader2#6 (comment)
avrdude.exe: Device signature = 0x1e9482
avrdude.exe: Expected signature for AT90USB82 is 1E 93 82
Also have a look at the issue filed for my HoodLoader2 (which I linked above):
CDC programming does not work for an 8u2 but with an at90usb82 (with the signature patched).
The 8u2 setting only works if you use avrdude with at90usb82 settings and the -F switch. So I think it is an avrdude issue, not lufa. Any ideas about that?
Edit: avrdude bug: arduino/Arduino#3645
I'm using LUFA for my own multi-mcu/cross-platform bootloader that is using that HID trick to bypass windows signing once more and ran into a very weird issue:
The bootloader userspace tools are here: https://github.com/uISP/uHID-userspace
The bootloader itself (lufa and v-usb stacks): https://github.com/uISP/uHID-bootloader-avr
The same code works with no problems on the same hardware under windows, linux (hidraw and libusb alike) and freebsd, only mac is giving me pain (
Any idea where to start looking for the bug?
Its been a year since the last release, I suggest to create a new one.
There were a few bootloader fixes from my side which are very important. There are some opened issue left about that though. Not sure how long you want to wait for a new release, this should just be a reminder, that a year passed now since the last release.
The following code seems to have no effect when run on an ATmega32U4 whose host is a Mac running Sierra.
if (USB_DeviceState == DEVICE_STATE_Suspended)
if (USB_Device_RemoteWakeupEnabled)
USB_Device_SendRemoteWakeup();
Hey guys
I try to compile the examples and get this weird error.
/home/robert/src/lufa/Projects/AVRISP-MKII/Lib/ISP/ISPTarget.c:119: multiple definition of
__vector_17'
obj/SoftUART.o:/home/robert/src/lufa/Projects/XPLAINBridge/Lib/SoftUART.c:102: first defined here
/usr/lib/gcc/avr/4.8.1/../../../avr/bin/ld: Disabling relaxation: it will not work with multiple definitions
collect2: error: ld returned 1 exit status
../../LUFA/Build/DMBS/DMBS/gcc.mk:241: recipe for target 'XPLAINBridge.elf' failed
make[2]: *** [XPLAINBridge.elf] Error 1
make[2]: Leaving directory '/home/robert/src/lufa/Projects/XPLAINBridge'
makefile:44: recipe for target 'XPLAINBridge/' failed
make[1]: *** [XPLAINBridge/] Error 2
make[1]: Leaving directory '/home/robert/src/lufa/Projects'
makefile:19: recipe for target 'all' failed
make: *** [all] Error 2`
Any ideas?
It should be uint16_t, not uint8_t.
The description of the NO_LIMITED_CONTROLLER_CONNECT token states that on controllers with limited VBUS sensing capabilities, VBUS should be sensed by the application and the events raised by using the RAISE_EVENT macro. However, there is no RAISE_EVENT macro anywhere in the source code.
The documentation is also unclear about what should be done with the USB_DeviceState variable. Assuming I can figure out what state should be set when VBUS goes up (the documentation does not give a hint), it is still unclear how I get LUFA to do whatever is needed so that enumeration can start. Maybe this can work if the application calls USB_USBTask() regularly, but when INTERRUPT_CONTROL_ENDPOINT is set, then some interrupt must happen before any LUFA code can react to the change in USB_DeviceState. This looks like a documentation gap to me.
It seems teensy_loader_cli which your hid_bootloader_cli is forked from has been updated to accommodate newer arms with larger buffer allocation etc.
I updated newer teensy_loader_cli to accept LUFA firmware. (Unlike your current approach to try for both, I made USB ID choice to be deterministic. If compiled code is called as hid_bootloader_cli, it only works with LUFA firmware.
See it in the branched teensy_loader_cli repo
Also code itself is
I hope this patch set is more easy to track teensy code in future.
Osamu
The documentation states:
BaudRate Serial baud rate, in bits per second.
DoubleSpeed Enables double speed mode when set, halving the sample time to double the baud rate.
One might think that setting BaudRate to X and DoubleSpeed to true should result in an actual baud rate of 2*X.
In fact the BaudRate argument has to be the actual baud rate.
Currently, TWI_ReadPacket and TWI_WritePacket use a uint8_t for the data packet length. However, many EEPROMs allow reading sequential addresses over more than a 256 address range. I would suggest changing:
uint8_t Length
to:
uint16_t Length
For following code:
I see duplicate definition of ISR(...). Let me focus on AVR side for simplicity.
For ISR definition on line 77, it is always there.
For ISR definition on line 261, it is conditional with:
#if defined(INTERRUPT_CONTROL_ENDPOINT) && defined(USB_CAN_BE_DEVICE)
Do you expect to duplicate definition if INTERRUPT_CONTROL_ENDPOINT and USB_CAN_BE_DEVICE are defined?
Is this some fancy function overloading? But this is C code ...
With Windows's gestapo driver signing now being truly enforced, we need signed versions of the LUFA demo INF driver files to be able to continue to use them on Windows machines. Apparently CDC-ACM now works on Windows 10 without any driver files (yay!) but Windows 8 and below still have a lot of market share, and RNDIS and other projects still require a signed driver even on Win10.
The list of driver INF files requiring signing are:
The vast majority of these are effectively identical, except for different VID/PID and descriptions. This means signing should be relatively easy once we get the base classes (CDC, RNDIS) figured out.
@ehajo @mitchjs will you be able to assist? Does someone else with a valid signing certificate wish to help out?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.