#eevblog - 2019-07-29 - AustNet Archive Project

// #eevblog — 2019-07-29

1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
« 2019-07-28 2019-07-30 »
51:06 Join: Wisefire ([email protected]) to #EEVblog
52:29 Quit: Wisefire ([email protected]) Quit: http://www.kiwiirc.com/ - A hand crafted IRC client
52:12 Join: Wisefire ([email protected]) to #EEVblog
53:35 Quit: Wisefire ([email protected]) Quit: http://www.kiwiirc.com/ - A hand crafted IRC client
51:11 Join: user_ ([email protected]) to #EEVblog
52:59 Join: Wisefire ([email protected]) to #EEVblog
53:00 Quit: HexicPyth ([email protected]) Ping timeout: 121 seconds
54:22 Quit: Wisefire ([email protected]) Quit: http://www.kiwiirc.com/ - A hand crafted IRC client
51:11 Join: Wisefire ([email protected]) to #EEVblog
02:51 Quit: Wisefire ([email protected]) Quit: http://www.kiwiirc.com/ - A hand crafted IRC client
45:10 <DHess_US> https://youtu.be/jBN13jxOYZ0?t=417
02:13 Join: Wisefire ([email protected]) to #EEVblog
03:37 Quit: Wisefire ([email protected]) Quit: http://www.kiwiirc.com/ - A hand crafted IRC client
02:59 Join: Wisefire ([email protected]) to #EEVblog
35:55 Join: ThunderSqueak ([email protected]) to #EEVblog
35:55 Mode: (by ChanOP) +o ThunderSqueak
53:45 Topic Is: Official IRC channel of the EEVBlog - www.eevblog.com
53:45 Set By: (Halcyon) on: Mon Dec 17 17:18:40 2018
56:30 Quit: user_ ([email protected]) Ping timeout: 121 seconds
29:16 Join: user_ ([email protected]) to #EEVblog
04:01 Join: soundcloudrapper ([email protected]) to #EEVblog
04:11 Part: soundcloudrapper ([email protected]) from #EEVblog
53:25 Join: guardeiro ([email protected]) to #EEVblog
53:58 <guardeiro> g'day
01:22 <guardeiro> I have a project going in which a 10 bit number stored in an array needs to be display on the gpio port at the event of an external trigger.
02:57 <guardeiro> at the next trigger to next array number is loaded to the gpio port, and so on
05:48 <guardeiro> I am using an arduino due (SAM3x8E) at the moment with an ISR. I tried to remove as much of the overhead the arduino code generates and was able to get down to ~600ns from the moment the arduino due receives the triger signal to it process the interrupt and display the number on the port.
08:43 <T3sl4> that's pretty good for arduino
29:53 <DHess_US> If you can, preload the next number into a shadow register as the last step of the ISR. Then on the next trigger, a new output can be loaded without looking it up.
30:19 <DHess_US> Or precompute the next number, whatever.
31:13 <DHess_US> Some hardware might allow you to use the output register to hold the value so the ISR only needs to stobe the latch.
31:54 <DHess_US> Or use an external latch to bring the latency down to nanoseconds.
31:55 <T3sl4> DHess_US, any ideas about how arduino sets up ISRs?
32:10 <T3sl4> any internal logic, callback?
32:31 <T3sl4> i haven't looked at any of it, dunno if you have either?
32:48 <DHess_US> That's on the software side. AVR by itself has low interupt latency like a PIC.
33:04 <DHess_US> I have no idea what the AVR software does.
33:11 <T3sl4> SAM tho
33:49 <T3sl4> ARM will spend some cycles fetching the ISR and all that, i think, but it'll be about as fast in real time
34:21 <T3sl4> assuming the ISR isn't fucking around, which isn't a good bet in this case
34:25 <DHess_US> Depends on the ARM. If you have caches and stuff everything goes out the window plug you have registers to save to the stack.
35:57 <DHess_US> To look at it another way, something like a PIC runs at 20 MHz with a 4 phase clock or something. An equivalent ARM runs at 50 MHz but with a longer pipeline, it doesn't acheive lower latency.
36:29 <DHess_US> And that is excluding saving registers if needed. I've always thought compilers were dumb about that.
36:42 <T3sl4> i'm thinking the SAM in question runs in the neighborhood of 80-160MHz, though i'm not terribly familiar with the family, and obviously it can be anything lower, too
36:56 <DHess_US> If you know what registers were used in the ISR, then you know which need to be saved.
37:04 <T3sl4> yeah, compilers are dumb about registers in ISRs, they follow the ABI and that's about it
37:25 <DHess_US> I studied the SAM series years ago and don't remember.
38:13 <T3sl4> they also tend to prefer using registers freely, rather than trying to reduce the number of saved registers
42:16 <DHess_US> Would need a compiler directive to mark routines for that.
43:15 <DHess_US> TI had some neat compilers once for DSP that did things like that.
44:06 <DHess_US> They also automatically tracked radix of fixed point math.
46:57 <DHess_US> Sometimes I'm tempted to write a language and compiler for a real time safety type language.
57:16 <T3sl4> you would, but you're a little too rust-y
58:13 <DHess_US> Does rust support radix tracking?
58:18 <DHess_US> Then no.
58:19 <T3sl4> no clue
58:24 <DHess_US> It doesn't
58:41 <DHess_US> I think the only langages which do are non-standard C compilers.
59:16 <DHess_US> Also, if your language doesn't produce a x+1 bit result from x bit sources, I'm not interested.
59:42 <DHess_US> And if multiply and divide do not produce 2x bit results, I'm also not interested.
59:43 <T3sl4> mine produces 2x bit results
59:50 <DHess_US> From an add?
00:05 <T3sl4> from an operator
00:11 <DHess_US> Eww
00:19 Quit: ThunderSqueak ([email protected]) Quit: Leaving
00:22 <T3sl4> you hadn't said which ones
00:53 <DHess_US> I want a CPU which has a flags register to save state for every written register.
02:11 <guardeiro> sorry, morning coffee break
02:14 <guardeiro> this is the code
02:16 <guardeiro> https://pastebin.com/4eaDPBDn
03:00 <guardeiro> my question is if any one of you guys has any idea on how to reduce the overhead even more
03:12 <DHess_US> I gave my suggestion.
03:28 <DHess_US> Load or precompute the *next* value at the end of the ISR.
04:32 <T3sl4> isr is never read
05:13 <T3sl4> or is that to force read an interrupt flag? in that case it doesn't need an lvalue
05:36 <guardeiro> yeah just read through the histry, thanks
06:09 <guardeiro> the line
06:09 <guardeiro> uint32_t isr = PIOC -> PIO_ISR;
06:09 <guardeiro> seems to be necesary in order to clear the flag
06:43 <T3sl4> btw set voltages_index = sizeof(voltages_binary) / sizeof(voltages_binary[0])
07:12 <T3sl4> you can just PIOC->PIO_ISR; and discard the return value
08:22 <guardeiro> T3sl4: thanks
08:22 <guardeiro> got that in the "real" code
08:36 <T3sl4> ah
08:43 <guardeiro> T2sl4: "PIOC->PIO_ISR;" true, thanks
09:09 <guardeiro> another question. does something like a dma functionality exist for memory->GPIO?
09:30 <T3sl4> what remains, it seems: RTFDS, and read the output (assembly)
09:43 <T3sl4> DMA? also RTFDS :)
09:54 <T3sl4> Read The Friendly? Datasheet
11:20 <guardeiro> i did but im new to arm, read it but couldnt find anything. STM32 seems the functionality but wasn't sure if i had missed something
11:54 <T3sl4> i haven't looked at either, long enough to know what differentiates the Atmel and ST families
15:48 <K> hello
15:58 <guardeiro> do you think theres a lot to gain if everythings written in assembler? i'm not very experienced so i fear the compiler is producing more efficient code anyways
16:24 <T3sl4> i said read, not write
17:28 <T3sl4> you have no reason to trust the compiler about anything whatsoever, if you've never read its output to verify it's doing what you told it to do
17:37 <T3sl4> trust but verify :)
18:05 <guardeiro> okay
18:22 <K> imho writing in assembler makes sense in 2 cases - you want to learn some specifics, or you KNOW the compiler does stupid shit
19:09 <T3sl4> there is very little need to /write/ assembler these days, but being literate enough to read it, is still good value
19:25 <guardeiro> sure, thanks
22:04 * Halcyon mounts T3sl4 
22:23 <Halcyon> $ nano /etc/fstab
22:24 <Halcyon> :P
22:25 <T3sl4> oooh, how decorative
22:40 <K> run fsck for a good measure too
22:53 <Halcyon> I'd love to fsck T3sl4
24:20 <K> (and what is with that "nano" nonsense?")
24:28 <Halcyon> :P
24:31 <Halcyon> I hate vi
25:11 <rust_collector> heh, why?
25:33 <Halcyon> I mean, I get the purpose, but it's overly complex nature isn't really needed on almost all machines these days
25:52 <Halcyon> I can count on one hand the number of times vi was the only options
25:56 <Halcyon> *option
26:32 <rust_collector> I do not use it,, because I can not remember all the cool things, so I use nano, or...something. But I do not hate vi
28:09 <K> the main thing you have to remember is "Esc,:wq"
31:39 <rust_collector> emacs is the thing I hate, because I just do not get how to use it at all, lol
33:06 <rust_collector> Oh great. boss is sending text messages, so I guess it is monday
36:45 <DHess_US> Part 15 jammer. Just saying.
38:36 <rust_collector> Yeah, I have a good ignore function built in, it is ok
38:56 <rust_collector> I will just call him when I know he is on his way home
40:00 <DHess_US> Or get a Faraday shield bag.
41:58 <Halcyon> Or just turn off the device?
43:54 <rust_collector> I find it is more effective to ignore it, so he can sit there and text and call as much as he wants, then call him back when I feel like it. Usually around 18, when I know he is on the road going home, or around 3 in the morning
45:38 <DHess_US> No, the device needs to be left on for plausible deniability.
46:09 <rust_collector> hehe.
47:41 <rust_collector> well, there is nothing in my contract about being available all the time. It is my day off, so... I don't have to answer, unless he wants to make a deal about that again.
49:26 <rust_collector> we used to count answering the phone on a day off, as the same thing as going to work, and them sending me home, because there is nothing to do, so 3 hours paid. I don't think he wants that again
50:04 <T3sl4> but he still calls?
50:27 <T3sl4> why would you make that determination about his judgement?
50:48 <rust_collector> some times. today he is just sending text messages
51:12 <T3sl4> that's not very different
51:37 <T3sl4> but it depends, i guess
51:38 <rust_collector> it is different enough that I can read them on wednesday morning
40:59 * DogWomble peers in
41:24 <DogWomble> anyone up for a game of Cards Against Humanity? Ampera? T3sl4?
58:58 <K> carbs against humanity
59:07 <K> or crabs.
59:18 <rust_collector> I can do some carbs
05:55 <Halcyon> There is a cream from those
06:05 <Halcyon> Or you could shave it all off I suppose?
12:06 <DogWomble> df -h
49:49 <steve30> Halcyon, I had my physiotherapy appointment last week
55:49 <Halcyon> How was it?
55:50 <Halcyon> :P
56:21 <steve30> I got a nice leg massage :)
56:26 <Halcyon> Oooer :P
06:17 <guardeiro> this is btw the assemlby code the arduino ide generatet regarding the ISR: https://pastebin.com/G5mnc3qb
07:37 <guardeiro> is there something obvious that would decrease the interrupt response time?
24:15 <Ampera> guardeiro, what sort of interrupts, hardware or software?
27:51 <guardeiro> hardware interrupt
28:01 <guardeiro> on a SAM3X8E
28:09 <Ampera> So reduce time from hardware interrupt being fired to code at the vector being fired?
28:22 <guardeiro> yes
28:32 <guardeiro> this is the code
28:33 <guardeiro> https://pastebin.com/4eaDPBDn
28:57 <Ampera> Regardless, if interrupts work the same way there as they do on most other systems, you can't.
29:11 <Ampera> I believe there are levels of interrupts on some systems, meaning the priority to how they get handled is different
29:24 <Ampera> but the general idea is an interrupt, well, interrupts the system, and will fire as fast as it can
30:45 <guardeiro> so de docs say that the highest priority is 0, which is set with the line NVIC_SetPriority(PIOC_IRQn, 0);
31:04 <guardeiro> so theres not much else i can do i guess
31:29 <Ampera> Yeah, most systems should handle a high priority interrupt as jumping as soon as the CPU gets it.
Search this day's buffer: