Back
[02:35:22] <_abc_> Good morning, rise and shine.
[02:36:13] <_abc_> Yesterday I posted my take on a timer interrupt jitter compensator for atmega, very few people looked. Here it is again, comments are welcome:
http://188.25.6.236:8881//mypaste/a0daa060507db22a41cf
[02:36:32] <_abc_> Yesterday I posted my take on a timer interrupt jitter compensator for atmega, very few people looked. Here it is again, comments are welcome:
http://188.25.6.236:8881//mypaste/a0daa060507db22a41cf/tmr0_isr_jitter_comp_v1.asm <- this works, disregard ...
[02:36:36] <_abc_> ... previous
[02:39:09] <chisight> server error _abc_
[02:39:21] <sabor> http://188.25.6.236:8881/mypaste/a0daa060507db22a41cf/tmr0_isr_jitter_comp_v1.asm
[02:39:27] <_abc_> chisight: hm? Several people got it, logs show it
[02:39:32] <_abc_> ^
[02:40:02] <sabor> the second double slash leads to an error for me too
[02:40:08] <_abc_> So, comments welcome. Especially if someone (like Dean Camera / abcminiuser or similar wizards) already dunnit with a much shorter piece of code.
[02:40:13] <chisight> looks like an extra slash
[02:40:21] <chisight> as sabor aays
[02:40:23] <_abc_> Oh I pasted that. Just a second
[02:40:23] <chisight> says
[02:41:01] <_abc_> http://188.25.6.236:8881/mypaste/a0daa060507db22a41cf/tmr0_isr_jitter_comp_v1.asm <- this link works, sorry if I pasted a broken one before, it was copy paste from a wrapped terminal and it fubar'd the link in the middle.
[02:41:32] <_abc_> Please confirm it works for you, it works for me, hairpinning in the local router.
[02:44:31] <sabor> i guess this only works when the timer is running at full speed...
[02:46:14] <chisight> i don't see a problem with the code and it's like half or 1/3 the jitter of the code i wrote. my approach was a tight loop reading the timer.
[02:49:35] <sabor> _abc_: i think you could make the code even shorter
[02:50:32] <sabor> _abc_: you could move _tmr0ofl_timing_comp to the end of the nopand then subtract twice the timer value
[02:51:14] <sabor> and if fudge is added to that address then you can remove that subi too
[02:51:52] <sabor> but the way it is now it is easier to understand
[02:55:16] <chisight> depending on what you're trying to do, it might be more accurate to do this in hardware.
[02:55:54] <chisight> obviously you know how to write an io, so that's probably not what you're doing here.
[02:56:18] <chisight> if you're trying to read a bit, just write a latch, then read the latch at your convenience.
[02:56:36] <chisight> no need for precision isr timing.
[02:56:37] <_abc_> The comments say clearly the timer is running in ccp mode at full speed.
[02:57:00] <_abc_> What I am doing is dds. I need to reduce output timing jitter as much as possible.
[02:57:30] <chisight> so this is writing to a dac?
[02:57:41] <Emil> _abc_: mate, pls
[02:57:51] <_abc_> sabor: I will look at that but that will save 3-4 instructions. Moving to a brXXX code will save more since Z will be left alone and the expensive push/pop will not be used
[02:57:55] <Emil> invest in reading comprehension :D
[02:58:01] <_abc_> Emil: ?
[02:59:43] <_abc_> So moving to brXXX will require much more knowledge about the possible values in TCNT0 when the isr fires. Then I can probably do something hacky involving bit tests on a snapshot (or direct!) TCNT0 value and rjmp using brXXX tests without changing Z ...
[02:59:47] <_abc_> ... and maybe not even R1
[02:59:57] <_abc_> This may reduce the code from the current 23 tcyc to possibly 10-15
[03:00:34] <sabor> yes, makes sense
[03:00:38] <_abc_> So, currently, on atmega328, the jitter can be in theory max 5 cycles, right?
[03:01:48] <_abc_> There are 1,2,3 cycle instructions, none are 4, and there is a +1 uncertainty at either end if the interrupt occurs asynchronously wrt the cpu clock domain. Which should never happen with an internal timer but better safe than sorry. Correct?
[03:01:59] <sabor> isn't the maximum jitter the difference between the intruction with the most cycles and the one with least cycles?
[03:02:00] <chisight> ok, dpm
[03:02:11] <_abc_> dpm? chisight ?
[03:02:13] <chisight> ok, don't use hardware. your call.
[03:02:32] <_abc_> don't use hw? I am not following you.
[03:03:06] <chisight> your dds writes to a dac, right?
[03:03:12] <_abc_> sabor: in theory it is. In practice one must account for "unforeseen circumstances", which should never occur for an internal timer, i.e. metastability.
[03:03:16] <_abc_> chisight: r2r
[03:03:45] <chisight> you can use a shift register and latch it out using a pwm.
[03:03:46] <_abc_> sabor: even if, removing 2 nops shortens the code from 23 to 21 cycles. Insignificant.
[03:04:08] <chisight> shift bits into the register at your convenience and just latch it at the precise time.
[03:04:13] <sabor> maybe insignificant, maybe it's exactly what you need :)
[03:04:33] <_abc_> chisight: the answer is no. This discussion is about the jitter. You can do your own dds if you like. This particular project needs to work as I said, and we are not discussing the r2r, dac, or anything else besides jitter
[03:05:02] <chisight> using hardware, there would be no jitter and no need for precision isr routines.
[03:05:39] <sabor> yeah, a bit of hardware can reduce the jitter to 0, shift the data into an 74595, trigger the output latches using pwm, works perfect
[03:05:48] <sabor> and wastes 0 cycles
[03:05:59] <chisight> thank you sabor.
[03:06:11] <sabor> you're welcome :)
[03:06:36] <_abc_> sabor: well going from 23 to 21 is not worth the hassle, especially since I do not know the exact value of TCNT0 on isr entry yet. In theory, I know it, it should be 2+2+{1,2,3} Ncyc + a few to save whatever at the start of the isr.
[03:06:57] <_abc_> Using an external shift register requires an extra pcb to hold it
[03:07:26] <_abc_> I can do that but better not?
[03:07:48] <_abc_> Also solving the jitter problem permanently is a priority.
[03:08:32] <chisight> your approach to the isr jitter problem is very good. an indexed jump based on the exact timer value is a promising approach.
[03:08:35] <sabor> put the cpu asleep and you also have no jitter
[03:09:46] <_abc_> So, back to TCNT0 values on ISR entry: 1, 2 or 3 cyc from OVF bit set, then 2 for the jump to int table, 2 more to jump to the isr proper. So {1,2,3}+2+2 -- does this appear correct so far?
[03:37:58] <_abc_> Right, so, given the incertitude and lack of information I'll make a test program which collects and bins TCNT0 values read in a naked isr at about the position I intend to use them and see.
[03:40:51] <_abc_> <aside>Strange how the simplest things become so complicated to do because of a hiatus of information. Back in Z80 days it was quite common to do hw and sw design both using cycle accurate timing and deep knowledge of machine cycles. Low cost computers ...
[03:40:55] <_abc_> ... would not have been possible without, think ZX80, ZX81 etc. Nowadays that info and the clones of those machines are alive and well, but getting a 20 year old part like atmega to work in similar ways STILL elicits answers like "do it with an ARM" or ...
[03:40:59] <_abc_> ... "use a STM32", on #avr, of all places.
[03:41:02] <_abc_> </comment>
[03:42:34] <hypermagic> evening _abc_
[03:42:39] <hypermagic> whats up?
[03:42:56] <Emil> _abc_: do test suites
[03:43:08] <Emil> _abc_: see how it behaves
[03:43:09] <_abc_> It's close to noon where I am, so, hi. hypermagic just the tail of a discussion. Just joined?
[03:43:19] <_abc_> Emil: I will! No other choice for now.
[03:43:21] <hypermagic> i am no t sure why would anyone need a jitter correction :) i prefer spread spectrum modulated signals
[03:43:33] <_abc_> Right, to each his own.
[03:44:40] <hypermagic> _abc_, i'm kind of busy but i sat down here now
[03:44:57] <hypermagic> just finished 4 apples
[03:48:14] <_abc_> I think I'll just make the FUDGE as long as my ctc reload value (64) and test it, setting flags for each different entry point in the nop table which will be simply "or Rx,Bi;" . There are 64 possible values, the 1st ones are unilkely but whatever, so ...
[03:48:18] <_abc_> ... 8 bytes, global, with one bit each settable whenever ANY such Ncyc value comes up. Run the code for a few seconds with a suitable representative main() and then dump the 8 bytes to analyze them in the host. This is my plan for now. Expected time to ...
[03:48:22] <_abc_> ... implement: ~2 hours from scratch.
[03:48:35] <hypermagic> _abc_, check out binary pwm and delta-sigma modulation ;) you might even like it
[03:48:53] <_abc_> ??
[03:49:22] <hypermagic> ¡¿?!
[03:49:56] <_abc_> Yesterday I posted my take on a timer interrupt jitter compensator for atmega, very few people looked. Here it is again, comments are welcome:
http://188.25.6.236:8881/mypaste/a0daa060507db22a41cf/tmr0_isr_jitter_comp_v1.asm <- hypermagic seen this?
[03:50:53] <hypermagic> http://www.batsocks.co.uk/readme/art_bcm_3.htm
[03:51:15] <hypermagic> https://en.wikipedia.org/wiki/Delta-sigma_modulation
[03:51:30] <_abc_> ds I know. What has this got to do with what I am doing now please?
[03:52:42] <_abc_> your bcm link is mostly reinventing logarythmic dimming using pwm. Nothing new. Philips may take expception, they patented (!) binary log pwm a long time ago for mcs51
[03:52:46] <hypermagic> totally nothing :)
[03:53:06] <_abc_> "Copyright (c) 2008, Nigel Batten.
[03:53:06] <_abc_> Contactable at <firstname>.<lastname>@mail.com
[03:53:19] <_abc_> " right. At least Philips will have trouble locating him by that email. Cunning.
[03:53:20] <hypermagic> delta-sigma modulator has no fixed clock requirement
[03:53:36] <_abc_> It also has nothing to do with what I am doing
[03:54:28] <_abc_> and ds modulator does require that the ratio of each successive output toggle follow the data stream exactly, meaning, it does require timing consistency in the jitter (lack of) sense.
[03:54:51] <hypermagic> lel yeah we know doubleclick is patented too for the greater good and the well being of humanity
[03:55:07] <hypermagic> _abc_, nah :)
[03:55:41] <hypermagic> frequency is irrelevant
[03:55:59] <hypermagic> it only defines ripple voltage
[03:56:50] <_abc_> huh? You are assuing dc output, that is not the case.
[03:57:28] <_abc_> "ripple" voltage in a dynamic context with sufficiently close clock to 2x mof is actually distortion.
[03:58:03] <_abc_> http://www.electronicsweekly.com/blogs/mannerisms/consumer/infineon-micro-avoids-philips-2013-03/ http://www.ledsmagazine.com/articles/2008/03/philips-files-led-patent-lawsuit-against-lighting-science-group.html
[03:58:08] <_abc_> not funny at all.
[04:10:27] <hypermagic> https://hackaday.io/project/1477-the-worlds-simplest-hack-ipod-party-amplifier haha
[04:11:54] <hypermagic> <_abc_> not funny at all.- it is
[04:12:53] <hypermagic> just wait till they patent the usage of your hand to wipe your ass
[04:22:10] <carabia> woah, so this guy needed a "system design" diagram for this?
[04:23:07] <hypermagic> http://www.dumpaday.com/wp-content/uploads/2013/07/your-argument-is-invalid-meme-dumpaday-6.jpg
[04:23:22] <carabia> oh wiat, it's you
[04:23:43] <hypermagic> _abc_,
https://www.cds.caltech.edu/~murray/amwiki/images/8/89/Deltasigma-simulation.png
[04:23:51] <carabia> wait, even. i had to unignore you to see if rue was losing his marbles talking to himself or was he talking to you. I forgot to ignore you again.
[04:24:11] <carabia> there we go. better.
[04:24:19] <hypermagic> carabia,
http://i3.kym-cdn.com/photos/images/newsfeed/000/002/623/W7ZWD6YR236ZU3KFX5CUCTA4NQZOREA6.jpg
[04:24:50] <carabia> and to whom it may concern, yeah rue was/is really losing his marbles
[04:36:05] <Emil> carabia: is someone else losing it, too?
[04:48:32] <hypermagic> sup Emil
[04:56:19] <Emil> hypermagic: hi
[05:05:56] <_abc_> To lose marbles, you have to have marbles 1st.
[05:06:06] <_abc_> Good for him, he has something to lose ;)
[05:44:27] <carabia> not anymore he doesn't
[06:31:27] * _abc_ sees by topic that rue_shop1 has been up to good lately. rue_shop1 anything to add wrt my humble attempts to kill off jitter in tmr0ovf isr?
[06:32:37] <_abc_> https://bitbucket.org/jartza/pentaveega/src/3ca3bd496da99284fc766fb3aea6d724a4cd515b/pentaveega.asm?at=master looks like he HAS.
[06:32:57] <_abc_> @label jitterfix: ;)
[06:34:07] <_abc_> Wait, the tiny only has 2 instruction lengths, 1 and 2, right? never 3?
[06:34:27] <_abc_> Ok, I'll fugzre it out.
[06:34:31] <_abc_> *figure even
[06:35:44] <_abc_> So in my case, isr is indirectly reached via table, so 2 more offset vs jartza's code above. Also, I don't see how the jump fixes 3 possible cases?
[06:38:28] <_abc_> ok so I had errors in my code, I was subtracting the offset instead of adding it. It now all "adds up". Still, I don't see how jartza's code deals with an offset of '3' or more? his code runs in ctc mode, psc=/1, so he should deal with 1 2 or 3 T delays?
[06:59:46] <sabor> _abc_: he knows that the instruction is rjmp so the jitter can only be 1 or 2 cycle delay
[07:04:02] <_abc_> why only 1 or 2?
[07:04:29] <_abc_> The jitter appears in the main interrupted code, so there it could be a 1 2 or 3 byte instruction being interrupted, no?
[07:04:39] <_abc_> sabor: ?
[07:06:01] <_abc_> This is driving me insane. avr asm program addresses are always word aligned, right? So I need to compute the cycles, multiply by 2, then rjmp to an address? What am I missing?
[07:06:58] <_abc_> Can the processor even jump to an odd address?
[07:07:11] <_abc_> Oh, wait, no.
[07:09:15] <_abc_> Oh, wait, yes. All opcodes are 16 bits.
[07:09:56] <sabor> i thought there are some 32bit opcodes, no?
[07:10:56] <_abc_> There are but none are 8 or 24
[07:11:06] <sabor> yes
[07:11:34] <_abc_> so the lsbit of any address loaded into ZH:ZL before ijmp MUST be 0 or it will be ignored. Correct?
[07:13:13] <sabor> Indirect jump to the address pointed to by the Z (16 bits) Pointer Register in the Register File. The Z-pointer Register is 16 bits wide and allows jump within the lowest 64K words (128KB) section of Program memory.
[07:13:52] <sabor> so address 0 is first instruction, 1 is second instruction (word)
[07:14:02] <_abc_> Yes so we read between the lines that ZH:ZL contains the WORD address, i.e. bytes are never addressable at all (16 bits -> 64kWORDS). Okay.
[07:32:01] <_abc_> http://188.25.6.236:8881/mypaste/a0daa060507db22a41cf/tmr0_isr_jitter_comp_v2.asm -- new version, using the correct idea of adding nt substracting tcyc to ZL, and other fixes. Code size 15
[07:32:13] <_abc_> Coments?
[07:37:30] <_abc_> Also, wrt the code in the project linked in the /topic, I think it works only because any 3 cycle delay instuction which may appear is simply too rare to matter, iow the program may crash under certain circumstances. To be safe, one needs 2 nops in ...
[07:37:34] <_abc_> ... jittercomp not one
[07:37:59] <_abc_> * in jitterfix after ijmp
[12:24:11] <_abc_> https://github.com/blakewford/boardmicro
[12:33:32] <_abc_> http://realscout.github.io/avr-emulator/ where the heck does one input a file or edit asm or something?
[12:34:37] <_abc_> https://github.com/RealScout/avr-emulator <- linked from
[12:40:37] <rue_shop3> _abc_, hows it progressing?
[12:40:54] <rue_shop3> dont use an emulator, none of them are accurate
[12:40:59] <rue_shop3> put it on a real device
[14:33:59] <_abc_> rue_shop3: I have a dds in inline asm working, doing the serial interface etc
[14:34:30] <_abc_> The jitter issue is not yet fully solved, need to go to full speed xtal and pcb 1st.
[14:35:06] <_abc_> 32 bit dds
[14:35:16] <_abc_> okay, gone for today, thanks for the discussion.
[14:39:58] <_abc_> rue_shop3: is there some way to make an ISR __naked__ using pure C? I tried to add this attribute to the ISR proto but I got errors.
[14:40:30] <_abc_> There is only one ISR used so that is not the issue, i.e. making all naked by changing the proto
[14:41:56] <_abc_> ahh the info is in comments in avr/interrupt.h @ISR_NAKED
[14:46:37] <cehteh> _abc_: one can make it working, but with very careful coding and revieing the generated asm
[14:47:13] <cehteh> if you only operate on registers which you know you can use, never trash other registers, never introduce temporaries
[14:48:39] <cehteh> i once made it the other way around, wrote naked ISR in C, compiled it, then copypasted the generated asm into it, removing the C code and added some bits/fixes
[15:25:37] <_abc_> That's almost what I am doing but step by step.
[15:36:39] <Jartza> evening
[16:03:24] <eballetbo> hi, can anyone give some clue with a thing, i'm newbie, i've an arm connected to a xmega16d4 via spi, the arm tries to read 8 bytes but looks like the xmega only sends two
[16:03:47] <eballetbo> the spi isr is executed 2 times instead of 8
[16:04:11] <eballetbo> i'm newbie so can be something really silly
[16:13:11] <_abc_> hi Jartza , you are famous now ;)
[16:14:44] <_abc_> Please tell me, in
https://bitbucket.org/jartza/pentaveega/src/3ca3bd496da99284fc766fb3aea6d724a4cd515b/pentaveega.asm?at=master L:83 , is there no danger that the jump will jump past the ldi temp, low(RAMEND) when the jitter overhead read from tmr0 is ...
[16:14:48] <_abc_> ... 2? It can be 1 2 or 3, there should be 2 nop's there, no?
[16:15:02] <Lambda_Aurigae> eballetbo, well, with that information, I would say your neutron flow is blocked..
[16:18:40] <eballetbo> I'm using asf libraries for the first time, and i'm not sure if i configured the cpu speed correctly, can be that the system is running slow?
[16:18:47] <chisight> ^^^ exactly Lambda_Aurigae
[16:19:51] <Jartza> _abc_: I ran the code in atmel studio simulator long enough to make sure that the timer value is either 4 or 5 every time after I've stored it into my register
[16:20:16] <Jartza> so, temp contains either 4 or 5
[16:20:17] <Lambda_Aurigae> well, with spi, processor speed doesn't matter for the most part, specially as you are getting two bytes.
[16:20:48] <Lambda_Aurigae> beyond that, I've never used asf of xmega myself so I'm out of that conversation.
[16:20:50] <Jartza> so I store jitterfix -label address to ZH:ZL and add temp to it
[16:21:20] <Jartza> it jumps over 4 or 5 instructions from that point, so it jumps to either nop or the following ldi
[16:21:28] <Jartza> ingenious, isn't it
[16:22:03] <_abc_> Jartza: that's probably because there are no instructions with 3t in your entire program? Did you check?
[16:22:43] <_abc_> Jartza: and yes it is clever, am doing something roughly similar for another purpose.
[16:22:46] <Jartza> didn't check
[16:22:50] <_abc_> In inline C.
[16:23:18] <_abc_> And I have nop's there ;) But I credit you for the hint, I had it backwards last night, subtracting cycles instead of adding.
[16:23:24] <_abc_> *in inline asm in C
[16:23:27] <Jartza> anyway the jump happens when I'm just rjmp:ing in a loop
[16:23:33] <Jartza> and rjmp takes 2 clocks
[16:23:53] <_abc_> I know. I have not looked hard but your code does not contain any 3t instructions when it runs
[16:24:11] <Jartza> it doesn't matter
[16:24:20] <_abc_> My C code may contains such, so there will be 2 nops there
[16:24:34] <_abc_> *may contain
[16:24:49] <Jartza> when timer launches, it takes either 1 or 2 clock cycle to finish the current instruction (rjmp)
[16:24:57] <Jartza> and my code is ALWAYS in that rjmp when interrupt happens
[16:25:07] <_abc_> Jartza: yeah in my case that is not guaranteed at all
[16:25:07] <Jartza> it doesn't matter if anywhere else in the code there's instruction that takes 3 cycles
[16:25:10] <_abc_> It can be anywhere.
[16:25:16] <Jartza> yeah. then you need more nops :)
[16:26:26] <chisight> _abc_: i may be completely wrong, but isn't nop an 8 bit instruction? won't multiplying the count by 2 get you two cycles of nops per count? or is it really also a 16bit instruction?
[16:26:28] <Jartza> originally I also had 2 nops there before I ran the code in simulator
[16:26:28] <_abc_> So an interrupt is serviced in my case in the usual C way, via indirection table.
[16:26:45] <_abc_> chisight: there are only 16 bit instructions on avr
[16:26:46] <Jartza> chisight: there are no 8 bit instructions in avr
[16:26:48] <_abc_> none are 8
[16:26:56] <Jartza> there are some that take 32 bits
[16:26:58] <chisight> ok. then non issue.
[16:27:32] <_abc_> In 2 minutes I'm out
[16:27:38] <_abc_> Jartza: the sim you used was studio?
[16:28:13] <Jartza> yes
[16:28:17] <Jartza> it's the most accurate one
[16:28:29] <Jartza> I even installed windows to virtual machine, just for that reason
[16:28:35] <eballetbo> Lambda_Aurigae: thanks anyway to answer :)
[16:28:45] <Jartza> CALL instruction is 32-bit
[16:29:13] <Jartza> and JMP
[16:29:15] <eballetbo> seems there is a sysclk_get_cpu_hz function, it reports that is running at 2MHz
[16:29:23] <Jartza> LDS
[16:29:44] <Jartza> STS
[16:29:57] <Jartza> seems those 4 are the only ones
[16:30:01] <Jartza> all the others are 16-bit
[16:30:50] <Jartza> _abc_: I had plenty of trouble getting my vga code running in simulator, until I figured out something fun
[16:30:58] <Jartza> d'oh
[19:16:29] <Jartza> whatsup?
[21:49:20] <hypermagic> hi
