Back
[00:00:15] <inflex> if you're going for speed, just use a LUT
[00:00:24] <inflex> then you only have the single offset address calculation
[00:00:32] <dsal> How would you go about doing that?
[00:01:10] <Chillum> anyone use one of these:
http://www.hobbyking.com/hobbyking/store/__27195__Atmel_Atmega_Socket_Firmware_Flashing_Tool.html
[00:01:26] <Chillum> a bit pricey but looks really easy to use
[00:01:44] <dsal> Chillum: Yeah, I use that a lot.
[00:01:58] <Chillum> it is as easy to use as it looks?
[00:02:15] <dsal> Kind of. You can sometimes put it on wrong or something. But it's mostly pretty good.
[00:02:26] <Chillum> going to get one of those for sure, I hate those clam shell adapters. Even with a loose chip they are hard to use
[00:02:36] <Chillum> being able to attach after being soldered is great
[00:02:47] <inflex> Chillum, nice, need one for my SOT23
[00:02:51] <dsal> Yeah. I use these for lots of pre-built things.
[00:03:11] <dsal> I'm kind of excited about that sot23 stuff. It seems ridiculous.
[00:03:13] <inflex> For the most part they shouldn't blow too many chips with those
[00:03:21] <inflex> dsal, *shrug* I love them, I feel the same *laugh*
[00:04:11] <dsal> How's this LUT idea work, btw?
[00:04:14] <inflex> I might buy one of those programming adapters, god knows there's plenty of times where I can't get access to the normal ISP port, or I don't have the right converter with me
[00:04:27] <dsal> I'm not that great at thinking in asm.
[00:04:59] <dsal> Oh wait, I could have some data and just load addr+register or something.
[00:05:05] <dsal> Still not great at thinking in asm. heh
[00:05:15] <inflex> dsal, basically it's just an array of values, in sequence... and you just go sbi PORTB, (base +offset)
[00:05:46] <dsal> Oh, I can sbi with a variable?
[00:05:52] <dsal> Do you have an example of how this works?
[00:06:20] <inflex> my_lut: .byte 8;
[00:07:09] <inflex> set the bitmaps for PORT appropriately
[00:07:11] <dsal> So then calculate offset, load, and out?
[00:07:24] <inflex> then you should be able to do something like... sbi PORTB, my_lut +N
[00:08:14] <inflex> mayube something like... my_lut: .byte 1, 2, 4, 8, 16, 32, 64, 128
[00:09:11] <inflex> here's a quick way... do it in C, then dump the code :)
[00:09:21] <dsal> Yeah, I can't sbi my register. That'd be handy. With the LUT, I'd have to load first. It's kind of lame because I only really need four values.
[00:10:01] <dsal> I might just pass on this one, though that's a good learning experience. It's already... beyond requirements.
[00:10:06] <inflex> np
[00:10:14] <dsal> Thanks a lot for the help, though.
[00:10:20] <dsal> I wrote a loop, so like... yay me.
[00:10:23] <inflex> I'm still waiting for some more parts and then I can start my production with my T10s
[00:10:28] <inflex> loop works :)
[00:10:53] <dsal> The C -> asm as insanely bad. I ended up just deleting the most complicated bits of my code and writing them from scratch. I'm almost pro.
[00:11:23] <inflex> ja, I know a lot of the conversions make you go "WTH?"
[00:11:35] <dsal> I didn't even understand what some of that code was doing.
[00:12:03] <dsal> Like, actually unreadable:
[00:12:05] <dsal> mov r0,r19
[00:12:05] <dsal> rjmp 2f
[00:12:05] <dsal> 1:
[00:12:05] <dsal> lsl r24
[00:12:05] <dsal> 2:
[00:12:05] <dsal> dec r0
[00:13:47] <inflex> i guess when we drop down to things like the T10 we have to accept that we need to kludge certain things (like variable bitshift)
[00:14:01] <inflex> I remember being upset that the Z80 didn't have a MUL operand
[00:18:52] <inflex> hang on, I'm a dead headed moron... sbi/cbi should work fine if you know which bit you want to set/clear
[00:19:00] <inflex> ie, sbi PORTB, N
[00:19:18] <dsal> I've got that in a register. It wouldn't let me give it my register.
[00:19:54] <dsal> I'm breaking out ppm -> pwm so clear is easy, I just set the port to zero.
[00:20:34] <inflex> bbl, got to do banking run... my brain is clearly fuzzy today
[02:33:10] <dsal> Got rid of loop. Threw out a bunch of code. It almost does nothing now. I wonder if it still works. Eager to scope tomorrow.
[02:35:09] <Xark> dsal: Did you start with optimized C output?
[02:36:20] <dsal> -Os -- but I threw out the bulk of it because it was really dumb.
[02:36:27] <Xark> :)
[02:36:41] <Xark> dsal: You need to write a compiler next! :)
[02:37:04] <Xark> However, C is somewhat cruel to poor 8-bit AVR.
[02:37:11] <dsal> hope not :(
[02:37:40] <Xark> You get a lot better code if you use -mint8 (but beware not recompiling everything with that)
[02:38:04] <Xark> (changes size of "int" to 8-bits)
[02:39:05] <Xark> Not standard compliant, but works great for AVR (and you can use int16_t and int32_t etc. as needed still)
[03:12:46] <dsal> Ah, I was using uint8 everywhere. Being able to say exactly what I want to happen is really nice, though.
[03:16:00] <Xark> dsal: That is good. However, even using uint8 everywhere, C standard still forces some calculations to be done at "int" precision (hence -mint8's effectiveness).
[03:16:18] <Xark> (especially WRT function arguments and returns)
[04:23:11] <LeoNerd> Xark: ooooh... does that make enums and bools 8bit too?
[04:28:37] <cehteh> would be nice when one could just turn off C internals coercions
[04:31:02] <stephe_> my fingers get tired of typing uint8/16/32_t etc
[04:36:29] <LeoNerd> u8 u16 u32 ...
[04:38:31] <stephe_> LeoNerd: is that what you do?
[04:46:07] <twnqx> i do that, too o/
[04:46:34] <twnqx> u<length> and s<length>
[05:15:58] <cehteh> just no coercison and automatic type deduction .. wont that be simple?
[05:16:24] <cehteh> needs some rules for mixed type expressions still
[08:57:50] <anton02> i made a circuit in lt spice then imported it using eagle's ltspice importer. then i used altium's eagle importer to import that schematic from eagle
[09:35:09] <cehteh> woot .. my line editor with utf-8 enabled is smaller than w/o
[09:44:16] <cehteh> an no wrong 40 byte more
[10:40:08] <dsal> Should I expect sleep/wakeup in my main loop to introduce a delay?
[10:40:24] <dsal> I guess there's not much of a point in asking since I'm going to measure it anyway, but I'm away from my equipment.
[10:42:15] <dsal> "If an interrupt occurs when the MCU is in sleep mode, the interrupt execution response time is increased by four clock cycles."
[10:42:20] <dsal> Bah. Ain't nobody got time for that.
[10:42:37] <dsal> Any reason not to just 10: goto 10 ?
[10:43:18] <theBear> how quick you expect to wakeup from sleep ? yer lucky it's quicker than a full startup
[10:43:34] <theBear> and cos nothing happens is why
[10:44:13] <dsal> I'm doing nothing but processing interrupts. I just want the main thing be thin.
[10:44:51] <dsal> I'd like a "wait for interrupts" sort of thing that's better than this:
[10:44:52] <dsal> mainLoop:
[10:44:53] <dsal> rjmp mainLoop
[10:47:49] <cehteh> add a few nop's ... who explained that some days ago?
[10:48:56] <cehteh> btw what sleep mode? are all equal? i doubt that
[10:49:05] <dsal> Getting rid of my sleep mode code got me down to 122 bytes for my ppm -> pwm decoder.
[10:49:32] <dsal> That text was the only thing I found relevant. I assume that's 'idle.' I'm guessing deeper sleeps are more costly.
[10:49:54] <dsal> But I'm trying to reduce latency, because, you know, people can feel that 4µs I was accumulating.
[10:49:55] <cehteh> you only want to convert ppm to pwm?
[10:49:59] <cehteh> nothing else?
[10:50:07] <dsal> Yeah. That's what I've got now.
[10:50:24] <cehteh> then i'd consider the other way around
[10:50:41] <dsal> I realized my loop with sleep mode in my testing was doing it without sleep mode enabled.
[10:50:41] <cehteh> get rid of interrupts, poll the i/o's
[10:51:09] <dsal> Why poll?
[10:51:25] <cehteh> because thats constant time
[10:51:56] <dsal> I got rid of my O(N) thing from channel output. It should be quite consistently ~2µs latency per channel.
[10:52:08] <cehteh> do everything in one loop maybe even w/o any branching (except the rjmp main)
[10:52:12] <cehteh> complete constant loop
[10:52:32] <cehteh> 8mhz?
[10:52:48] <cehteh> up to 8 channels?
[10:52:49] <dsal> yeah
[10:52:56] <dsal> Well, 8 on input, 4 on output.
[10:53:15] <dsal> 5 if I get brave and disable reset.
[10:53:31] <cehteh> wont matter, its only one port
[10:53:45] * cehteh thinks about a very simple way to do it
[10:54:21] <dsal> Mine's pretty simple. :)
https://github.com/dustin/snippets/blob/master/avr/deppm/deppm.S
[10:54:34] <dsal> disclaimer: I've not actually tested it since I made a bunch of changes last night.
[10:54:39] <cehteh> yes i am thinkin about 1/4 that size :D
[10:55:07] <dsal> neat
[10:55:21] <cehteh> ok well maybe 1/2 with starting timer and so .. but no interrupts
[10:55:27] <cehteh> 16 bit timer?
[10:55:55] <cehteh> mhm possibly you dont even need a timer, with a constant loop you just count iterations
[10:56:16] <dsal> This is 8 bit. I only need somewhere around 2.5ms
[10:56:34] <dsal> Yeah. If nothing's changing for a bit, we're back to 1.
[10:56:52] <cehteh> my ppm parser runs at /1 .. thats even at 16 bit very short time :)
[10:58:45] <cehteh> 8192µs actually
[11:16:51] <dsal> What was the thing about nops, btw?
[11:17:39] <cehteh> less latency
[11:19:27] <dsal> Is there a rule of thumb?
[11:21:00] <cehteh> no hard facts
[11:21:40] <cehteh> jump takes 2 cycles, interrupts are only served after the executing instruction completes
[11:21:53] <dsal> Oh, I see.
[11:25:33] <dsal> It's unfortunate there's not a "do nothing forever" instruction. Best I could do is fill remaining flash with nops and a jump.
[11:28:13] <cehteh> oh cool there are "branch if interrupt enabled/disabled" instr
[11:28:17] <cehteh> didnt know that
[11:30:53] <cehteh> the program counter isnt directly accessible right?
[11:31:14] <jacekowski> it is
[11:33:12] <cehteh> main: subi PC, 1
[11:33:26] <cehteh> would that work?
[11:34:12] <jacekowski> nope
[11:35:01] <jacekowski> you can read it
[11:35:06] <jacekowski> but writing to it will end up badlyu
[11:35:14] <jacekowski> as you can only write 8 bits at the time
[11:35:19] <cehteh> thats ok
[11:36:28] <cehteh> when you just decrement it and align your function properly (not on a 512 byte boundary) then decrementing the lower part would do
[11:36:57] <jacekowski> but it will still take 2 cycles
[11:37:24] <cehteh> so the single bytes are not accessibe?
[11:37:39] <cehteh> i never did so much asm on avrs
[11:37:42] <jacekowski> no
[11:37:45] <jacekowski> 2 stage pipeline
[11:37:48] <jacekowski> it still has to flush it
[11:38:02] <cehteh> ok
[11:38:23] <jacekowski> and i'm not 100% sure how it will work if you do it without jmp/branch instructio
[11:38:48] <jacekowski> iirc it is those instructions that cause the pipeline flush
[11:38:55] <cehteh> i didnt really expected it to work, on some archs that work .. but well
[11:39:15] <jacekowski> if you do it other way it might still execute next instruction and then instruction at the correct address
[11:39:30] <cehteh> that could be still ok
[11:39:49] <cehteh> main: subi PC_lowerbyte, 1 ; nop
[11:40:03] <Xark> jacekowski: An easier way is just rjmp. :)
[11:40:21] <cehteh> the idea is to to it in one cycle not 2
[11:40:59] <Xark> Seems unlikely as it fetches next opcode during same cycle.
[11:41:44] <cehteh> if that opcode rigged to be nop it wont matter
[11:41:51] <jacekowski> basically any changes to IP/PC on any architecture will have to cause pipeline flush and have a delay or cause undesired side effects
[11:41:59] <Xark> okay, but it is not a useful technique (that I can see).
[11:42:19] <cehteh> was just a thought experiment
[11:42:45] <cehteh> i think i would start with the thing dsal does in C w/o interrupts
[11:42:51] <Xark> If it worked, it would be interesting. :)
[11:42:56] <jacekowski> also, i'm not 100% sure where it would jump
[11:43:04] <jacekowski> as there is the internal PC incrementer thing
[11:43:48] <dsal> If you did it in a sea of nops, maybe that wouldn't be bad.
[11:43:52] <cehteh> even then nop; nop; nop; main: subi PC,1; nop; nop nop .... nopfenced
[11:44:10] <cehteh> or subi PC,2 ...
[11:44:34] <jacekowski> why not just make it sleep
[11:44:39] <cehteh> as long its in a loop with only 1 cycle instructions its fine
[11:44:55] <cehteh> because he complained that waking from sleep takes extra 4 cycles
[11:45:21] <cehteh> well .. thats nothing much compared to interrupt handling
[11:45:30] * Xark is starting to think dsal really wants an FPGA. :)
[11:45:44] <dsal> Yeah. This latency is ridiculous.
[11:45:48] <cehteh> it has be done on tinys and its pretty simple to do
[11:46:10] <cehteh> but interrupts have some latency, you have to account for that
[11:46:28] <cehteh> when you do it right its static and you can just substract it
[11:46:38] <cehteh> or .. again .. do it w/o interrupts
[11:46:43] <Xark> cehteh: Also indeterminate latency (as it waits for current instruction).
[11:47:04] <cehteh> Xark: that was the reason for the 1-cycle loop idesa
[11:47:20] <Xark> cehteh: Yeah, I was thinking that.
[11:48:26] <stephe_> anyone want a 250$ breadboard?
https://wakutuku.com/shop/breadboardmaniac/bbm-wbb.html
[11:48:27] <stephe_> :D
[11:48:30] <cehteh> damnit i need to write the servo driver for mµOS .. then the problem dsal just becomes very simple :D
[11:48:45] <cehteh> pure gold breadboard?
[11:48:47] <Xark> cehteh: Seems to me interrupts are never going to be least latency though
[11:48:48] <dsal> heh. I'm just learning. My original C version was fine. :)
[11:49:17] <cehteh> Xark: i just dont rely on interrupt timing when it needs to be hard
[11:49:30] <Xark> stephe_: Needs more bling. :)
[11:49:42] <cehteh> bamboo breadboard?
[11:49:45] <dsal> I figured interrupt timing would be pretty good. 2µs isn't that bad.
[11:49:57] <Xark> cehteh: Right. Although not too hard to make interrupt cycle accurate.
[11:50:09] <Xark> (polling timer)
[11:50:21] <cehteh> depends whatever load is there
[11:50:34] <cehteh> if other interrupts happen then you get a problem
[11:50:35] <stephe_> cehteh: google translate says fir :D
[11:50:59] <cehteh> i should build one in my workshop :D
[11:51:03] <Xark> cehteh: Not a problem per se, but will affect latency. :)
[11:51:09] <cehteh> would be a hell of a drill job
[11:59:21] <Mr_Sheesh> how well would bamboo do w/ soldering temps tho?
[11:59:30] <cehteh> no problem
[11:59:42] <cehteh> may geta bit smoked :D
[11:59:53] <cehteh> but who solders on breadboards?
[11:59:58] <Mr_Sheesh> yeah, burned grass smell
[12:00:47] <cehteh> well that was my idea .. stripe raster PCB's where the holds have pre-tinned springs
[12:01:05] <cehteh> one can mount and test things like on a breadboard
[12:01:24] <cehteh> and then make it permanent with hotair or soldering
[12:17:38] <stephe_> what do you guys use to power your breadboard thingies?
[12:20:35] <dsal> Lab power supply mostly.
[12:20:53] <dsal> When I'm working on something with usb and need 3v3, I just stick a vreg in the breadboard.
[12:35:53] <cehteh> i use usb often
[12:40:27] <stephe_> i first will need a desk to work at before i get to lab power supply level :D
[12:40:49] <stephe_> cehteh: how do you power it with usb?
[12:41:48] <cehteh> eh?
[12:42:06] <cehteh> just plug it in?
[12:42:28] <cehteh> either usbasp or onboard usb
[12:44:12] <stephe_> cehteh: ah ok thought maybe you had something like this
https://wakutuku.com/shop/breadboardmaniac/bbm-muc.html
[12:44:35] <stephe_> https://wakutuku.com/shop/breadboardmaniac/bbm-muc-w.html
[12:44:40] <stephe_> this guy really likes wood :D
[12:44:46] <cehteh> wtf is that?
[12:45:04] <cehteh> ah ok
[12:46:00] <cehteh> devel is just a arduino nano on a mini breadboar here.
[12:46:22] <cehteh> some old usb hub then i can connect logic analyzer together with the nano
[12:46:45] <cehteh> i dont need much more just for software development
[12:46:59] <cehteh> few probes, leds .. done
[12:47:25] <cehteh> handfull 5V leds is fine for breadboard work
[12:48:08] <cehteh> or the bare tiny84 thing
https://pbs.twimg.com/media/CeU4GP_WIAAWRsV.jpg:large posted that already
[12:48:40] <cehteh> thats hooked on the avrisp when testing
[12:48:56] <cehteh> usbasp ...
[12:49:10] <stephe_> your masterpiece, yes i remember you posted that :)
[12:49:33] <cehteh> whats masterpiece there? :D
[12:49:34] <dsal> I'm super pro:
https://usercontent.irccloud-cdn.com/file/Aap8eOHw/why%20r
[12:50:13] <cehteh> to much space required :D
[12:50:35] <cehteh> and 3/4 of the breadboard unused!
[12:51:33] <dsal> I could probably reduce some of that by knowing what I'm doing.
[13:15:28] <cehteh> hah .. the mµOS manual is 44pages meanwhile .. 13 of that are the GPL ;D
[13:15:42] <Xark> :)
[15:30:06] <liwakura> how do i call a de-init function, like uart_deinit()? uart_stop()?
[15:30:33] <liwakura> or just use enable() / disable() pairs?
[15:30:50] <twnqx> init/shutdown is what i use (if i ever shut down)
[15:31:27] <liwakura> also a good canidate.
[15:32:06] <twnqx> else, init/uninit
[15:32:25] <liwakura> hm.
[15:32:36] <liwakura> uninit is such an ugly word
[15:33:09] <liwakura> kill or shutdown... hm.
[15:33:19] <liwakura> stop sounds so simple
[15:33:31] <liwakura> if it had 4 letters like init, that would be great
[15:33:34] <liwakura> the sections use fini
[15:33:41] <liwakura> which sounds like shit tbh
[15:34:50] <liwakura> dispose.
[15:53:57] <phinxy> exterminate
[15:54:07] <phinxy> nullify
[16:01:06] <antto> uded
[16:29:50] <Jartza> liwakura: I usually use init/deinit
[16:30:27] <Jartza> stop is bad because there are cases where you might start/stop already initialized bus.
[16:31:08] <liwakura> i see
[16:31:52] <liwakura> same goes for enable/disable
[17:34:10] <eszett> hmm
[17:55:12] <hetii> hi
[17:55:42] <hetii> What is the maximum ISP speed that I can use to reflash modern avrs?
[17:56:23] <machinehum> It's a function of your clock speed
[17:56:27] <Tom_itx> damn fast
[17:56:39] <machinehum> 1/4 ? I think
[17:56:45] <Tom_itx> /4 your clock rate
[17:57:06] <Tom_itx> what's your rush?
[17:57:33] <machinehum> Chip burning compatition
[17:57:37] <machinehum> duh
[17:57:48] <hetii> well stk500v2 support max isp clock 1.8MHz, but I port it to work with esp8266 and his hardware isp clock can handle up to 80MHz
[17:58:17] <hetii> so I wonder if it make sense to implementen such speed in protocol.
[18:01:30] <martinus> machinehum | Chip burning compatition >> I tried programming my uC with a plasmatorch. It burned *really* quickly...
[18:01:52] <martinus> Write once, use never.
[18:04:29] <Tom_itx> i programmed some at 1v
[18:04:31] <Tom_itx> beat that
[18:04:56] <inflex> lo Tom_itx
[18:05:01] <Tom_itx> haha
[18:05:18] <Tom_itx> lotsa diode drops ...
[20:11:06] <inflex> Anyone done a hall-effect sensor power switch? ie, I'd like to have a latching-toggle effect, where bringing the magnet near the sensor switches it to the opposing state (ie, on->off->on etc)
[20:11:20] <inflex> must need a low quiescent ... and will be doing SMD
[20:14:00] <apo_> inflex: try reed switch + lowpass + flipflop? :p
[20:14:34] <inflex> aye, tried that in the past... reeds that size are expensive and a bit delicate :(
[20:14:39] <apo_> true enough
[20:16:06] <inflex> hrmm... there's latching hall sensors in SOT23
[20:17:47] <inflex> nope, they don't do what I expected, though I suppose they could still work (basically N turns on, S turns off )
[23:42:48] <dsal> cehteh: I tried your idea. It's a bit less consistent. I get between 920ns and 2.68µs so far.
[23:42:59] <dsal> I'm still using a timer to sync.
