Back
[00:41:32] <eszett> in an usb cable, why is the usb shield drain wire not linked with the GND wire?
[00:42:45] <Casper> because you don't want that, you want a separate shield
[00:43:10] <Casper> if it was connected, it would also cary power, and throw interference in the ground line
[00:43:18] <Casper> at this point, why have a ground wire at all?
[00:44:02] <Casper> also, separating them also help to avoid noise in and out of the ground line, so happier devices and happier FCC
[00:44:06] <eszett> ok i understrand, but how do i connect it then to my pcb?
[00:44:46] <eszett> or do i better leave the drain wire just unconnected?
[00:48:04] <Casper> connect at the host to ground via a thick ground ideally
[00:49:14] <Casper> as for device side... most likelly the same, but some say to not...
[00:49:26] <Casper> all of what I checked connect it to their ground plane
[00:51:03] <eszett> the EMIs dissolve slightly when they go into a thick fill zone (connected to GND=) right?
[00:51:13] <eszett> due to the impedance of the fill zone..
[00:51:52] <Casper> not sure
[00:52:18] <eszett> but then again, the drain wire is a loose end, do i solder it on a special pad i have to create on my pcb??
[00:55:52] <Casper> yes?
[00:57:12] <eszett> never saw that on my collegues PCBs..
[01:19:23] <nofxx> Crossposting #electronics: Need 2 PWM, 2 Analog and webserver. Thinking bbb or rpi + avr. Any suggestion for the arm board? plug and pray SPI?
[03:00:58] <Casper> nofxx: also, consider plain serial
[08:50:11] <saedelaere> I often see code like this
https://bpaste.net/show/8ca2a46bff93 where a volatile variable is accessed from an ISR handler and the main loop. what can I do to ensure the volatile variable is accessed atomic?
[08:51:04] <bss36504> disable interrupts while reading it where you want it to be atomic
[08:51:05] <daey> saedelaere: you could add a lock variable
[08:51:07] <LeoNerd> Use an atomic variable type
[08:51:27] <LeoNerd> Your platform/compiler will tell you what types of variable are atomic. I'd imagine on AVR, that's only chars
[08:51:45] <LeoNerd> Anyhing larger you'll want to do the save_SREG / cli() ... / restore SREG trick
[08:51:54] <daey> besides is double access even possible?
[08:52:16] <daey> theres no parallel processing going on
[08:52:56] <bss36504> daey: I assume he means he wants to read the variable and do something with that value in an atomic context. Otherwise, you're right, I dont think the variable can be updated "mid read"
[08:52:58] <daey> just the order in which things are done is random
[08:53:13] <daey> can be random*
[08:53:55] <bss36504> saedelaere: atomic.h has some defines that let you make an atomic block. It's really just doing a cli() <your code> sei() though
[08:54:17] <LeoNerd> you don't want to do that. you definitely want to use the save_SREG version
[08:54:28] <LeoNerd> In case interrupts /weren't/ enabled before you starte
[08:54:29] <LeoNerd> d
[08:57:16] <saedelaere> bss36504: So I need do this in my main loop --> ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {/* read global flag */}
[08:57:29] <LeoNerd> If your flag is larger than a char, yes
[08:57:42] <LeoNerd> So if you can, just make it a char then it's fine
[08:57:59] <saedelaere> LeoNerd: okay so in my case I do not need to do this because I am using an uint8_t
[08:58:08] <LeoNerd> Indeedy
[08:58:28] <saedelaere> LeoNerd, daey, bss36504 thanks a lot!
[08:59:19] <Emil> Anyone have a usb example thats not obsfucated like the lufa is
[08:59:20] <Emil> ?
[08:59:30] <Emil> for m32u4 or similar
[08:59:53] <LeoNerd> I'm not sure lufa is obfuscated... at least, certainly not intentionally
[09:00:05] <Emil> obfuscated*
[09:00:05] <LeoNerd> USB is just an awkward thing to perform, so the code will be rather longwinded
[09:01:17] <Emil> Eh
[09:01:25] <Emil> But you get my point
[09:01:36] <LeoNerd> No, I don't
[09:02:17] <Emil> A simple exactly one file program that sets up a usb serial port and sends and receives data through iy
[09:02:28] <LeoNerd> That's going to be quite long
[09:02:32] <LeoNerd> USB is just long like that
[09:02:59] <LeoNerd> There's a long bunch of crap about descriptors and strings and so on which is just the nature of USB
[09:03:08] <LeoNerd> Very little of that code will /actually/ be about being a virtual serial port
[09:03:25] <Emil> Which is fine
[09:27:18] <bss36504> Emil: LeoNerd is totally right, USB sucks. It's "hard" (ie, complex) to program for. There will be no single file implementation that is somehow more readable than LUFA.
[09:27:57] <bss36504> LUFA is very well written and documented, you'll be better off learning how it works. Or, write your own by studying the datasheet and reading up on the USB spec.
[09:28:31] <LeoNerd> Yah; the USB spec is like.. totally less than a thousand pages.. just.
[09:28:39] <LeoNerd> So that should be a quick read :)
[09:29:26] <bss36504> Oh and it's extremely easy to comprehend, what with the minimal list of glossary terms you need to know /s
[09:30:20] <bss36504> To be fair though, it's difficult to make something a universal serial bus without it being very complicated.
[09:30:29] <bss36504> Whoops, meeting time. Be back later
[09:30:41] <LeoNerd> Oh indeed. It's not a simple problem. Complex problems tend to have complex solutions
[09:30:45] <LeoNerd> That is just the nature of things
[09:32:30] <skz81> <LeoNerd> Anyhing larger you'll want to do the save_SREG / cli() ... / restore SREG trick >> cli /sei is ok for an atomic operation. You restore SREG after an interrupt, here you can save one cycle
[09:32:59] <LeoNerd> But that unconditionally enables interrupts
[09:33:03] <LeoNerd> Which would be Bad
[09:33:34] <skz81> not always enabled at first, indeed...
[09:34:13] <skz81> then, you could save one cycle when sure interrupts were enabled in the first place
[09:34:21] <skz81> ;°)
[09:36:12] <skz81> Already discussed before, actually... I really need to be more patient, read ALL, and ONLY THEN, think, and ENVENTUALLY, post...
[10:23:09] <Emil> bss36504: not true. USB is not complex from a data transaction or negotiation standpoint
[10:23:16] <Emil> The documentation is shit
[10:31:57] <bss36504> Emil: Well if it's not complex, why is the documentation so g-dang long? Why can't you write programs in a single file? There's no such thing as importing usb.h and magically making a device function. It just isnt that simple. The biggest mistake is to think that USB and regular UART/Serial are even remotely similar.
[10:32:25] <bss36504> (I understand you *could* write a single file program, obviously. You just shouldn't if you value your sanity)
[10:35:04] <twnqx> it pretty much depends what your hardware does
[10:38:17] <_ami_> bss36504: what are you trying to do with usb device? i am late to party! :)
[10:38:45] <_ami_> bss36504: i did some hacks with usb devices recently.
[10:38:49] <sabor> party? where? i only have tea here ;)
[10:38:58] <_ami_> sabor: :)
[10:39:56] <bss36504> _ami_: I'm not doing anything, Emil was just lameting the complexity, and asking why you cant just have a *simple* usb-uart deal
[10:40:36] <bss36504> _ami_: Emil - Anyone have a usb example thats not obsfucated like the lufa is
[10:43:36] <twnqx> admittedly, i tried to understand the LUFA code too, and kind of failed
[10:45:29] <bss36504> It is very complex, but also quite elegant. Think in more of an object oriented sense and it's easier. everything is controlled by data structures, and most (all? been a while) of the hardware setup is abstracted for you. Can;t really get any easier than that. The whole point of OO is that you dont have to know how the car operates, you just need t
[10:45:29] <bss36504> o know what all the buttons do.
[10:46:09] <twnqx> see
[10:46:17] <twnqx> and that's the opposite of what i want :)
[10:46:40] <bss36504> Why?
[10:47:00] <bss36504> If you want to learn USB, do what Dean did and study it. If you want it to work, just use LUFA
[10:47:27] <twnqx> personally, i would want a middle ground
[10:47:28] <bss36504> but I don't think LUFA is a training piece. it wasnt designed to be incrementally studied for an unlearned USB-er :)
[10:47:59] <twnqx> something that abstracts the hardware, takes my config, and has callbakcs or whatever per endpoint
[10:49:25] <bss36504> I mean...that's what LUFA has.
[10:49:49] <twnqx> if that's the case, i just did not find it
[10:50:25] <bss36504> Well I only ever messed with the mass storage class example. But effectively there is some MSC code that he wrote that takes function pointers to your actual read and write code
[10:50:56] <bss36504> But you could go up the chain and write the USB-class code, such as replacing the MSC driver with another device type
[10:52:57] <osteri> search for EVENT in the LUFA codebase
[10:53:34] <osteri> IIRC
[10:53:50] <twnqx> for me it was - at that time - HID class devices
[10:54:04] <twnqx> there's a neat guide for their descriptors and what they do on the web
[10:55:09] <bss36504> All the descriptor stuff is pretty well exposed. you are writing values into a USB_DESCRIPTOR struct (or something like that)
[10:55:28] <osteri> the USB standard itself is also quite complicated
[10:55:30] <bss36504> plus, LUFA includes an HID example that i'm sure you could leverage
[10:56:00] <twnqx> it did not compile for my at90 usb :P
[10:56:12] <twnqx> and i failed to change the hardware
[10:56:59] <twnqx> but admittedly, i used another approach later
[10:57:06] <twnqx> and didn't look particularly long
[11:00:21] <bss36504> ewww at90USB
[11:03:36] <twnqx> it's what i have around :P
[11:03:59] <bss36504> 32u4 is where it's at
[11:04:22] <twnqx> i might have an arduino leonardo without arduino crap
[11:06:07] <bss36504> That would be good too. I've said it before, I'll say it again: It's not a bad hardware design/form factor. Just shitty, shitty software
[11:10:05] <_ami_> hid and usb are two different things.
[11:10:29] <bss36504> _ami_: HID is a usb class
[11:10:38] <_ami_> i think hid is lame.
[11:10:40] <_ami_> not usb
[11:10:43] <bss36504> it's also a generic acronym.
[11:10:48] <bss36504> what?
[11:11:27] <bss36504> https://en.wikipedia.org/wiki/USB#Device_classes
[11:11:38] <bss36504> 0x03: HID - Keyboard, mouse, joystick
[11:12:08] <_ami_> i know, but you can do HID over I2C or usb too.
[11:12:25] <_ami_> its just that usb supports/facilates usb
[11:12:36] <_ami_> usb supports/facilates hid**
[11:12:51] <bss36504> Ok, sure, but clearly in the context of this conversation we were talking about USB's HID implementation. No need to be pedantic.
[11:13:09] <osteri> is the at90 that wannabe-usb-stick?
[11:13:34] <bss36504> at90USB is an old AVR with USB. Might be the first one, I dont remember exactly
[11:13:36] <_ami_> hid is unnecessary complex.. may be generic things are hard to write in softwares.
[11:13:46] <bss36504> the 32u2 and u4 are vastly superior
[11:14:17] <bss36504> _ami_: I think that's exactly the case. If you want to cover a large cross section of use cases, your code gets big and complicated.
[11:14:32] <_ami_> bss36504: true
[11:21:01] <scoy> can somebody explain how USART_MAX_BUFFER keeps txHead below the max buffer size? ...
http://pastebin.com/g9Fu7BZH
[11:21:41] <_ami_> has anybody read this book?
https://www.amazon.com/Kicad-Like-Pro-Electronic-professional-ebook/dp/B01CYB95A8#nav-subnav
[11:21:51] <_ami_> howz it? thinking of buying it.
[11:22:24] <sabor> scoy: we can only guess if you do not show all the code
[11:23:13] <sabor> scoy: but from the names i would guess that max buffer should be 2^n
[11:23:20] <bss36504> scoy: Assume the MAX_BUFFER is 0x0f. What would be the result if you bitwise-and 0x1F with it? 0x0F&0x1F = 0x0F, which demonstrates that you have truncated the "data" (in this case, 0x1F) down to the MAX_BUFFER number
[11:23:57] <bss36504> tl;dr, if the number is bigger than the MAX_BUFFER, the upper bits get chopped off while preserving the lower bits.
[11:26:46] <scoy> thanks for all the input. my guess is that it prevents txHead from exceeding 100, or MAX_BUFFER_SIZE.
[11:26:53] <bss36504> That said, it's sort of an odd method. I dont know where that would be useful in the context of a USART, but without more code who knows. If you just want to truncate a number down to a particular width, you can just use the modulus operator.
[11:27:24] <bss36504> n%100 // n will never exceed 100
[11:27:36] <bss36504> or rather, the result of that expression will never exceed 100
[11:27:38] <bss36504> my bad
[11:27:54] <scoy> bss36504: I saw it AVR1309 and figured it was preventing txHead from exceeding MAX_BIFFER_SIZE
[11:28:36] <bss36504> Yeah, I guess it would work. It just seems weird since youd be bitwise and-ing with 99 (base 10). Without reading the app note idk. \
[11:32:07] <scoy> so if I understand correctly, this accomplishes the same thing ...
http://pastebin.com/EEAhCZUF
[11:32:58] <scoy> just learning here and making sure I got that right
[11:34:25] <bss36504> I...guess. It depends on what txHead is used for...
[11:34:32] <bss36504> but it seems approximately equivalent
[11:48:45] <scoy> bss36504: thanks
[12:44:24] <_ami_> twnqx: is there any document on explanation of hid driver in linux kernel?
[12:45:28] <_ami_> why few drivers overrides report? e.g. .report_fixup = _override_report;
[12:48:09] <_ami_> is it because of firmware bugs?
[13:26:02] <Emil> bss36504: the point is that usb, like every protocol ever, is just bytes in certain ordee
[13:26:23] <Emil> abstracting those bytes to a struct that is then clocked out helps no one understand
[13:26:37] <Emil> You asked why is the spec so long, that is because it is shittily written
[13:28:50] <Emil> Also because microsoft
[13:30:45] <bss36504> Emil: I guess we will have to just agree to disagree on this one. I think the spec is long because the spec is complicated. I think abstraction is a good way to separate the nitty gritty details from just getting it done. You seem to want to know USB inside an out, yet you're unwilling to do the extensive research necessary to get that understandin
[13:30:45] <bss36504> g. If you want a cut down version, buy a book on USB, but guess what, those books are still many hundreds of pages long. Because it's complicated. Like I said before, LUFA isnt a learning vehicle for USB programming, it's an implementation library that gets your device talking to the computer over USB in like 10 minutes, AND gives you enough tools
[13:30:45] <bss36504> to do your own shit.
[14:16:27] <ub|k> is using interrupts to handle rotary encoders a good idea?
[14:16:44] <LeoNerd> rotary encoders are really just slightly odd buttons
[14:16:47] <LeoNerd> So, I don't see why noyt
[14:18:14] <ub|k> LeoNerd: i've read some stuff against using interrupts for buttons
[14:18:43] <nofxx> Casper, I'm always on foot behind with serial... stable? maybe with a good code, error rescue, reconnect...
[14:19:06] <LeoNerd> ub|k: Oh?
[14:19:21] <bss36504> ub|k: gotta be careful about button bounce and how you handle it when using interrupts for button reading
[14:20:06] <bss36504> It's probably less of an issue with a rotary encoder, but don't quote me on that.
[14:20:41] <LeoNerd> They might still bounce.. but just handle that the same as anything else.
[14:20:47] <LeoNerd> I usually debounce buttons via a small delay
[14:21:11] <LeoNerd> the pinchange interrupt just schedules a timer in a few system ticks.. when that expires, the real IO handling task executes which reads the now post-bounce pin state
[14:21:26] <LeoNerd> It does add a few tens msec delay, but that's usually not noticable to the human operating it
[14:21:30] <nofxx> me too... the hw way is a diode and a cap? refreshing my mem
[14:21:45] <bss36504> resistor and cap
[14:21:48] <bss36504> low pass filter
[14:22:08] <nofxx> ah, right, makes more sense too
[14:23:57] <bss36504> also, you could probably get away with just a cap if you size it based on the impedance of the encoder's outputs
[14:24:07] <bss36504> assuming the drive strength isnt too high
[14:24:35] <LeoNerd> I wouldn't bother - software is cheaper/easier/smaller/...
[14:24:44] <bss36504> Very true
[14:31:12] <nofxx> Just out of curiosity, how ppl are connecting avr's to these pc boards? (rpi/bbb/bananapi)
[14:31:23] <nofxx> serial/spi/i2c
[14:32:05] <nofxx> those boards are nice, but I/O is a joke
[14:32:07] <ub|k> apparently, internal pull-up resistors plus 104 cap is enough
[14:32:30] <ub|k> i think that if someone were to elect the most important component in the history of electronics, that would be the 0.1uF ceramic cap.
[14:33:33] <nofxx> ub|k, as in when you find that nice schematics online and it's always the only comp you do have
[14:33:59] <nofxx> lying around
[14:34:57] <ub|k> yeah :D
[14:35:25] <ub|k> i think you can build anything out of 104 caps and 1K and 10K resistors
[14:35:52] <bss36504> ub|k: except for anything with logic or inductance ;)
[14:39:18] <nofxx> bss36504, ok, buch of 104 and 1k, 1m of wire and a pencil to coil it, and one avr =D
[14:39:58] <nofxx> ICs are for cheaters
[14:41:44] <twnqx> _ami_: yes, typically it is erratic hardware
[14:42:58] <_ami_> twnqx: i was trying to load a custom hid driver.. but the probe is not getting called. i did unbind the device from "usbhid"
[14:43:39] <_ami_> twnqx:
https://github.com/amitesh-singh/ldd/blob/master/usb/hid/simple-hid.c
[14:44:08] <_ami_> any pointers on why probe() is not getting called?
[14:45:50] <twnqx> i am probably the wrong one to ask, sorry
[15:04:18] <_ami_> twnqx: got the reason though. vendor id 0x160c which i was using was not in ignore list for usb generic hid (hid-core.c). so i used apple vendor id and now my hid driver probe is getting called.
[15:06:37] <_ami_> updated firmware also with apple vid and pid
[16:59:42] <ub|k> the difference that a 47 uF between Vcc and GND can make...
[16:59:46] <ub|k> )cap=
[21:41:15] <scoy> after i disable an interrupt on a USART module, do I need to wait or test that it's fully disabled before moving on? XMEGA IC