#avr Logs
Oct 08 2019
#avr Calendar
12:05 AM day__ is now known as day
02:48 AM Maya-sama is now known as Miyu
02:48 AM Miyu is now known as hackkitten
06:10 AM twnqx: :( what do i do if LUFA is far too slow for USB on a mega 32u4? any alternatives?
06:11 AM LeoNerd: Too slow?
06:11 AM twnqx: it misses usb frames
06:12 AM twnqx: i can see them in a usb monitor, but my program on the chip doesn't receive them
06:13 AM twnqx: (usb monitor = physical device, listening on the wire in between)
06:13 AM twnqx: a software implementation on a mega8 (based on tinyusb) doesn't have this problem
06:14 AM twnqx: there's about 26µs between the ack from the host on the last tranaction until the setup of the next, which is missed
06:54 AM cehteh: twnqx: are you sure you didnt drop frames by some other bug?
06:55 AM LeoNerd: I've done pretty odd things with LUFA on 32U4 before, and I've never seen it drop a frame
06:56 AM twnqx: i have a device that runs control endpoint only, and not every control frame reaches EVENT_USB_Device_ControlRequest
06:57 AM cehteh: prolly bug in your code, running extended times with interrupts disabled or so
06:57 AM twnqx: my code is down to this:
06:57 AM twnqx: for (;;) { USB_USBTask (); }
06:58 AM cehteh: what osc do you use?
06:58 AM twnqx: 16mhz external on an arduino leonardo
06:59 AM LeoNerd: Doesn't USB need to be 12MHz ?
07:01 AM twnqx: it has a 48mhz PLL, so i guess it's just a matter of setting that correctly
07:02 AM LeoNerd: Not sure offhand how you make 48 out of 16
07:02 AM cehteh: should be doable with pll
07:02 AM LeoNerd: Oh. it's just *3 ;)
07:02 AM cehteh: :D
07:03 AM cehteh: i still suspect something going wrong there, usb is handled in hardware, i henver used that but that should work reliable
07:03 AM twnqx: i agree to that sentiment
07:03 AM cehteh: when it drops frames then only because they are either too fast or you dont handle them in time
07:04 AM cehteh: USB_USBTask (); is what?
07:04 AM twnqx: the weird thing is: every now and then i get a build that works
07:04 AM twnqx: LUFA's main loop
07:04 AM cehteh: and do you hook anything into that main loop?
07:05 AM twnqx: yes, the code that handles the control requests
07:05 AM cehteh: so that code causes it
07:05 AM twnqx: i seriously doubt that
07:05 AM cehteh: remove it, only increment a counter
07:05 AM twnqx: can't
07:05 AM cehteh: send 1000 frames, check if that counter is 1000
07:05 AM twnqx: that code is what does the replies.
07:06 AM cehteh: still something wrong there
07:06 AM cehteh: at least thats my suspiction
07:07 AM twnqx: https://pastebin.com/aAKNK5WX
07:08 AM twnqx: hm
07:08 AM twnqx: bloody hell
07:08 AM twnqx: ok, i need to dig into lufa's serial code
07:09 AM cehteh: handle_i2c_request (); is that blocking?
07:09 AM twnqx: i was expecting that to be sane, ringbuffer + interrupt driven IO
07:09 AM cehteh: same for DPRINTF
07:09 AM twnqx: DPRINTF is a wrapper aroudn printf
07:09 AM cehteh: yes .. blocking or not?
07:09 AM twnqx: which seems... not the best idea
07:09 AM cehteh: :D
07:10 AM twnqx: ok, when disabling debug mode, this part is gone
07:10 AM twnqx: and the handle_i2c... it just has to block
07:10 AM twnqx: given the results are to be transmitted back
07:10 AM cehteh: bad idea i guess
07:10 AM twnqx: it works with the i2c-tiny-usb
07:10 AM twnqx: which also bitbangs 1.5mbit usb at the same time
07:11 AM twnqx: but maybe THAT is why it works
07:11 AM cehteh: whatever
07:11 AM twnqx: as it gives 10x the time
07:11 AM cehteh: i'd rather do things async, never block
07:11 AM twnqx: i want this to work with the existing linux kernel driver, rather than writing a new one
07:12 AM cehteh: problem is most likely in your code anyway
07:12 AM cehteh: aka this blocking
07:13 AM twnqx: ok, need to figure out how to make LUFA be a low-speed device :P
07:13 AM cehteh: nah you need to figure out how to code this correctly
07:14 AM cehteh: by just going slower your code only works by chance, not by design
07:14 AM twnqx: the driver says
07:14 AM twnqx: "the reply is in the answer packet."
07:14 AM twnqx: and i know the answer only after running the i2c code
07:14 AM cehteh: yes
07:14 AM twnqx: so
07:14 AM twnqx: i can send the answer only after running the i2c code in the middle
07:15 AM twnqx: not async. nlocking is the only option.
07:15 AM twnqx: blocking*
07:15 AM LeoNerd: I²C is sufficiently slow as compared USB that you likely want to async that around it
07:15 AM twnqx: again: it is not my driver
07:15 AM cehteh: either you query i2c regulary so you know the result beforehand or you reply immediately with "please ask me again"
07:15 AM twnqx: i am trying to build a device that is compatible to an existing, working one
07:16 AM twnqx: this device is an abstract i2c master
07:16 AM twnqx: that is connected to a host via usb
07:16 AM cehteh: still you must not violate the usb specs and/or stall the usb stack .. that wont work
07:16 AM twnqx: so i cannot do anything regularly, in advance, or whatever
07:16 AM twnqx: as i have no information about the userspace client
07:16 AM cehteh: there must be some way .. or this just wont work
07:17 AM twnqx: as it currently works
07:17 AM twnqx: there must be a way
07:17 AM cehteh: dunno what device that is
07:17 AM twnqx: https://github.com/harbaum/I2C-Tiny-USB
07:17 AM cehteh: i am pretty sure there is a working way, but just throttleing the speed sounds less optimal to me
07:17 AM twnqx: i agree
07:18 AM twnqx: the only thing i need to have is the ACK/NAK(timeout, ...) for the addressing
07:18 AM cehteh: i dont know anything about that
07:21 AM cehteh: i dont even know if its request, reply in exact order, cant you delay the reply and still have usb active (doing protocoll stuff, receiving other requests, pinging) while the reply is still pending? no idea
07:21 AM twnqx: no
07:21 AM twnqx: first of all, up the debug serial console to 2mbit/s
07:22 AM cehteh: well i dont know that about usb, but there is still some stack with physical and protocol handling at the lowest this may need some more or less constant petting
07:22 AM cehteh: then you have enpoint layers above which do their job
07:23 AM twnqx: i suppose that exxactly is the problem :P
07:23 AM cehteh: ok i dont know but feels to me like you stall it and it times out and breaks
07:23 AM twnqx: nah, i probably exceed some other timing
07:23 AM cehteh: thus you need to do things async and handle the lower usb stuff while preparing the reply, non blocking
07:23 AM cehteh: again i dont know,
07:23 AM twnqx: again, then i need to change the driver, likely
07:24 AM cehteh: but if it expects soem reply within some timout and you cant give it becasue i2c is too slow then it wont work, you should at least send an error 'in time' and done
07:24 AM cehteh: no idea, its not an offical linux driver, maybe its crap, but i'd first expect the error on your side
07:25 AM twnqx: uh
07:25 AM twnqx: it is in-kernel for ages
07:25 AM twnqx: yes, it is a regular, mainline driver
07:27 AM cehteh: ok
07:27 AM cehteh: then its your fault for sure
07:28 AM twnqx: well, the point of usb delay vs. i2c frequency is also correct
07:28 AM twnqx: it might simply not be possible with anything but low speed
07:28 AM cehteh: you can reply with an error?
07:28 AM twnqx: that's not helpfull unless i change the driver :P
07:28 AM cehteh: huh?
07:29 AM twnqx: if the user asks the kernel "send these bytes to the device at ID xx" and the kernel only replies with "error", that's not helpful.
07:29 AM cehteh: well then the user asks again?
07:29 AM twnqx: and the driver only returns what the device returns.
07:30 AM twnqx: nah
07:30 AM twnqx: that would mean touching every single client out there
07:30 AM twnqx: that uses the generic I2C API
07:31 AM cehteh: then you need to find some way to delay the reply, possibly by sending "i am still busy, wait a moment" over usb, handling some pings/protocoll stuff while the i2c query runs
07:31 AM twnqx: so, 2mbit serial, no printf wrapper but directly to the hardware, and down to 1.5mbit usb - works
07:32 AM twnqx: at least for stage one, the one command i missed is found now.
07:32 AM cehteh: makes sense as you are then slow enough to query the i2c in time
07:32 AM twnqx: nah, this wasn't even with i2c so far
07:32 AM cehteh: but i bet there are better ways to handle that
07:32 AM cehteh: ok
07:32 AM twnqx: before it was "sending four bytes as a string thorugh printf"
07:33 AM cehteh: anyway .. i am doing my stuff now
07:33 AM twnqx: well, you gave me some insight, and pointed to the right things :) thank you and have fun!
07:33 AM cehteh: lesson learned: when it doesnt work its 99.9% your own fault
07:34 AM twnqx: i really didn't expect the printf() overhead to be THAT high
07:34 AM twnqx: but apparently it's >22µs on AVR.
07:35 AM Fuchikoma: Code in assembly! :D
07:36 AM cehteh: its not the overhead its the blocking
07:36 AM twnqx: my main goal was to learn LUFA :P
07:36 AM twnqx: cehteh: true, but without the overhead the blocking doesn't matter
07:36 AM cehteh: well it has some overhead as well, but when your output queue is full it blocks until it sends some bytes
07:36 AM Fuchikoma: (*as much)
07:37 AM cehteh: anyway dont use printf then
07:37 AM twnqx: i mean, i'd only ever queue the string that arrives, and use an interrupt driven serial handler to empty the buffer
07:37 AM cehteh: i dont even know how big the serial buffer is you have
07:38 AM twnqx: hardware? 2 bytes max
07:38 AM twnqx: in software? blocking, i am afraid (didn't look yet, not my code)
07:38 AM cehteh: lol ok
07:38 AM cehteh: i have non blocking io in my code :D
07:39 AM twnqx: me too
07:39 AM cehteh: no you use printf :D
07:39 AM twnqx: first time
07:39 AM twnqx: for convenience :(
07:39 AM twnqx: by last project was way worse
07:39 AM cehteh: and printf comes with some kind of interpreter .. the thingy that parses the formatstring and dispatches actions depending on that
07:40 AM twnqx: it would totally run in interrupt handlers only
07:40 AM cehteh: thats kindof heavy even its well optimized in avr-libc
07:40 AM twnqx: yeah
07:40 AM twnqx: but i wanted to print dynamic values
07:40 AM cehteh: i have output functions for every type and when the buffer is full they fail and return an error immediately
07:41 AM twnqx: my buffer discarded pending output instead
07:41 AM twnqx: but that's a matter of preference
07:41 AM cehteh: and a locking function where you tell in advance how much buffer space you need it will schedule other tasks when the buffer iisnt available yet, thus you have some explicit blocking and it does something else inbetween
07:42 AM twnqx: i don't do multitasking on avr :P
07:42 AM cehteh: its not really multitasking, just scheduling, cooperatively
07:42 AM cehteh: single stack
07:43 AM cehteh: kindof you need to do when you want to do things async .. and you certainly want that somehow
07:44 AM twnqx: i'd do that event based, with an event queue
07:44 AM twnqx: you could just skip things that would block and process the next
07:45 AM cehteh: thats kindof what i have,
07:45 AM twnqx: uhhh it's worse than i thought
07:45 AM twnqx: yes, i'll have to go async, whatever it costs... the callback runs inside an interrupt handler
07:46 AM cehteh: better schedule callbacks to be called immediately after the isr
07:46 AM twnqx: lufa is not my code
07:46 AM twnqx: _I_ would
07:46 AM cehteh: calbacks inside ISR are pretty hard
07:47 AM twnqx: at least i was correct in delcaring the variable volatile.
07:48 AM cehteh: usually its better trying to avoid that :D .. but when you need it you must do
07:48 AM * twnqx goes back to the original code and hopes he misread it
07:48 AM cehteh: copying a value out of the isr is often better
10:28 AM julius: hi
10:29 AM julius: in this howto: https://www.pocketmagic.net/avr-sdcard-fat-support-with-fatfs/ theres a SDCS connector on the sdcard adapter, where would i connect that to on a avr?
10:32 AM cehteh: plenty
10:33 AM cehteh: i wonder if one really wants fat support
10:34 AM cehteh: has prolly a lot of overhead
10:36 AM julius: first experiments with saving data
10:36 AM julius: i just want to log my temperature sensors output every minute or so
10:36 AM Fuchikoma: FAT has a lot of support across lots of different platforms
10:36 AM cehteh: up to you, i'd prolly go with just raw saving
10:36 AM cehteh: yeah, well i only suspect that fat has some overhead, but its pretty simple to maybe ok
10:37 AM julius: of course it has overhead
10:37 AM julius: its huge to any code i wrote
10:38 AM julius: what do you mean by plenty cehteh, SDCS is listed in te same picture as MOSI/MISO and so on....so i was thinking its some kind of special port?
10:38 AM cehteh: https://www.mikrocontroller.net/articles/MMC-_und_SD-Karten
10:39 AM Fuchikoma: SDCS is card select
10:41 AM cehteh: dont forget that spi is rather slow and when you use a big card wrinting it at this slow speeds will be insanly slow :D
10:42 AM Fuchikoma: It's not clear at all is SDCS shold be high or low, but if there's only one device in your project you can try using a 10K resistor to connect it to either +3.3 or GND
10:42 AM Fuchikoma: If it doesn't work, try it the other way
10:43 AM twnqx: so the usb part works now... figured out where in the sequence of calls the open window is
10:43 AM twnqx: just the avr refuses to do I2C now :(
10:43 AM twnqx: guess i need a logic analyzer or scope to see what is going on
10:43 AM cehteh: see the link i posted, that suggest you toggle the whole card on/off (including pullups) with a pfet
10:44 AM cehteh: twnqx: you dont have one? .. get one
10:44 AM cehteh: $12
10:44 AM twnqx: i have a bad habit of not buying cheap
10:44 AM cehteh: lol
10:44 AM Fuchikoma: twnqx: I recommend a LA if you have neither; They're a better tool for this kind of thing
10:44 AM cehteh: you dont need more for this
10:45 AM twnqx: the more reasonable logic analyzers i had on the shortlist where around 1.2k
10:45 AM Fuchikoma: That's pretty insane
10:45 AM twnqx: a few dozen channels in the ghz range is not THAT insane
10:45 AM cehteh: you can always buy 10k$ logic analyzer but it wont help you more than a $12 one in this case
10:45 AM Fuchikoma: What level of development are you doing?
10:45 AM twnqx: "any" :P
10:46 AM Fuchikoma: Yeah that's dumb
10:46 AM cehteh: as in basics :D lol
10:46 AM twnqx: i mean, the next project features ddr3
10:46 AM Fuchikoma: Does it, now?
10:46 AM cehteh: hah rly .. you dont even have this usb2i2c flying yet
10:46 AM twnqx: this one is just supposed to become a usb controlled driver board at some point, so avr should do the trick
10:46 AM julius: Fuchikoma, thanks
10:47 AM twnqx: cehteh: yeah, but i only speccing it
10:47 AM julius: cehteh, im not worried about speed. one decimal with 5 digits every minute shouldnt be a problem
10:47 AM cehteh: julius: just saying :)
10:48 AM twnqx: also, it makes no sense that i even see 2.5V at the ppins in idle
10:48 AM cehteh: anyway read the article above ... should be simple
10:48 AM Fuchikoma: https://sigrok.org/wiki/Supported_hardware#Logic_analyzers
10:48 AM twnqx: yeah, guess i'll just use that with a bus pirate
10:48 AM twnqx: though that doesn't work with weird voltage levels that shouldn't be there
10:48 AM Fuchikoma: Most of those are under $100 and will be more than you'll need for the foreseeable future.
10:48 AM cehteh: i have these simple saelae clones, which work well for me, dont need any more. using those with sigrok/pulseview .. thats all i need
10:49 AM twnqx: i mean, i was happy i had a USB analyzer around
10:49 AM cehteh: if course when you want to analyze things like DDR3 you need equipment on another level. but i rather doubt that makes any sense now
10:49 AM twnqx: yeah, and given that will be BGA, can't reasonably connect anyway
10:50 AM twnqx: but a bus pirate should do, no`?
10:50 AM cehteh: for ddr ram?
10:50 AM cehteh: noway
10:50 AM twnqx: no, for I2C
10:50 AM cehteh: ah yes
10:50 AM cehteh: well should do
10:50 AM Fuchikoma: I have a LWLA1034 which is brilliant, and I only got that one 'cause I had an application where I needed to monitor 20 lines at once
10:50 AM twnqx: my bigger issue is that i'd like to see the waveform on voltage level
10:51 AM cehteh: buspirate isnt that great
10:51 AM twnqx: but i could never convince myself to get a scope for that
10:51 AM cehteh: for exact timing and voltages you really need a scope
10:51 AM twnqx: anyway, i'll call it a day. bbl
12:12 PM damjan: I just got my stm32g031 disco kit
12:12 PM damjan: but it seems that stlink 1.5.1-1 doesn't recognize it
12:29 PM davor_ is now known as davor
12:34 PM Helle is now known as Guest68470
04:43 PM Smashcat: Anyone experienced an ATMel ATMega IC developing a short between VCC and GND? I had a batch of boards made in China (PCBA) and several have developed the same issue. I've replaced the Atmel part and it solves the problem!
04:44 PM Smashcat: It's a bit annoying as everything's SMD, and a lot of small parts close to the MCU...
04:44 PM LeoNerd: What footprint? Often VCC and GND are neighbours on newer chips. Maybe a pin short?
04:52 PM cehteh: bad soldering?
04:54 PM Rez: solder whiskers?
04:56 PM cehteh: ESD defect .. somewhere they got overvoltage and the diodes between vcc/gnd gone short?
05:17 PM Smashcat: cehteh: Sorry, was in another channel. Yeah the board design is fine - same one I've been hand-assembline with no problems. I didn't see any bridges. And the MCUs were still faulty once I put them into a test jig. Replacements are fine on the same boards.
05:19 PM Smashcat: They're all TQFP-32 footprints. So not THAT fine pitch :)
05:19 PM Smashcat: There are other parts with smaller pitch pins on the same PCBs that don't have issues. I suspect a bad batch of MCUs.
05:58 PM timemage: Smashcat, any chance you have something like a 328pb vs 328p ?
06:29 PM cehteh: moreover are you sure you have a short? ... can you put it in a testbench with *only* the VCC's and GND's connected and measure the current drawn?
07:18 PM Smashcat: sorry, back. Yep, definitely shorted, as I put the MCUs into a test jig without anything else connected, and a dead short across VCC and GND. They are all 328PBs, as they did work initially - and if they were not, then part of the circuit wouldn't work.
07:19 PM cehteh: i meant how did you measure the short
07:19 PM cehteh: and pb's have slight differences to p
07:20 PM Smashcat: Set bench power supply to 100mA output, and connecting MCU pulled it down to zero V. Also, bench multimeter measured 0 ohms between VCC and GND
07:20 PM cehteh: iirc there is some fuckup when you use a board desigend for *p and put a pb in it
07:20 PM Smashcat: Yes I know PBs are different to Ps - I use the PBs for the extra IOs on the board :)
07:21 PM cehteh: i am using pb here too
07:21 PM Smashcat: I always use them now - the cost difference is worth it for the extra peripherals and IOs for sure
07:21 PM djph: lucky you guys :p
07:22 PM cehteh: well there are some fuckups with the PB's you need to be aware
07:24 PM Smashcat: I've noticed an issue with PORTE not returning the correct value when it's set to high input on all pins, then PINE is read. Seems to happen if you do this too quickly after reset.
07:25 PM cehteh: there is this strange clock modulation thing on the new timer and some unlucky choice of pins
07:25 PM Smashcat: I first noticed this when I had PORTE connected to a 4 pin DIP switch. Couldn't work out why I kept getting the wrong value. Adding a short delay fixed it.
07:25 PM cehteh: https://www.pololu.com/file/0J1464/Atmel-42559-Differences-between-ATmega328P-and-ATmega328PB_ApplicationNote_AT15007.pdf
07:25 PM Smashcat: cehteh: Haven't noticed that.
07:26 PM cehteh: 2.3. OCM1C2 - Output Compare Modulator
07:28 PM Smashcat: Yeah I haven't used that peripheral
07:28 PM cehteh: ah and LeoNerd i just read that officially its only up to 16Mhz with quarz .. duh
08:14 PM timemage: Smidge204, not sure what it would have to do with reset, but PORTx goes through a synchronizer before you can read it back on PINx, so if you line the instructions up one right after the other you can fail to read what you wrote.
08:15 PM timemage: erm, well, for smashcat, if he returns anytime soon.