Back
[03:05:08] <cehteh> ㎌
[03:05:12] <cehteh> mmh
[03:19:49] <WormFood> hey, it works
[03:21:11] <cehteh> :)
[03:21:52] <cehteh> just fixed the last glitches on my utf8 lineedit, works with chinese glyphs now
[03:22:08] <cehteh> do you know any 3 or 4 cell wide glyph?
[03:22:49] <cehteh> i havent found any yet which are supported by the terminal
[03:27:41] <WormFood> 不知道
[03:28:07] <WormFood> that means "don't know"
[03:29:48] <cehteh> ok
[03:30:18] <cehteh> possibly not important anyway, should work with anything the terminal supports
[03:30:31] <cehteh> even unprintable chars are handled correctly
[03:31:18] <cehteh> its just a mess that the whole line has to be redrawn in a lot of cases, maybe i can optimize a few things, but not much
[03:31:32] <WormFood> That's cool. How big is your compiled code?
[03:32:19] <cehteh> 6k incl the rest of mµOS
[03:32:54] <cehteh> with lots options for slimming it down, currently i have all bells and whistles on
[03:32:57] <WormFood> Are you going to publicly release your code, when you're done?
[03:33:10] <cehteh> its already public
[03:33:18] <WormFood> github?
[03:33:28] <cehteh> git://git.pipapo.org/muos
[03:33:59] <cehteh> but its still a undocumented mess with a lot things not finished
[03:34:49] <cehteh> http://git.pipapo.org/?p=muos;a=shortlog;h=refs/heads/devel
[03:52:16] <cehteh> so next stop: port to attiny
[03:52:24] <cehteh> well .. later, cu
[05:28:57] <LeoNerd> Gah...
[05:29:19] <LeoNerd> Just after I thought I finally had a good mental model of all the various AVR timers... I read the tiny25/45/85 datasheet about Timer1
[05:29:22] <LeoNerd> It's weeeeird
[05:29:32] <LeoNerd> All the bits are in the wrong place
[05:29:48] <LeoNerd> Literally. The control registers are laid out differently to everything else I know
[05:30:53] <LeoNerd> There's no WGM bits, instead separate CTC and PWM bits. There's no input capture, *but* it has a dedicated CTC value in OCR1C, which doesn't have a corresponding output pin.. it's just for setting TOP
[05:36:41] <Jartza> yeah
[05:36:47] <Jartza> tiny85 is weird chip in many ways :)
[05:36:53] <Jartza> also the 64MHz internal PLL is crazy
[05:37:49] <LeoNerd> Mmm
[05:38:02] <LeoNerd> I wasn't even going to use that bit.. Just in normal sync. mode so I have four PWM channels
[05:38:05] <LeoNerd> Am doing flashy LED effects
[05:40:38] <LeoNerd> Hrm.. Also I don't seem to have any tiny[x]5 chips here.. though I do have a boxful of tiny84s.. maybe I'll use one of those with the timers I already know
[05:40:41] <LeoNerd> and are sensible
[05:42:45] <LeoNerd> "Timer 1 on the ATtiny85 processor is a perfect example. I believe it is unique in the AVR world." --
http://forum.arduino.cc/index.php?topic=163393.0
[05:45:55] <lorenzo> hm?
[05:56:36] <LeoNerd> Of tiny peripherals being weird
[05:56:58] <LeoNerd> Whereas mega ones tend to be more standard between chips
[06:00:30] <lorenzo> ahh
[06:42:19] <LeoNerd> Ohgod it's worse... tiny85's timer1 *has* CTC logic in the OCR1C register, but there's no corresponding interrupt for it
[07:18:38] <nikomo> Made a synchronous buck converter with tiny85, on breadboard. I had to drop down switching freq to 8kHz, the inductor got really hot, and the switching node kept goint past 20V (with 12V input into system)
[07:20:57] <nikomo> Jartza: the PLL isn't crazy, it's useful :P
[07:23:50] <Jartza> I've made boost converter out of attiny85 :)
[07:24:10] <flyback> uh
[07:24:21] <flyback> if the inductor is getting hot, something is CANUCKED
[07:24:41] <LeoNerd> Yesterday I looked at a nice ON Semiconductor chip for doing boost/buck/etc.. converters nicely
[07:24:54] <LeoNerd> 34063. Just use one of them :)
[07:24:56] <flyback> cool idea though
[07:25:27] <flyback> nikomo might be really good for wildly varying load conditions where a normal smps controller is going to panic
[07:26:40] <flyback> im going to have to study a lot of linear reg fu for some low end wind power projects
[07:27:07] <flyback> hmm thx nikomo you gave me an idea
[07:27:55] <flyback> guess I could use a linear reg and a large cap to compensate for wildly varying input power to keep the mcu for smps stable
[07:28:14] <flyback> then I could have the efficiency of smps
[07:40:00] <nikomo> you can do it with one pin easily. even synchronous. so that's nice.
[07:43:19] <flyback> heh with a mcu you could do 3 phase syron like from a stepper motor windmill]
[07:43:52] <flyback> \however since this is all 3rd world idea I probably can't even use a mcu easily but I have ideas about that
[07:44:26] <flyback> might use a 8051 since you can find them in old keyboards, optical drives etc
[07:46:02] <nikomo> where are you working that requires scanvenging like that? takes a bit of work, but I imagine it's worth it
[07:47:04] <flyback> im just thinking about people in remote areas etc
[07:47:09] <flyback> that don't have reliable power etc
[07:47:29] <flyback> you can generate a few watts from stuff in the trash easily
[07:49:57] <nikomo> do I remember correctly that ADC was a macro in avr-libc that would just read the 10bits from the ADC for you?
[07:50:25] <nikomo> I don't think that's documented anywhere, but it works
[07:56:12] <twnqx> reminds me i need to build a smps :P
[07:56:55] <twnqx> and not a cute easy DC-DC one
[07:57:26] <nikomo> I was looking online for buck converters that would go down from 24v or 48v, but I didn't really like anything I saw on the cheap end
[07:57:47] <nikomo> output is also fairly trivial to modify when it's just a register in your micro
[07:58:19] * twnqx grabs can controller board
[07:58:35] <twnqx> dang, can't read in this light
[07:58:45] <twnqx> TI LM5001
[08:00:00] <twnqx> 3.1 - 75V -> 5V (in my setup :P)
[08:01:57] <nikomo> kinda weird
[08:02:11] <twnqx> SEPIC topology. can go up or down as needed.
[08:02:17] <nikomo> where are you getting 3.1v from, and where do you need 75v
[08:02:43] <twnqx> i might have 3.8 or so worst case on the far end of a USB power + diode drop
[08:03:16] <twnqx> target voltage is 13.8V mainly (car electric), but that can have... spikes
[08:03:27] <twnqx> so i wanted something that just tolerates 65V peaks :P
[08:03:50] <twnqx> or 13.2 or whatever they use
[08:06:20] <twnqx> mainly, i wanted usp power and/or car battery power, and "a bit" headroom for resilience
[08:06:23] <twnqx> usb*
[08:07:34] <twnqx> reminds me i need to order a certain capacitor again...
[08:07:36] <nikomo> I just realized I had my PLL lock reading logic backwards, that's why the code never started executing, it was waiting for PLL to start up forever
[08:07:36] <twnqx> i c1
[08:07:57] <nikomo> I just ripped it out and waited for 100ms because I cba looking at it lol
[08:08:05] <nikomo> so I didn't bother thinking what was wrong
[08:13:15] <nikomo> I added in feedback via ADC, it's actually kinda ok now I think
[08:13:32] <nikomo> I mean the inductor still heats up way too much etc., but it's not bad for breadboard contraption
[08:22:10] <flyback> twnqx, you need to do 75v to 5
[08:22:24] <flyback> probably can use a old pc smps controller
[08:22:29] <flyback> like a tl494
[08:22:48] <flyback> but there's more modern shit that's better
[08:22:52] <flyback> a topswitch might work
[08:23:02] <nikomo> ~280mA of load at 3.1V output, and it seems stable
[08:23:03] <nikomo> neat
[08:24:10] <nikomo> after fingertip testing, inductor doesn't seem to heat up with higher PWM freq either
[08:48:31] <grafi_> Can endianness be completely configured in the compiler?
[08:48:58] <grafi_> I'm working with an AVR32, that uses big-endian as default
[08:49:24] <LeoNerd> Not really.. the trouble is all the >8bit hardware registers in timers, ADC, etc...
[08:56:27] <grafi_> I see
[09:18:56] <grafi_> Since it's so quiet here atm.. What does 1 wait state mean?
[09:19:29] <grafi_> I read that the avr needs to use 1 wait state if I'm going to use the highest clock frequency
[11:29:15] <daey> grafi_: you mean the wait time during bootup?
[13:56:44] <julius> hey
[13:57:12] <julius> im still traumatized from killin that 168, bluetooth module and led yesterday....i dont think i can go on
[14:02:27] <RikusW> oops
[14:02:51] <RikusW> I killed a mega32L once because of a faulty psu :/
[14:03:17] <LeoNerd> I killed an IO pin on a PIC16F84 once, probably handling static
[14:03:22] <LeoNerd> I've yet to blow up any AVR chip
[14:03:43] <LeoNerd> Oh except a tiny84 I think I probably grounded every single IO pin at once via a faulty nRF radio
[14:03:44] <LeoNerd> .. yeah that
[14:03:49] <LeoNerd> Made the case physically crack
[14:04:11] <RikusW> and let the magic smoke out ?
[14:04:35] <LeoNerd> I can't imagine a SOIC-sized ATtiny containing more than a reeeeally teeenytiny amount of smoke
[14:04:59] <RikusW> the epoxy can produce a bit
[14:05:25] <RikusW> enough to produce the expensive smell
[14:21:47] <Chillum> LeoNerd: ohh they can make a lot of smoke
[14:22:10] <Chillum> not as much as a larger chip, but a surprising amount
[14:22:39] <LeoNerd> Mine just made a little tiny crack noise
[14:22:49] <Chillum> luck of the draw
[14:22:52] <Chillum> I reversed the polarity
[14:23:26] <Chillum> and did not notice for a while
[14:29:13] <RikusW> You should load some in the Chillum next time :-P
[14:29:45] <RikusW> though I doubt epoxy smoke is healthy...
[14:29:52] <Chillum> Good idea, I need to relax. Just finished building my racing quad and flew it for the first time, I feel like a kid with too much sugar!
[14:30:05] <Chillum> sooooooo fun
[14:30:13] <RikusW> (some tinys I meant :-P )
[14:30:22] <Chillum> I have a better plan
[14:30:56] <RikusW> which is ?
[14:48:45] <RikusW> Chillum: After go listen to Dota
[15:18:06] <applepi> Hi all. I'm trying to write an i2c driver for an atmega128rfa1, and write seems to be working fine, but for some reason when I try to read, after sending the read address, the bus never seems to get released for the slave to respond.
[15:18:16] <applepi> DigiView capture here:
http://imgur.com/a/xYdco
[15:20:23] <applepi> It goes off into this weird nevernever land, the clock isn't even going, so I can't get anything back.
[15:22:03] <cehteh> sounds like a bug :D
[15:27:34] <applepi> Well, yes. I was hoping someone might have a suggestion as to why it might be getting hung :P
[15:28:05] <applepi> Any registers or bits that could cause it to get that way, etc?
[15:29:05] <cehteh> no idea, must be some bug in your code, missing some release or doesnt complete sending the read address completely or checksum error or whatever
[15:29:16] <julius> mine did not smell or make a noise at all...but im pretty sure i switched + and -
[15:29:22] <julius> could it still be alive?
[15:29:46] <cehteh> the avr? the bluetooth? the led?
[15:29:59] <julius> the led is dead
[15:30:01] <cehteh> led should be fine :D
[15:30:08] <cehteh> that would be strange
[15:30:13] <julius> tried another power supply, no light
[15:30:51] <cehteh> led is a diode, they dont really like reverse operation but normally they should survive that, you had a resistor in series?
[15:32:25] <applepi> I can't even send an STOP condition after I send the read address, it just gets perma-stuck. Like even if I try just writing SLA+R then STOP, I get the same result.. surely I have to be missing setting flag?
[15:43:41] <grafi_> "In AT32UC3A, what is the typical last instruction to be executed right before the assembly program jump to a different function?" - does this question make any sense?
[15:47:22] <cehteh> no
[15:47:42] <cehteh> assember has no ABI, whatever works is legit
[15:48:28] <grafi_> ok, good, thanks
[15:48:50] <cehteh> test question?
[15:49:12] <grafi_> yep
[15:49:47] <cehteh> possibly expects an answer like 'loading the address where to jump to ..
[15:50:02] <cehteh> but till awkward test asking such billshit
[15:50:10] <cehteh> bullshit
[15:52:22] <RikusW> call maybe ?
[15:53:09] <Jartza> or rcall :)
[15:53:26] <RikusW> Hi Jartza
[15:53:37] <RikusW> still using U2S ?
[15:53:42] <Jartza> sure
[15:53:43] <Jartza> works fine
[15:53:56] <Jartza> no complaints :)
[15:54:00] <RikusW> :)
[15:57:18] <Jartza> RikusW: I got the lufa avr isp mk2 firmware for it and it's been working great ever since
[15:57:35] <RikusW> how is pdi working ?
[15:58:00] <RikusW> or not tested yet ?
[15:58:47] <RikusW> have you changed the default mode to app-nousb ?
[16:03:31] <cehteh> is there any code around to make a tiny85 a ISP with vusb on the input side?
[16:04:02] <Jartza> PDI works just fine
[16:04:11] <Jartza> haven't had any problems
[16:05:26] <RikusW> so you loaded the lufa mk2 with the u2s bootloader ?
[16:05:31] <cehteh> hah .. i just found some articles how to flash an tiny with a isp with RSTDSBL fuse set
[16:05:52] <cehteh> power it below brownout voltage to keep it in reset, then you can connect a isp
[16:06:03] <cehteh> crazy
[16:06:23] <RikusW> heh
[16:06:30] <RikusW> interesting
[16:06:43] <RikusW> LV vs HV programming :-P
[16:07:16] <RikusW> and hope the brownout is high enough to allow programming
[16:07:23] <cehteh> yes
[16:07:40] <cehteh> well you can set the brownout detector somewhat high
[16:08:01] <RikusW> if you planned ahead..
[16:08:29] <Jartza> RikusW: yes, lufa mk2 with u2s bl
[16:08:30] <RikusW> if its already bricked there is no way to know what its set at
[16:08:32] <cehteh> when you set the RSTDISBL fuse you *should* plan ahead :D
[16:08:51] <cehteh> but tiny85 also works fine with bootloader
[16:09:09] <RikusW> Jartza: did you change the default mode ? so you don't have to fiddle with the buttons each time ?
[16:09:17] <Jartza> no
[16:09:33] <Jartza> but I don't find it too tedious as it's connected all the time to my usb-hub :)
[16:09:35] <RikusW> load the app_nousb eep file with the bootloader
[16:09:59] <RikusW> lufa don't need the usb code in my bootloader
[16:10:23] <Jartza> mm, okay
[16:10:34] <Jartza> I'll try that at some point :)
[16:11:54] <RikusW> /AVR_U2S_20111022/U2Settings/U2Settings_APP_NoUSB.eep from
https://sites.google.com/site/megau2s/home/supporting-software/AVR_U2S_20111022.tbz?attredirects=0&d=1
[16:12:46] <Jartza> thanks, I download it waiting :)
[16:13:07] <RikusW> 48kb...
[16:13:16] <Jartza> yeah, noticed, that was quick
[16:13:38] <RikusW> s/quick/click ;)
[16:14:00] <cehteh> oh ultralowpower ... use the 128khz osc and highest clock prescaler ... run tiny at 500Hz clock
[16:14:48] <Jartza> cehteh: yes, that's quite fun :)
[16:15:02] <cehteh> just needs some application where it makes sense
[16:15:08] <RikusW> Jartza:
https://sites.google.com/site/megau2s/home/supporting-software/u2scli.tbz?attredirects=0&d=1 it may or may not compile on mac, works on linux
[16:15:27] <cehteh> i mean i use the 128khz osc for my battery watchdog .. but clkdiv=1 then
[16:15:30] <RikusW> commandline tool to change the modes
[16:15:45] <Jartza> ahh. I'll give it a try
[16:15:58] <RikusW> not sure about the serial stuff on mac though
[16:16:16] <Jartza> me neither :)
[16:16:22] <cehteh> and i wonder if avrs have also this run-to-idle thing .. better choose a higher clock and then you can sooner go into sleep conserving even more power
[16:17:12] <cehteh> current consumption looks quite linear on the datasheets
[16:18:52] <Jartza> well
[16:18:55] <Jartza> doesn't compile as-is
[16:18:55] <Jartza> RCom.cpp:101:20: error: use of undeclared identifier 'B460800'
[16:20:09] <RikusW> yep, the serial stuff...
[16:20:11] <Jartza> LOL
[16:20:19] <Jartza> osx only defines speeds up to 230400
[16:21:11] <RikusW> does osx actually support termios ?
[16:22:20] <RikusW> I'll rather use libusb than termios :/
[16:22:30] <Jartza> well it has libusb
[16:22:30] <RikusW> much easier and more consistent
[16:23:01] <RikusW> my u2s use CDC, so its serial for compatibility
[16:23:40] <RikusW> if it could be unlinked from the CDC driver somehow libusb could be used
[16:27:04] <Jartza> well. it compiled when I dropped speeds >230400
[16:27:11] <Jartza> but how to use it? :9
[16:29:43] <RikusW> u2scli 80 or 81 etc
[16:30:09] <Jartza> Setting mode to 80
[16:30:09] <Jartza> spd = 115200 = 115200
[16:30:09] <Jartza> bits = 8N1 = 300
[16:30:12] <RikusW> can't remember it it should be 0x80
[16:30:38] <RikusW> the 0x80 is for the builtin modules
[16:30:40] <Jartza> well, giving 0x80 at command line sets the mode to 00 :D
[16:32:40] <RikusW> so use 80 arduino bl 81 bootloader 82 stk 83 jtag 84 uart
[16:32:53] <RikusW> 80 will do a timeout and jump to mode 0
[16:33:10] <RikusW> modes 00 - 0F will pass the value to the app
[16:34:00] <RikusW> 85 and up is not defined yet, though 85 is for the still nonexistent dW module....
[16:34:16] <Jartza> okay
[16:34:42] <RikusW> basically an autobauding soft uart that goes up to 250kbps
[16:34:48] <Jartza> cool
[16:35:03] <RikusW> its a bit tight at 16MHz
[16:35:11] <Jartza> I bet :)
[16:36:52] <RikusW> and it must handle some dW stuff+buffering as well to prevent usb slowing down everything
[16:37:10] <Jartza> well, the u2scli seems to work
[16:37:26] <RikusW> nice! :) didn't expect it to
[16:37:28] <Jartza> just not the high speeds
[16:37:39] <Jartza> or well. the defines aren't that magical
[16:37:50] <Jartza> #define B460800 460800
[16:37:50] <Jartza> :P
[16:37:51] <RikusW> its CDC so it doesn't matter, baud is irrelevant
[16:37:59] <Jartza> yea
[16:38:19] <Jartza> works just fine with mac
[16:38:32] <RikusW> I did the RCom module for easy serial access on both windows and linux
[16:38:42] <Jartza> although the default port seems to be /dec/cu.usbmodemU21
[16:38:47] <RikusW> great to know it works on mac
[16:39:07] <RikusW> ttyACM0 on linux
[16:39:09] <Jartza> it works, just not the B460800 and B921600
[16:39:14] <RikusW> COM3 or so on windows
[16:39:32] <RikusW> I don't think those are even available on most serial ports
[16:39:33] <Jartza> I just #if 0:ed them out
[16:40:34] <RikusW> Jartza: 41 is the mode to prevent the u2s turning on its usb code
[16:40:46] <Jartza> ok
[16:40:58] <Jartza> though I don't find this being a problem :)
[16:41:11] <RikusW> seems lufa reinit it anyways
[16:41:25] <RikusW> some code don't
[16:41:31] <Jartza> yea
[16:41:46] <Jartza> but it works for me, so currently I'm not going to break it :)
[16:42:17] <RikusW> seems you're doing a burn-in by leaving it connected :-P
[16:42:34] <Jartza> hehe yea :)
[16:42:39] <Jartza> my mac is also on 24/7
[16:42:50] <Jartza> and I have 2 seven port USB3 hubs :P
[16:43:00] <Jartza> also powered with external supply
[16:43:11] <RikusW> and how many devices connected ?
[16:43:12] <Jartza> there's never enough USB ports
[16:43:20] <Jartza> currently only 9
[16:43:48] <RikusW> I only have 2, mouse and keyboard right now, and an A-B cable on another port
[16:44:44] <RikusW> I do have a A4 scanner, and had a laser printer which I sold to my mom
[16:44:57] <Jartza> usbasp, 3 ftdi cables (2 * 3.3V and one 5V), printer, u2s, arduino, segger jtag and flyswatter jtag :)
[16:45:19] <RikusW> Was used for printing pcb masks, but I didn't make a lot
[16:45:37] <nikomo> anyone know what file in avr-libc defines the ADC macro? I'll probably go insane if I try to grep around for "ADC"
[16:45:40] <Jartza> but when playign with more arm-stuff, then moar usb-ports in use because I mainly use those nucleo boards for my own stuff
[16:45:51] <Jartza> currently also lot of customer devboards here
[16:46:19] <julius> cehteh, you were right. the led survived the +/- debacle
[16:46:22] <RikusW> buy another hub :-P
[16:46:43] <julius> even the bluetooth module is at least blinking happily...cant test at the moment
[16:47:04] <RikusW> my PC got 10 usb ports, 3 are usb3
[16:47:12] <Jartza> nikomo: io.h
[16:47:19] <Jartza> but it loads your MCU specific file
[16:48:35] <Jartza> nikomo: so I would look under avr/include/avr/iotnx5.h
[16:48:39] <nikomo> Jartza: I just checked the MCU specific file (iotn85.h) and it's not there either
[16:48:56] <nikomo> only line containing ADC is #define SLEEP_MODE_ADC (0x01<<3)
[16:49:11] <Jartza> check iotnx5.h
[16:49:48] <nikomo> ah
[16:50:38] <Jartza> they are separated into tiny x5 (25, 45, 85) specific AND mcu specific on top of those
[16:51:31] <nikomo> ... what's an SFR?
[16:51:57] <nikomo> ah
[16:52:03] <nikomo> special function register
[16:52:41] <Jartza> yes
[16:52:45] <Jartza> it's just a memory offset
[16:52:54] <Jartza> because those IO-registers are SRAM as well
[16:53:01] <Jartza> and your "real" sram begins after them
[16:53:57] <Jartza> they are in avr/include/avr/sfr_defs.h
[16:54:44] <nikomo> ADC is just defined as SFR, I just wanted to see how it's defined so I know if I need to check for ADC conversion being finished myself (answer: yes)
[16:55:15] <cehteh> ook .. porting mµOS to tiny85, micronucleus boot loader .. it compile, flashes,
[16:55:26] <cehteh> ... but doesnt work (led blinking :D)
[16:56:01] <Jartza> nikomo: I bet it's defined as _SFR_IO16 ?
[16:56:06] <nikomo> Jartza: yes
[16:56:10] <Jartza> which is most probably _MMIO_WORD
[16:56:25] <Jartza> which is just (*(volatile uint16_t *)(mem_addr))
[16:56:26] <Jartza> :)
[16:56:34] <Jartza> so 16 bit memory access
[16:56:43] <nikomo> I just realized I can skip uint16_t adc_result = ADC; not sure why I did that
[16:57:30] <Jartza> cehteh: what's mµOS?
[16:57:58] <cehteh> the schedler thing i am workin on
[16:58:15] <Jartza> oh... mmkay
[16:58:19] <Jartza> multithreading?
[16:58:59] <cehteh> no threads, queues of functioncalls
[16:59:06] <cehteh> going easy on the stack
[16:59:06] <nikomo> Jartza: doing uint16_t blah = ADC; and if'ing against that, instead of comparing against ADC, saves 2 bytes space o_o I don't get it
[16:59:09] <Jartza> ahh
[16:59:28] <nikomo> time to disasm I guess, sigh
[16:59:34] <cehteh> needs only a few bytes ram and around 1k flash
[16:59:41] <Jartza> yea
[16:59:51] <Jartza> I did multithreading led blinker for attiny85 :)
[17:00:01] <Jartza> very very very very basic one
[17:00:01] <cehteh> yeah
[17:00:20] <cehteh> i want it useable and generic, more than just blinking leds :)
[17:00:33] <cehteh> threads are to heavy for the stack
[17:00:49] <Jartza> I think it was this
https://gist.github.com/Jartza/3b869fa4b6a4afcc19b2
[17:00:55] <nikomo> multithreading, aka you save stack somewhere etc.? I imagine a task queue, like cehteh's, would be better on something like the t85
[17:01:06] <Jartza> nikomo: of course they are better
[17:01:13] <Jartza> especially when AVR has gazillion cpu registers
[17:01:32] <Jartza> but yes. stack switching multitasking blinkenlights
[17:01:34] <Jartza> just because
[17:01:47] <nikomo> then again, you do have a tendency to do completely insane stuff for funsies so
[17:01:48] <Jartza> but very quick'n'dirty
[17:01:58] <Jartza> indeed, for funsies
[17:02:59] <Jartza> but yea. task switching on avr has huge CPU hit and memory hit
[17:03:07] <cehteh> my stuff is a bit more elaborate :D .. priority queue for timer tasks, normal queues for high/low priority tasks
[17:03:12] <Jartza> it's ok if you switch task like 50 times a sec
[17:03:27] <Jartza> cehteh: yeah. that's the way to go on small memory system.
[17:03:45] <cehteh> priority queue with a sliding window implementation
[17:03:52] <Jartza> I actually made this blinkenlight just because I was explaining task switching to someone
[17:04:14] <Jartza> so it was easier to explain with an example
[17:05:38] <cehteh> ok .. led turns on .. i guess just compiling the timer code which was made for 328p to tiny85 isnt all .. needs some adjustments
[17:05:42] <cehteh> ah ISR's :D
[17:06:09] <Jartza> oh yea. attiny85 timers are the black sheep of avr family :D
[17:06:09] <cehteh> wherent they named differently on the tiny
[17:06:17] <Jartza> that too
[17:06:42] <cehteh> well i have some little HAL .. more like preprocessor macros which generate the names
[17:07:12] <cehteh> just fix that up, just started to port it to tiny so having it compile without errors is already a good start at first
[17:08:01] <nikomo> I kinda like the tiny85 timers though. though if I remember correctly, timer0 couldn't do PWM with complement on second pin, but that's not strictly necessary
[17:08:41] <nikomo> I've never actually properly used a 328 really yet, the t85 is so nice. especially now that I have my own small board I can just stick on the breadboard and connect the programmer
[17:08:42] <cehteh> yes the tinys are somewhat cool
[17:08:51] <cehteh> thats why i want to port my code there
[17:09:12] <cehteh> after that tiny84
[17:09:22] <cehteh> and some day stm32
[17:09:44] <nikomo> if they made like a t165, I'd be totally ok with that. double the flash, 4x the RAM, and you've got a pretty big beast on your hand
[17:10:01] <nikomo> that'd probably be a way bigger die though
[17:10:23] <Jartza> nikomo: have you checked t1634?
[17:10:30] <nikomo> I have not
[17:10:37] <Jartza> "tiny" :D
[17:10:52] <nikomo> yeah I noticed they have weird definitions for "tiny"
[17:11:08] <nikomo> ... 20pins, tiny? really?
[17:11:16] <Jartza> it's not weird. if core doesn't have mul, it's tiny
[17:11:20] <nikomo> man that's a lot of ADC
[17:11:27] <Jartza> yes. and 16kB of flash.
[17:11:38] <cehteh> someday i want to be at the point where from the idea of a project to the implementation is only a few hours or days
[17:11:49] <Jartza> another very very cool chip is attiny88
[17:11:53] <nikomo> double the SRAM
[17:12:01] <Jartza> costs like nothing
[17:12:14] <Jartza> 32 pin tqfp / qfn
[17:12:28] <cehteh> yes thats the unfriendly thing for quick and dirty hacks
[17:12:28] <Jartza> oh, I think qfn was 28 pins
[17:12:47] <nikomo> good thing corecode isn't here or he'd just be yelling omg just use arm already, at me
[17:15:13] <Jartza> lol
[17:15:30] <Jartza> I like arm too. but for small things they are often too tedious
[17:15:46] <nikomo> to be honest I really need to get on that, the timers on even the most basic chips are so good, I think I'm going to need to use one for what I want to do next
[17:16:29] <LeoNerd> the 1634 is the biggest "tiny" chip I know of
[17:16:45] <LeoNerd> 17 GPIOs, 5(!) timers, 2 UARTs, 16Ki flash, ...
[17:16:50] <Jartza> yep
[17:16:51] <Jartza> tiny
[17:16:55] <LeoNerd> "tiny"
[17:17:14] * LeoNerd considers "scumbag Atmel" meme picture
[17:17:25] <Valen> USE ALL THE TIMERS!
[17:17:42] <LeoNerd> Could be useful for big LED controllers
[17:17:50] <LeoNerd> Each timer likely has 2 channels, so that's 10 PWM pins
[17:26:03] <nikomo> just checked the frequency for PWM if you do 16bit resolution with a 100MHz timer. slightly less impressive than I was hoping, but who really needs full 16bits
[17:42:22] <grafi_> What peripheral/hardware would you use to measure the duty cycle of an external digital waveform?
[17:42:22] <LeoNerd> Oscilloscope?
[17:42:23] <grafi_> Interrupt?
[17:42:23] <grafi_> Oscilloscope is a good suggestion, buut I have to use an AVR
[17:42:24] <nikomo> it's a square wave?
[17:42:25] <grafi_> I'm assuming that since its digital
[17:42:25] <Jartza> it's never digital ;)
[17:42:25] <nikomo> if it's a square wave that goes between digital low and digital high, that's probably nice. analog would involve adc which would be bad.
[17:42:26] <nikomo> Jartza: everything is digital if you don't look at it too closely
[17:42:26] <grafi_> I was thinking of using a timer to read a pin?
[17:42:26] <nikomo> you could have an interrupt and then time how long it stays high/low etc.
[17:42:27] <grafi_> I can only choose between INTC, EIC, ADC and TC. EIC was the first that came in mind
[17:42:28] <Jartza> what avr that is?
[17:42:29] <grafi_> AVR32
[17:42:52] <Jartza> EIC sounds like external interrupt controller
[17:43:31] <grafi_> Yep, it is
[17:43:37] <Jartza> so, I think I would check if EIC can be launched on pin change
[17:43:40] <Jartza> meaning, both edges
[17:43:52] <grafi_> good idea!
[17:44:01] <Jartza> then just run some timer fast enough and in the interrupt check the time elapsed since last fire
[17:44:15] <Jartza> and of course reset the counter value in the interrupt
[17:44:46] <Jartza> and of course read the pin state inside interrupt so you see when it is high and when it's low
[17:44:52] <Jartza> easy enough to calculate duty cycle from that
[17:45:40] <grafi_> thanks!
[18:10:22] <cehteh> oh ... it works! was only the ISR names TIMERx.._vect vs TIMx.._vect
[18:11:17] <cehteh> i wonder whats the reason behind naming the ISRs differently
[18:12:18] <Jartza> dunno. haven't ever checked.
[18:13:03] <Jartza> maybe the reason that tinys don't have the bootloader section and the interrupt vectors are always in one place
[18:13:14] <Jartza> whereas megas have several placement options for those
[18:13:27] <Jartza> but this is purely guessing, don't know
[18:13:48] <cehteh> even then the name would be purely cosmetic
[18:13:56] <Jartza> true
[18:13:56] <cehteh> text data bss dec hex filename
[18:13:56] <cehteh> 1508 0 63 1571 623 example.elf
[18:14:16] <Jartza> also some megas have 4 byte vectors
[18:14:33] <Jartza> tinys have only 2 byte per isr iirc
[18:14:37] <cehteh> yes
[18:14:46] <cehteh> but still name is only cosmetic :D
[18:14:58] <Jartza> yep.
[18:15:21] <cehteh> maybe they want to differ for compat reaons .. or just hysteric rasins
[18:15:23] <Jartza> but less ifdeffing in code :)
[18:16:02] <cehteh> yes its bit ugly what i do with the cpp there
[18:16:20] <cehteh> tinys have TIMSK while megas have TIMSK0 and TIMSK1 too
[18:18:06] <LeoNerd> tinys tend to more densely pack control bits into bytes of IOcontrol registers, whereas megas spread them out more leaving gaps for future expansion
[18:18:28] <LeoNerd> The tiny USI module has not a single spare bit left. Which means my wish for endian control will likely not happen :(
[18:19:23] <cehteh> shifting is done in hardware, so that would need some more changes
[18:19:42] <LeoNerd> I just want a 2x2 crossbar switch on the ends
[18:19:56] <LeoNerd> The DI / DO pins are hardwired to the LSB and MSB of the shift register
[18:20:19] <LeoNerd> I'd just put a little switchable crossover in there, so if you swap the ends you get reversed endian
[18:20:25] <LeoNerd> Thus making it a little easier to use USI as a UART
[18:20:50] <cehteh> yes
[18:20:54] <LeoNerd> Oh though I suppose it needs to shift the other way too
[18:20:54] <LeoNerd> hmm
[18:21:36] <cehteh> i wonder how atmel designs chips .. on demand for big users? or do they guess what the market wants?
[18:22:16] <cehteh> they certainly have a lot functional blocks they could put together for some design
[18:25:24] <Chillum> /join #multirotors
[18:25:26] <Chillum> oops
[18:25:45] <cehteh> mhm
[19:20:33] <Evidlo> Is it bad to put a lot of stuff in my ISR if there's nothing in my main loop?
[19:21:24] <Evidlo> I need to crunch some numbers every time my ADC takes a sample
[19:25:40] <LeoNerd> I'd move it to main loop
[19:25:49] <LeoNerd> Adopt a tasklet style
[19:28:07] <Evidlo> so set a flag in the ISR and check for it in the main loop?
[19:28:14] <LeoNerd> Ya
[20:16:31] <cehteh> Evidlo: dont forget that callin an ISR wakes the cpu from sleep, i am just have an EMPTY_INTRERUPT() by timer here which wakes the mainloop which in turn does the work
[20:17:30] <cehteh> same for other interrupts, like uart etc. just keep them as small as possible, do the most work on queues from the mainloop
[20:19:07] <julius> i2c_retry: <- this on a single line, what is it?
[20:19:54] <julius> i mean in general
[20:20:00] <Evidlo> cehteh: Does the main loop resume from where it was after an interrupt?
[20:20:03] <julius> not what it does in a i2c context
[20:20:12] <julius> yes evi
[20:21:14] <Evidlo> ah cool, I'm able to do that entire computation at almost 12KHz. that means I should be good for 9600 samples/sec
[20:21:34] <cehteh> julius: label for goto to jump tp
[20:21:52] <cehteh> Evidlo: yes
[20:24:25] <cehteh> ++OSCCAL;
[20:24:29] <cehteh> ... ahaha fun
[20:25:11] <Evidlo> cehteh: can you explain why my loop slows down to exactly 8KHz (2x adc freq) when I enable interrupts?
https://dpaste.de/2Ey3
[20:25:33] <cehteh> interrupts taking time
[20:25:54] <Evidlo> But why is my main loop exactly 8KHz? I would expect it to be some random number below 12KHz
[20:27:54] <cehteh> why should it be random?
[20:28:31] <Evidlo> cehteh: not random every time, just some value due to computation time + interrupt time
[20:28:43] <cehteh> which is still deterministic
[20:29:08] <cehteh> btw .. throw first reads away .. and start adc/interrupts after you configured the ADC not before
[20:29:10] <Evidlo> But it doesnt make sense that it is exactly 4KHz. It was almost 12KHz from only computation time
[20:30:50] <Evidlo> also that implies that (interrupt + computation) is 3x longer than just computation
[20:31:11] <cehteh> in your case maybe you forget about interrupts and do all in one main loop, busy wait on the ADC
[20:31:36] <cehteh> generally not a recommended practice but your µC should do only one simple thing
[20:32:26] <cehteh> you dont care much about the speed its running, you only want to decode bits and set a output accordingly
[20:33:04] <Evidlo> I need to sample at a specific rate
[20:33:37] <Evidlo> and a synced output means the output bits will probably be less jiterry
[20:34:18] <cehteh> yes, there are these 2 approaches
[20:34:28] <cehteh> will do to
[20:36:12] <cehteh> btw: PORTB ^= 1<<PB2; -> PINB = 1<<PB2;
[20:36:23] <cehteh> toggles output in hardware w/o reading it first
[20:37:38] <Evidlo> interesting, thanks
[20:38:10] <cehteh> when you disable interrupts how fast does your mainloop run then?
[20:38:41] <Evidlo> 11.8KHz square wave
[20:39:31] <cehteh> note that ISR's have some weight, 6cycles alone for calling the interrupt, then the code pushes registers on the stack, and then *your* ISR code gets executed .. and finally things get popped from the stack and the isr returns
[20:39:43] <Evidlo> but when I enable it, it ends up being a rectangle wave at exactly 8KHz
[20:39:56] <cehteh> with a small mainloop like yours that may make already the difference
[20:41:02] <cehteh> and you should use a bool or uint8_t for the adc_ready flag .. int is 16bit
[20:41:44] <cehteh> in other places too and esp for arithmetic when you want to do arithmetic in 8 bit you have to do a lot nasty casts
[20:41:57] <cehteh> dump the assembler gcc generates and check
[20:42:51] <Evidlo> I first need to figure out why my main loop is running at the same frequency as the ADC
[20:43:08] <Evidlo> I'm never checking if the ADC is ready
[20:44:12] <Evidlo> the only thing I can imagine is if the interrupt somehow resets the main loop
[20:45:01] <Evidlo> because then if the loop runs at say 2.638x the speed of the ADC, it would get floored and the output would toggle at 2x the speed
[20:45:21] <cehteh> mhm
[20:45:38] <Evidlo> I think thats what happening. I made my loop a bit longer and it jumped down to exactly 4KHz
[20:45:48] <cehteh> looks more like a coincodence to me
[20:46:00] <cehteh> just add some delay into the mainloop and see
[20:46:11] <Evidlo> read what I just said
[20:46:41] <cehteh> ah
[20:46:42] <cehteh> yes
[20:46:44] <cehteh> so ok
[20:46:56] <cehteh> and you need to be bit more sparse with 'volatile'
[20:47:25] <cehteh> try to make the loop even more longer
[20:47:30] <cehteh> or little less
[20:47:48] <Evidlo> if I make it too long, it might never toggle the pin
[20:47:56] <cehteh> why not?
[20:48:05] <cehteh> there is no conditional
[20:48:15] <Evidlo> because the interrupt would reset it before it got to the bottom
[20:48:15] <cehteh> you have a bootloader?
[20:48:29] <cehteh> your interrupt doesnt reset any pins
[20:48:32] <Evidlo> I don't think so. just using a makefile with avrdude
[20:48:47] <cehteh> ok
[20:49:15] <cehteh> i have some suspiction: could it be that something crashes and the chips is constantly resetting and starting anew?
[20:49:50] <cehteh> w/o bootloader that would match your description
[20:49:52] <Evidlo> but why would disabling the interrupt cause it to not crash?
[20:50:21] <cehteh> yes weird
[20:50:49] <cehteh> well i havent looked that closely, i'd think the code looks somewhat ok except for the things i mentioned
[20:51:47] <cehteh> but you saied when you make the loop much longer the pin never gets toggled .. thats definately wrong
[20:51:58] <Evidlo> I haven't tried that yet
[20:52:22] <Evidlo> I made it 2x as long and it ran at 4KHz
[20:52:54] <cehteh> if it first runs at 8khz then twice as long would run at 4khz .. no wonder
[20:53:14] <cehteh> make it 1.33 times as long and see
[20:53:48] <cehteh> and except for adc_ready remove the volatiles
[20:54:06] <cehteh> ..then it will look differently :D
[20:54:40] <Evidlo> When I say it is exactly 4KHz, I mean it is exactly 4.00KHz. Even adding a delay of 1ms or 2ms doesn't change the speed
[20:54:43] <cehteh> and the blogpost you've shown didnt he used rotates as well?
[20:55:08] <cehteh> delay by what?
[20:55:34] <cehteh> are you sure the delay is correctly rigged (F_CPU set)
[20:56:17] <cehteh> there is no code which syncs the adc with the mainloop ..
[20:56:26] <Evidlo> I added _delay_ms(1) and it is still toggling at 4KHz. F_CPU is 8000000 and I reflashed the chip to be 8MHz
[20:57:10] <cehteh> thats strange
[20:57:39] <Evidlo> If I move _delay_ms to above the pin toggle, it doesnt ever toggle
[20:57:49] <Evidlo> so the main loop is resetting like I thought, or crashing
[20:58:18] <cehteh> wrong compiler flags?
[20:58:38] <cehteh> is your ISR routine wrongly set up?
[20:59:15] <Evidlo> No, I can move the pin toggle to the ISR and it toggles at 4KHz
[21:00:00] <cehteh> hah
[21:00:07] <cehteh> i found the bug :D
[21:00:27] <cehteh> it resets because of illegal interrupt
[21:00:31] <cehteh> TIMSK |= (1 << OCIE0A);
[21:00:47] <cehteh> you enable compare match interrupts but dont have a handler
[21:01:56] <cehteh> btw iirc there is some way to start the ADC by timer w/o interrupt .. hardware does that rtfm
[21:02:39] <Evidlo> yeah that fixes my main loop
[21:03:13] <Evidlo> 11.8KHz again, so it appears the ADC time is negligible
[21:04:13] <Evidlo> Ok, time to read some ADC documentation
[22:32:56] <Evidlo> Is this the correct way to check if the ADC is ready? (ADCSRA>>ADIF)%2
[22:34:32] <Casper> why not (ADCSRA & (1<<ADIF)) ?
[22:35:32] <Evidlo> Actually shouldn't it be ~(ADCSRA & 1<<ADIF)
[22:35:39] <Evidlo> the datasheet says a 1 clears it
[22:36:46] <Casper> check imply read
[22:37:18] <Casper> you talk about clearing the bit..
[22:38:58] <Evidlo> Casper: 1 to clear implies that a 0 means its set, is what I mean
[22:43:17] <cehteh> Evidlo: you doing it w/o interrupts now?
[22:44:55] <cehteh> otherwise when the ADC is your only interrupt source, then you can make it a EMPTY_INTERRUPT, waking the mainloop
[22:45:40] <cehteh> you dont even need to check for it then, but may start the ADC noise canceling sleep
[22:46:00] <Evidlo> cehteh: I'm using OCR1A to trigger the ADC at 9600Hz
[22:47:24] <cehteh> but w/o interrupt?
[22:47:33] <Evidlo> no interrupt
[22:47:59] <cehteh> then the ADC_vect could be the only interrupt in your code
[22:48:12] <cehteh> for waking the mainloop
[22:48:31] <Evidlo> Here's what I've got. Doesnt work yet:
http://www.rafb.me/results/EHgUtG64.html
[22:48:53] <cehteh> you still use int and volatile too much :D
[22:48:57] <Evidlo> messed up my indentation
[22:49:07] <Evidlo> Oh yeah, I forgot to fix those
[22:49:46] <cehteh> i dont know if you need to start the ADC when you autotrigger
[22:50:23] <cehteh> but at first in your mainloop you should enter a adc noise canceling sleep (or just sleep_idle)
[22:50:55] <cehteh> enable the ADC_vect but make it an EMPTY_INTERRUPT
[22:51:08] <Evidlo> for debugging?
[22:51:18] <cehteh> no
[22:51:24] <cehteh> that would wake your mainloop
[22:51:41] <Evidlo> Oh ok. But first, my code isn't working even in this state
[22:51:44] <cehteh> well or you do busy looping by checking the ADC .. you can do either or
[22:53:16] <Evidlo> my ADC checking logic is wrong
[22:53:49] <cehteh> yes checking for ADIF doent work this way
[22:55:47] <Evidlo> OK, I think it should be `if ((ADCSRA & 1<<ADIF) == 0)`
[22:55:57] <cehteh> if you want to busy wait you have to check and wait as long ADSC is set
[22:56:02] <cehteh> no
[22:56:25] <cehteh> ADIF gets only set when you enable interrupts iirc, not when a result is ready
[22:56:43] <cehteh> but then you need to handle the interrupt, which would making the check pointless
[22:57:12] <Evidlo> The datasheet says 'This bit is set when an ADC conversion completes and the data registers are updated.'
[22:57:14] <cehteh> the interrupt handler would also automatically clear that bit
[22:57:24] <cehteh> so never ever check for it .. wrong way
[22:57:46] <cehteh> mhm i thouht its only set when interrupts are enabled
[22:57:57] <cehteh> and by the way .. so far i always used interrupts with the ADC
[22:58:22] <cehteh> with this EMPTY_INTERRUPT thing you have relative low overhead
[22:58:31] <cehteh> 7 cycles or so
[22:58:46] <cehteh> ah plus wakup which takes 4 cycles iirc
[22:58:47] <Evidlo> What's wrong with triggering it directly using OCR1A?
[22:58:55] <cehteh> your triggering is ok
[22:59:09] <cehteh> i mean reactin on when its finished
[22:59:51] <Evidlo> I know I can put the micro to sleep while the ADC is going, but how do I do it this way first? What bit should I check?
[23:00:26] <cehteh> no bit check at all
[23:00:40] <cehteh> just start the adc with auto triggering
[23:00:46] <cehteh> then go sleep
[23:01:13] <Evidlo> so I have to use an interrupt if i want my computation to run once for each measurment?
[23:01:25] <cehteh> eventually the timer will trigger a conversion, while the µC still sleeps
[23:02:16] <cehteh> when that coversion is finished it wakes the µC from sleep, calling the ADC_vect (which should be defined as EMPTY_INTERRUT)
[23:03:08] <cehteh> empty interrupt instantly returns, but executes your program (mainloop) right behind the sleep .. you fetch the ADC data there, do your caclulations.. loop and sleep again
[23:03:51] <cehteh> thats one way to do this, there are certainly other ways
[23:04:24] <cehteh> with only *one* interrupt (from the ADC) you can be sure that your µC is synced with it and only waken up by that
[23:05:07] <cehteh> when you add multiple interrupt sources then things might become a bit more complicated as you need to check for the wakeup reason
[23:06:27] <cehteh> you can do a busy wait to, but i think with autotriggering this gets even more messy
[23:06:54] <Evidlo> I want to get this working first for my own learning purposes
[23:07:38] <Evidlo> Why does the datasheet say that ADIF is cleared by writing a logical 1? Does that mean that ADIF is 0 when it is set?
[23:07:48] <cehteh> no
[23:07:59] <cehteh> it only means that its clearned by writing a 1
[23:08:13] <Evidlo> So I write a 1 to a bit that is already 1 to make it 0?
[23:08:28] <cehteh> and i am not sure it gets set when ADIE id disabled
[23:08:32] <cehteh> yes
[23:08:38] <cehteh> magic hardware registers
[23:08:59] <Evidlo> Is that why PINB = 1<<PB1 toggles the pin?
[23:09:38] <cehteh> but if you have to set ADIE for ADIF .. .then you can use the sleep and wake thing with interrupts at the first place instead a ugly workaround
[23:09:58] <cehteh> thats just special with i/o registers, nothing logical
[23:10:07] <cehteh> its like it is implemented, dont question it :D
[23:10:57] <cehteh> from what i read ADSC is the way to check if a conversion is running
[23:11:07] <cehteh> but for a busy wait its ugly
[23:11:12] <cehteh> with autotriggering
[23:12:43] <Evidlo> I don't care if a conversion is currently running, just if one was finished since the last time I checked
[23:12:48] <cehteh> because you first have to wait that the autotrigger starts it while(!(ADCSRA&(1<<ADSC))); .. followed immediatly by waiting for its finish while(ADCSRA&(1<<ADSC));
[23:13:25] <Evidlo> so what's the point of ADIF, if not for this specific case?
[23:13:59] <cehteh> all interrupts have some bit somewhere indicating that the interrupt is pending
[23:14:27] <cehteh> for example if the µC is already in a interrupt handler, then interrupts (nested interrupts) are usually disabled
[23:15:03] <cehteh> as soon it returns (and reenables interrupts) from the handler, the next pending interrupt gets executed
[23:15:29] <cehteh> so this bits are more some hardware artifact and can be used for some tricky programming techniques sometimes
[23:15:36] <Evidlo> The datasheet makes it sound like ADIF gets set right after the ADC update is complete, regardless of whether you are using an interrupt
[23:15:52] <cehteh> can be. test it, i never used it in this way
[23:16:15] <Evidlo> Yea, here's what I did. Still doesn't work:
https://dpaste.de/UasK
[23:16:25] <cehteh> and dont use ~ .. the ==0 or !(....) is the proper check
[23:17:13] <cehteh> i really think ADIF is the wrong way
[23:17:32] <cehteh> try while(!(ADCSRA&(1<<ADSC))); while(ADCSRA&(1<<ADSC));
[23:18:04] <cehteh> no if ()
[23:20:10] <Evidlo> This book does it the way I'm trying to
https://books.google.com/books?id=3qSSAwAAQBAJ&pg=PA86&lpg=PA86&dq=avr+check+if+adc+ready+adif&source=bl&ots=PariU5rr3R&sig=_UR5VGA-IPEnAq33U_AfDjaKU0k&hl=en&sa=X&ved=0ahUKEwikh9Px6MbLAhVpv4MKHVTiCwoQ6AEISjAG#v=onepage&q=avr%20check%20if%20adc%20ready%20adif&f=false
[23:20:15] <Evidlo> uhhh
[23:27:12] <cehteh> then try it that way
[23:27:25] <Evidlo> Ok, I was missing ADCSRA |= 1<<ADSC at the end of my computation
[23:27:43] <cehteh> you shouldnt need that
[23:27:51] <cehteh> since you are autotriggering
[23:27:58] <cehteh> but maybe your autotrigger is borked
[23:28:10] <cehteh> i havent checkd that code
[23:28:48] <Evidlo> It must be. It isn't running at the frequency I expect it to
[23:30:37] <cehteh> when you need to ADCSRA |= 1<<ADSC then autotrigger doesnt work
[23:30:57] <cehteh> thats just the redneck method
[23:31:16] <cehteh> start next conversation as soon your loop is through
[23:31:19] <Evidlo> Does the act of reading from ADCH or ADCL trigger something?
[23:31:27] <cehteh> yes
[23:31:33] <Evidlo> I'm only reading from ADCH
[23:31:40] <cehteh> well not trigger but read datasheet
[23:31:53] <cehteh> order of reading is important
[23:31:56] <Evidlo> I know they have to be read in a certain order
[23:32:09] <cehteh> ok thats what i meant
[23:32:11] <cehteh> nothing else
[23:33:43] <Evidlo> I'm pretty sure my autotrigger stuff is correct
[23:36:12] <cehteh> i havent checked :D
[23:36:54] <lorenzo> hm dumb question but it's 5 am and I need to get this thing done
[23:37:10] <lorenzo> libs/sht31.c:31:5: warning: left shift count >= width of type [enabled by default]
[23:37:10] <lorenzo> serial |= (i2c_read_ack() << 16);
[23:37:17] <lorenzo> serial is uint32_t
[23:37:22] <lorenzo> i2c_read_ack() is a uint8_t
[23:37:27] <lorenzo> so why can't I << 16 ?
[23:41:08] <cehteh> because its uint8
[23:41:14] <lorenzo> yeah forgot a (uint32_t) cast
[23:41:30] <cehteh> thats super ugly
[23:41:50] <Evidlo> also use a pastebin
[23:41:51] <cehteh> i hope the compiler optimizes that :D
[23:41:57] <lorenzo> eh :<
[23:42:49] <cehteh> i mean technically there is no need for shifting
[23:43:09] <cehteh> it just needs to or the result (or even write if all is zero) to the right byte
[23:43:33] <lorenzo> yeah, I need to read 4 bytes via I2C into a single uint32_t (which is the serial number of the device)
[23:44:35] <cehteh> in some serializer code i did something more ugly, but dont rely on compiler optimizations:
[23:45:12] <cehteh> ((uint8_t*)&serial)[3] = i2c_read_ack(); kindof this
[23:45:38] <cehteh> of course relies on endianess etc
[23:46:07] <lorenzo> ah so you move the "implicit" pointer byte by byte?
[23:46:10] <lorenzo> over the 32 bits
[23:46:31] <cehteh> i just calculate the right address where to put the byte
[23:46:40] <cehteh> thats resolved at compiletime
[23:47:35] <cehteh> but you may check both variants, what asm it generates, i wont be surprised if both results in the same
[23:49:09] <Evidlo> I'll try asking on AVR forums