Avr port #82
Avr port #82
Conversation
perigoso
force-pushed
the
avr-port
branch
2 times, most recently
from
0c6a24e to
dbe07f8
Compare
|
TODO before review:
|
|
|
||
| void usb_write_descriptor(u8 interface, u8 *report_data, u16 report_size) | ||
| { | ||
| if (interface == openinput_hid_interface.Config.InterfaceNumber) { |
| }; | ||
|
|
||
| /* create protocol config */ | ||
| struct protocol_config_t protocol_config; |
There was a problem hiding this comment.
I don't know what C version do openinput use, but this is possible on newer versions for zero initialization:
| struct protocol_config_t protocol_config; | |
| struct protocol_config_t protocol_config = {}; |
There was a problem hiding this comment.
I don't think we're freezing to a particular standard right now, but we do or will, it would be one that supports this
Either way, static uninitialized variables end up on the .bss and are set to 0 by default, at least on our arm targets
| * passed to all HID Class driver functions, so that multiple instances of the same class | ||
| * within a device can be differentiated from one another. | ||
| */ | ||
| USB_ClassInfo_HID_Device_t openinput_hid_interface = { |
There was a problem hiding this comment.
Is this aliased to const? I don't see changes to this memory so perhaps this can be on .data section or other read-only memory.
There was a problem hiding this comment.
This is just me playing with lufa and committing to save progress, this is will get a clean up
There was a problem hiding this comment.
The struct itself i don't think is written, so yes, although on avrs, consts are always fetched to ram anyway i believe
There was a problem hiding this comment.
The struct itself i don't think is written, so yes, although on avrs, consts are always fetched to ram anyway i believe
Well, yeah, I'm not aware of those embedded cases. Godbolt https://godbolt.org/z/soo4eaaev tells me it goes to .rodata and the compiler can optimize it to immediate loads instead of an offset. This is not always the case although, as I believe the jump cost is a trade-off the compiler takes into consideration, depending on size of the data/non-natural alignment.
Signed-off-by: perigoso <[email protected]>
Signed-off-by: perigoso <[email protected]>
Signed-off-by: perigoso <[email protected]>
…pcb by gilmore Signed-off-by: perigoso <[email protected]>
Signed-off-by: perigoso <[email protected]>
Signed-off-by: perigoso <[email protected]>
Signed-off-by: perigoso <[email protected]>
Signed-off-by: Rafael Silva <[email protected]>
Signed-off-by: Rafael Silva <[email protected]>
Signed-off-by: Rafael Silva <[email protected]>
Signed-off-by: Rafael Silva <[email protected]>
Signed-off-by: Rafael Silva <[email protected]>
Signed-off-by: Rafael Silva <[email protected]>
closes #57
cc @ljmf00