Back
[00:11:56] <chisight> LeoNerd: of course it only works at low speed.
[00:30:16] <chisight> LeoNerd:
http://electronicdesign.com/site-files/electronicdesign.com/files/uploads/2014/01/InerfaceConnectionfig7.gif might run faster, you'd have to evaluate it.
[01:10:02] rue_house changed topic of
#avr to: 8 bit atmel microcontrollers. suggest a hilight for the day to Rue_house. Todays hilight:
https://hackaday.io/project/19248-394-byte-8-color-vga-demo-with-attiny5
[08:35:10] <veek> what does he mean by chip layers? do they glue sliced wafers together? with ion implantation etc you can modify the properties of silicon and create different regions and if you do that over a large enough area you can create a layer.. but then what?
[08:37:05] <veek> as in wrt 14 nm intel processors (i know they can place wafers one on top of another)
[08:41:06] <bss36504> veek: Chips are made with layers of silicon and metal. The metal layering is a bit like a mullti-layer PCB. If you stack chips in a package usually it is called a "System-in-package", especially if the chips are different, or just "stacked die package". There are probably other names too
[08:42:33] <LeoNerd> No no... chips are made of potatoes. Everyone knows this
[08:43:53] <bss36504> LeoNerd: You're in the UK right? So that means you're talking about "crisps", right?
[08:44:19] <LeoNerd> Both
[08:44:31] <LeoNerd> crisps/chips - those thinly sliced fried things
[08:44:47] <LeoNerd> chips/fries - the bigger solid battons of potato
[08:45:01] <LeoNerd> Anyway it was only supposed to be a tiny offhand comment :P
[08:45:15] <veek> bss36504, what's the difference between a wafer and a die - it's roughly the same thing isn't it? what i'm trying to get at is, when a mask is used, can the doping add a second layer below the first (savvy?)
[08:45:22] <bss36504> Haha I know i know, i was just clarifying
[08:45:35] <LeoNerd> A wafer is that big circular disc of silicon
[08:45:48] <LeoNerd> That gets cut up into little (usually) rectangles, called dies. Each die goes into one package to make a chip
[08:45:58] <veek> right which is got by slicing the massive crystal up
[08:46:04] <bss36504> veek: The wafer consists of multiple "reticles", each reticle can contain any number of individual dies. The die itself is a single integrated circuit.
[08:46:25] <veek> ah hmm
[08:47:01] <bss36504> On single-chip wafers, each reticle usually has just one die in it. It's only in so-called "Multi-product wafers" (MPW) that they have multiple ICs/dies per reticle.
[08:47:16] <bss36504> multiple different*, that is
[08:47:45] <bss36504> As for your second question, you can't really change a lower layer after an upper layer is made.
[08:48:09] <bss36504> Technically you could grind away the upper layers to expose and modify the lower layer, but usually it's just cheaper and easier to start over for a variety of reasons
[08:48:49] <veek> okay excellent - thanks
[08:49:00] <bss36504> no problem :)
[08:49:26] <veek> bss36504, hey could you suggest a good intro text to lithography and fabrication
[08:49:57] <veek> ion implantation, vapor deposition - what exactly goes on in a process
[08:50:01] <bss36504> Can't think of one off hand. All my knowledge is from working in the industry, for the most part, and in the big scheme of things I'm relatively new
[08:50:12] <veek> ah darn hmm
[08:50:27] <veek> okay wiki reticles gave me some stuff - thanks :)
[08:51:35] <bss36504> the more "modern" the process is, the more complicated it will be. I tend to only see those complications from the design and layout side, less from the manufacturing side. For example, a 90nm process is pretty old at this point and relatively straight forward.
[08:52:30] <bss36504> pretty much just grow tranistors, apply metal, polish, expose via masks, etch away unused metal, apply a dielectric layer, repeat from step 2.
[08:53:00] <bss36504> But newer processes get into double and triple patterning, where multiple masks are used to create alternating metal tracks because the feature size is so small
[08:53:48] <bss36504> Or the new eUV (extreme-UV) photo-lithography processes where they use near-xray wavelengths generated by molten tin plasma.
[08:54:55] <veek> okay thinking.. and eating :p
[10:37:17] <hypermagic> hi
[10:41:11] <Casper> low
[12:24:01] <_abc_> Hello. Been googling and readins ds's for hours now. What IS the max core (cpu) clock rate on atmega and attiny with PLL? tyin86 tiny861 mega8u2 etc all seem to say the core max clock is not the pll max output clock. Correct? There should be no way to ...
[12:24:06] <_abc_> ... overclock the core with a pll clock no matter what, excepting as a stupid experient? (I am not into experiments).
[12:24:45] <bss36504> You can absolutely overclock with the PLL.
[12:24:54] <bss36504> It's been done on the xmega
[12:25:26] <_ami_> _abc_: i did overclock attiny85 upto 30 Mhz :)
[12:25:27] <learath> heh
[12:25:30] <_abc_> I know but I need reliable, not experimental. And I would like to see the official line (dogma) from Microchip. I mean, Atmel.
[12:25:35] <bss36504> Why do you say that there should be no way to overclock? That's silly. The whole point of the PLL is to allow designers to use a variety of input clock frequencies
[12:25:39] <learath> _ami_: did you figure out what the limit was?
[12:25:50] <_ami_> learath: _abc_:
http://amitesh-singh.github.io/avr/2016/09/04/use-ext-clock-as-hearbeat-to-avr.html
[12:26:09] <bss36504> Do those datasheets not have the handy "clock f vs core voltage" chart in them?
[12:26:18] <_abc_> Also, what is the official interrupt latency on normal atmega for tmr interrupts please?
[12:26:20] <_ami_> it was running ok (atleast blinking) up to 30 Mhz.
[12:26:27] <learath> bss36504: for outside the official range? probably not.
[12:26:36] <_ami_> i remember its not working when i did run at > 32Mhz
[12:26:40] <_abc_> bss36504: ah good idea. Of course the chart will be blank outside "official" freqs
[12:27:07] <bss36504> Well yeah so what difference does it make?
[12:27:38] <bss36504> I was questioning your assertion that "there should be no way to overclock the core with a PLL, no matter what..."
[12:27:58] <_abc_> Oh, please have the goal in view, not the comments trying to get there.
[12:27:59] <bss36504> Which doesnt make sense. Since they want you to be able to use a low frequency crystal and still have a high core speed.
[12:28:08] <bss36504> ok
[12:28:12] <carabia> you can overclock with the pll by fucking with the osc calibration register
[12:28:22] <bss36504> well you obviously wont find out-of-spec specs, thats an oxymoron
[12:28:50] <_ami_> that pll thing on attiny is ugly.. u do need some algorithm to calibrate
[12:28:55] <carabia> you can get up to ~32 MHz
[12:29:13] <bss36504> The tiny861 cover page has the speed grades listed. I would treat that as gospel as far as a maximum speed covered under the spec
[12:29:13] <_abc_> https://unitetechno.com/time-jitter-on-avr-interrupts/ this explains some of what I really need to do. Sigh.
[12:29:16] <carabia> that can be found from the DS
[12:29:28] <_abc_> bss36504: yes agreed.
[12:29:52] <carabia> then again i am not sure where the need to overclock a fucking avr stems from
[12:30:12] <carabia> again a classical example of doing things wrong
[12:30:17] <bss36504> Right so if your question is "can it be done?": yes, you can. "Will it work?": probably. "Is it reliable?": depends on your definition of reliability.
[12:30:24] <_abc_> I don't really need to overclock I need to get a cpu freq which is an integer multiple of an output I need to be as jitter free as possible.
[12:30:45] <carabia> then you probably don't want to overclock it. stay in-spec.
[12:31:34] <bss36504> Right then, as carabia said.
[12:32:50] <bss36504> I have no doubts that the silicon in the chip can handle at least 20% over spec on clock speed.
[12:33:20] <_abc_> https://github.com/cnlohr/avrcraft/blob/master/terminal/ntsc.c scary timing correction for interrupt latency jitter in ISR(TIMER1_COMPA_vect ) -- by clohr, so, good -- is there a less scary / more explained way? I need it on a non compare timer, i.e. ...
[12:33:21] <carabia> the maximum system clock you should expect is to check your voltage against the speed grade ranges listed in the ds and see what's the most you can get with the dividers provided, while staying in-spec
[12:33:24] <_abc_> ... tmr overflow.
[12:34:20] <_abc_> I assume (fingers crossed) that by using the highest speed grade chip there IS a chance that it will go quite a bit faster than published. Based on the fact that lower speed grades are selected for speed and thus guaranteed _not_ to do that.
[12:34:42] <_abc_> Anyway, thanks for answering on the overclocking issue. Now the latency issue. Any ideas?
[12:37:14] <_abc_> In my case, I should simply consult the timer, and see if I am 'early', add a few nops to make it equal run time I guess. Correct? That's how it's done on PICs iirc. I used that some years ago, so, in theory I know how to do it. Now, for practical issues.
[12:38:52] <_abc_> interrupt latency is a minimum of 6 cycles + whatever delay is incurred due to interrupting on instructions longer than 1 cycle, right?
[12:46:54] <bss36504> What the heck are you making that needs cycle accurate interrupt latency?
[12:47:00] <_abc_> dds
[12:47:06] <_abc_> low frequency but dds
[12:47:24] <bss36504> Why AVR then? Why not just use a "bigger hammer"?
[12:47:33] <bss36504> Go get some 100Mhz ARM
[12:47:38] <bss36504> or an FPGA
[12:47:44] <_abc_> I need to do it in a week and there is a cost problem too and tooling
[12:47:52] <bss36504> oy ffs
[12:48:08] <_abc_> Usually I use a low frew analog devices adxxxx dds but now I need to cut corners.
[12:48:12] <_abc_> *freq
[12:48:23] <_abc_> This is v3 of a project which never used avrs so far.
[12:48:48] <bss36504> Was your boss like "hey _abc_ I need you to make a DDS with the worst possible microcontroller choice for. Oh and you have a week."
[12:49:09] <_abc_> Well the avr replaces a pic and an ad dds. Win.
[12:49:22] <carabia> in that case an arm will most likely cost you less. Win.
[12:49:51] <_abc_> Have to tool for arm 1st. I can do it with pic32 which is also in range $wise
[12:50:03] <_abc_> The previous pic was 16f
[12:50:06] <bss36504> yeah I usually dont care about cost but ARM will be cheaper and faster. Hell, even an M0 will be >50% faster than an avr
[12:50:15] <bss36504> Do you not have an Atmel ICE?
[12:50:20] <carabia> and which avr is pin compatible with a pic?
[12:50:28] <bss36504> It already supports all the ARM chips that atmel makes
[12:50:29] <carabia> don't you need to tool for the avr, too?
[12:50:37] <_abc_> nope. I have only low end avr setup. stk200 clone usbasp and avr-gcc
[12:50:43] <bss36504> oh ffs.
[12:51:01] <carabia> get a fucking stlink clone then, if we're going ghetto
[12:51:04] <_abc_> So cut out the upgrade talk, it will happen some time, but not now.
[12:51:06] <bss36504> are you selling this as a product? Cant you justify the $100 investment in proper tooling?
[12:51:14] <Emil> _abc_: if you code in c
[12:51:22] <_abc_> no, it is very low unit count and almost no money
[12:51:25] <Emil> The interrupt latency is 20 cycles
[12:51:32] <Emil> and overheard 30
[12:51:34] <Emil> 40*
[12:51:40] <Emil> overhead*
[12:51:41] <_abc_> Emil: assume naked and asm interrupt
[12:51:48] <Emil> ah
[12:51:52] <_abc_> where does the 20 come from?!
[12:52:10] <Emil> Then it is around 4 to 6
[12:52:15] <_abc_> http://www.avrfreaks.net/comment/916157#comment-916157 is this reasonable?
[12:52:24] <bss36504> I would assume the 20 is from pushing all the stuff onto the stack?
[12:52:25] <Emil> _abc_: pushing the registers
[12:52:29] <Emil> yeah
[12:53:00] <_abc_> Oh, forget that, I will not be pushing anything, using dedicated global regs for isr, isr code is very short. 32 bit add with carry, set output, done
[12:53:38] * _abc_ thunders against mcu makers who turn out oodles of peripherals but NOT ONE dds meaning simply wide accumulator + phase delta term + adder
[12:53:45] <Emil> _abc_: what part of coding in C do you not unzerstand? ;)
[12:54:36] <_abc_> Emil: I don't have a problem with coding in C I am just used to set some pragma and have the compiler let me do things in naked mode in the isr, in C, without dropping to asm. But I can handle it, I will read up and compile some exmaple and see what ...
[12:54:40] <_abc_> ... the output is.
[12:55:16] <_abc_> Setting pragma naked for isr in avr-gcc simply removes the push pop prologues right?
[12:55:30] <antto> NSFW that link, the isr was nekkid!
[12:56:19] <bss36504> antto: :O
[12:57:07] <bss36504> _abc_: I dont know that avr-gcc supports pragma, it does support __ATTRIBUTE__ though
[12:57:18] <_abc_> I know
[12:58:41] <_abc_> http://www.avrfreaks.net/forum/help-interrupt-jitter?page=all okay the thread is useful, I now have some clues. Sounds like I'll do the simple look-at-tmr-lsbyte-and-jump-into-nops-to-compensate thing
[12:59:26] <_abc_> tmr lsbyte access from asm in atmega is one cycle or two?
[13:00:09] * antto doesn't speak asm
[13:03:42] <_abc_> lds r16,TCNT1L ;2 <- 2
[13:04:20] <_abc_> Ah so the timer needs to run without prescaler
[13:04:53] <_abc_> What if I start 2 timers, one does the interrupts, with prescaler, the other runs with no prescaler. If I clear the prescalers after starting the timers, will the timers be in sync?
[13:05:06] <_abc_> The prescaler less timer would be used for timing correction
[13:07:10] <antto> just put two avrs, and de-phase their clocks with an inverter ;P~
[13:08:05] * _abc_ shows antto nekkid chicks to keep him busy
[13:09:06] * antto only sees imperfections
[13:12:04] <_abc_> So on mega328, if I use the GTCCR.TSM bit I can sync the tmr0 and tmr1's then start them together as above, one prescaled, one not?
[13:12:44] <_abc_> Rephrased: since clearing psc in sync mode does not affect the timer which does NOT run on prescaler, I should: 1) set
[13:15:42] <_abc_> both tmr0 and tmr1 to prescaled clock, assert TSM, set both timers to 0, then switch tmr0 to non prescaled mode, it starts counting immediately, then release TSM. This will introduce a delay between the 2 timers, between the moment when tmr0 is set to ...
[13:15:46] <_abc_> ... non psc mode, and when tmr1's prescaler starts counting due to TSM. I have to deal with this fixed delay as a constant. Assume this section is coded as critical code with ints off so timing is constant and predictable. Does this sound okay?
[13:17:29] <_abc_> Hmm for this particular project I can use tmr0 in ctc mode, it needs to count to 64 with no prescaler, so I can get away without the hack above. Still, as a discussion, is the above considered reasonably feasible?
[13:18:41] <_abc_> The goal is to have tmr0 and tmr1 almost perfectly synchronized even though tmr1 would run on prescaler and tmr0 not so, to permit using tmr0 as cycle accurate counter when correcting interrupt jutter in tmr1 overflow interrupt?
[13:20:52] <_abc_> ?
[14:03:21] <_abc_> Okay, this is one of my 2nd (:) avr asm programs, not written as inline C, comments please? It probably has errors, but is the idea roughly okay? Remember I did this before with PIC and Z80 and MCS51 and god knows what else. I'm an older guy. ...
[14:03:25] <_abc_> ...
http://188.25.6.236:8881/mypaste/a0daa060507db22a41cf/tmr0_isr_jitter_comp_v0.asm
[14:04:21] <_abc_> note: scary url is in my laptop, no comments about "strange country ip". Also, sfw.
[14:05:30] <_abc_> <aside>I am surprized there is no direct way to manipulate PC on avr but it makes sense, since it is pipelined. On pic etc one simply adds W to PCL to do a computed jump.</aside>
[14:05:49] <_abc_> (pic is not really pipelined, pic 16f etc isn't)
[14:07:41] <_abc_> highlight me when you have a comment, doing something
[14:11:42] <_abc_> daft question #1: when computing a jump like that, do I have to multiply the offset by 2 because avr program addresses are always word aligned?
[14:11:47] * _abc_ assumes yes
[14:29:57] <_abc_> http://188.25.6.236:8881/mypaste/a0daa060507db22a41cf/tmr0_isr_jitter_comp_v1.asm - minor errors fixed
[14:30:53] <_abc_> I as sure there is a much shorter way to do this, once the exact inherent delay expected at FUDGE is known and a few strategically placed tests and branches fix it. Probably reducing the code to 10 or so Ncyc
[14:33:10] <rue_house> what ya up to?
[14:33:34] <_abc_> hmm? trying for a low jitter low frequency dds
[14:33:41] <_abc_> with cheap and cheezy means
[14:33:46] <rue_house> digital delay?
[14:33:54] <_abc_> freq. synthesis
[14:33:58] <rue_house> ah
[14:34:02] <rue_house> what range?
[14:34:03] <_abc_> The problem is interrupt jitter.
[14:34:09] <_abc_> under 50kHz
[14:34:19] <rue_house> what is your clock source?
[14:34:25] <_abc_> 20MHz
[14:34:32] <rue_house> yea, from a what? :)
[14:34:35] <_abc_> Or close to that
[14:34:45] <_abc_> canned osc or xtal, don't know yet
[14:34:52] <rue_house> oh
[14:35:00] <rue_house> your having interrupt timing issues?
[14:35:06] <_abc_> jitter issues
[14:35:29] <rue_house> 1 clock cycle?
[14:36:03] <rue_house> your interrupt looks good, not even any conditional branches
[14:36:08] <_abc_> How does SBIC know whether to skip 1 or 2 words?
[14:36:18] <_abc_> rue_house: yeah but that is just a skeleton
[14:36:26] <_abc_> and FUDGE needs to be determined
[14:36:38] <_abc_> Oh the core steps over the next instruction I see.
[14:36:55] <_abc_> I thought it would be coded into the opcode but it's deduced by the core at runtime
[14:37:12] <rue_house> well, the timing of the interrupt will be +-1 cycle depending on the instruction thats hit when the interrupt occurs
[14:37:29] <_abc_> it will be exact after that code, I hope
[14:37:56] <rue_house> if you hit an interrupt on the first cycle of a 2 cycle op, the second cycle finishes before the interupt is processed
[14:38:05] <rue_house> so your late a cycle
[14:38:18] <rue_house> what duty?
[14:38:19] <_abc_> As long as TCNT0 keeps track of Ncycs I'm good.
[14:38:26] <_abc_> duty?
[14:38:32] <rue_house> 50% output?
[14:38:40] <_abc_> Oh not relevant there are filters afterwards
[14:38:53] <rue_house> yea, but is it?
[14:38:58] <_abc_> output is not 50% and never will be, the dds nature creates jitter, itself
[14:39:15] <rue_house> ok, but steady state, 50%?
[14:39:42] <_abc_> I don't know if you are familiar with how dds works... it sort of "interpolates" the output frequency as the phase error fractional part sums in the accumulator.
[14:39:49] <_abc_> So it is not 50%, no
[14:40:02] <rue_house> but its not 90% or 10%
[14:40:15] <_abc_> It will be close to 50% most of the time
[14:40:20] <rue_house> ok
[14:40:23] <_abc_> say between 33 and 66 always
[14:42:35] <rue_house> so whats measuring your phase error?
[14:43:02] <_abc_> Once one knows the exact value of FUDGE one can write much more specific code for it, using branch on condition and rjmp, thus not needing the ugly math and push pops which take up the larger part of the code.
[14:43:19] <_abc_> rue_house: say what? Oh it makes a line on a specan eventually.
[14:43:42] <_abc_> After traversing a lot of things.
[14:43:52] <_abc_> That's not relevant, really. The jitter is.
[14:44:42] <rue_house> whats your main loop look like?
[14:44:53] <_abc_> Empty.
[14:44:57] <rue_house> heh
[14:45:09] <rue_house> a 2 cycle jump to the same address?
[14:45:28] <_abc_> Except it read the serial receive flag and copies from serial to buffers then sets the dds phase delta atomically
[14:45:34] <rue_house> start: rjmp start ?
[14:45:44] <rue_house> ah
[14:45:49] <_abc_> rue_house: the main loop does not exist yet, this will be a __naked__ isr in a C program
[14:46:14] <rue_house> hmm
[14:48:02] <_abc_> I don't care whether setting the freq from serial interferes with the output (it will not, really, since only the tmr0 ofl interrupt will be on, and setting will be atomic
[14:48:36] <_abc_> There's already a project for this sort of thing using an avr, and serial control, I have not looked at the code, will do that too.
[15:16:59] <_abc_> Wow slow Friday. People must be @home with beers already
[15:18:52] <bss36504> Just busy working on this absolute motherfucker of a program at work.
[15:19:08] <_abc_> :) No complaints. Is it a stm32 program? >;)
[15:19:19] <bss36504> Nah its a memory compiler
[15:19:44] <bss36504> take small blocks of layout >> compile them into SRAMs of various sizes.
[15:19:59] <_abc_> rue_house:
http://codeandlife.com/2012/03/13/fast-dds-with-atmega88/ simplest (and fastest) dds in avr I can find.
[15:20:32] <_abc_> bss36504: small blocks of layout of what? Is this not like a fpga without a fpga? LUT based system?
[15:21:10] <bss36504> No these are full custom blocks that make up an SRAM. Well a TCAM to be more specific.
[15:23:45] <bss36504> _abc_: that guy in your link has a heck of a name, Joonas Pihlajamaa. I like the way that tickles my brain.
[15:24:07] <_abc_> Nah, he's a Finn. I'm in Europe and I'm used to funny names.
[15:24:24] <bss36504> Ah that explains it haha
[15:29:56] <_abc_> http://xkcd.org/1785/ 100% correct
[15:33:06] <carabia> i see xkcd, not worth moving my hand to click it
[15:33:25] * _abc_ removes the c from carabia and sends the remainder home
[15:34:23] <carabia> they're sure shipping a lot of the carabia sans c over here to europe
[15:35:05] <_abc_> <off topic>wow
http://www.dailymail.co.uk/news/article-4116878/A-fox-blocks-Animal-frozen-ICE-falling-river-Germany-blizzards-freezing-weather-claim-60-lives-Europe.html
[15:35:28] <carabia> wow sick, thanks.
[16:07:14] <bss36504> _abc_: looks like they ran that fox through the renderer for minecraft
[16:07:52] <_abc_> You are cruel. Remember that happened not too far away from where I was at the time, in another country.
[16:08:41] <_abc_> Meaning, I felt like that fox for a few hours 3-4 days ago. -20 degC is not amusing, even if you shovel snow to keep warm / to avoid the snow killing the furnace by clogging a chimney
[16:15:41] <carabia> well. That's nothing but unimaginable stupidity of the owner of said house
[16:17:01] <carabia> you need that hat thingy for the chimney. If that doesn't help, then well light a god damn fire. don't shovel, be smart
[16:18:48] <carabia> i got a nasty flu a while ago and the cold front was here, it was kind of funny when the snot borderline freezes in your god damn nose
[17:11:23] <_abc_> carabia: the chimney is horizontal and nearly at ground level, for that one we worried about. Ground floor's furnace.
[17:11:35] <_abc_> Each floor has one, some have two ;)
[18:02:54] <hypermagic> <bss36504> Do those datasheets not have the handy "clock f vs core voltage" chart in them? - they do have a graph VCC/cpu freq that is flattened out at 5V, you continue that line and install a heat-sink ;)
[18:06:20] <hypermagic> at some point tho cpu will start to make mistakes in computing, that is where you need to consider the amount of safety margin for the frequency and voltage you will overclock to, if you use lower than suggested voltage for given cpu frequency that will cause the cpu to make faults too, it is called undervolting
