#avr Logs
May 02 2017
#avr Calendar
09:01 AM polprog: the good news is that th camera works fine
09:09 AM Emil: Hmm
09:09 AM Emil: How should I go about finding some lipos for my led light
09:10 AM Lambda_Aurigae: google
09:12 AM Emil: I might scrape hobbyking
09:16 AM Lambda_Aurigae: used to have a battery site that I bought batteries from years ago
09:16 AM Lambda_Aurigae: but forgot the name.
09:18 AM Chillum: the only places I have found with reliably speced batteries have been RC hobby stores(not all of them) and vape stores for 18650s(again not all of them)
09:18 AM Chillum: as those are the places where the customers will notice if they are lied too
09:18 AM Lambda_Aurigae: yup.
09:18 AM Chillum: any company that just incidentally sells batteries tends to pass on whatever BS they got cheapest
09:19 AM Lambda_Aurigae: this place I used to order from had good prices and good product...and you could buy in bulk.
09:26 AM specing: Lambda_Aurigae: nkon?
09:27 AM Lambda_Aurigae: nope
09:27 AM LeoNerd: Totally random question: Anyone here actually using Rust on an AVR chip yet?
09:27 AM Lambda_Aurigae: it was "battery SOMETHING"
09:27 AM Lambda_Aurigae: LeoNerd, I prefer my electronics non-rusty
09:28 AM LeoNerd: I suddenly wonder whether Rust can be taught about the two kinds of memory space on AVR, and do the pgm_read_byte() et.al. itself, rather than my having to think about it
09:28 AM LeoNerd: So if I had a pointer into program memory, I could just dereference it, and the compiler would do the right thing
09:28 AM Lambda_Aurigae: probably.
09:29 AM Lambda_Aurigae: would require some major compiler rewrite/addon
09:31 AM specing: polprog: lol I thought TME was cheap
09:31 AM specing: polprog: turns out all the prices were in GBP and without VAT
09:31 AM polprog: kek
09:32 AM polprog: yeah, that VAT part got me too
09:32 AM specing: LeoNerd: you missspelled Ada
09:32 AM LeoNerd: :P
09:37 AM polprog: the only composite monitor i have is crap: https://drive.google.com/file/d/0B7nrducTAtMTSGF1STJvY1kyVjg/view?usp=sharing
09:37 AM polprog: but hey, i fixed a camera!
09:37 AM Emil: LeoNerd: RUST is a fad
09:37 AM Chillum: aren't all composite monitors crap?
09:37 AM Lambda_Aurigae: rust is burnt iron
09:37 AM Emil: LeoNerd: Everything it promises can be provided by compiler addons
09:38 AM Emil: And I find it god damn stupid that the effort is not invested there
09:38 AM Lambda_Aurigae: it looks like C with some addons.
09:38 AM Emil: The syntax is horrible
09:40 AM Emil: C is far superior in what it provides
09:41 AM Emil: Though, again, C types are stupid
09:41 AM Emil: s8, s16, s32, s64, u8, u16, u32, u64, f32, f64 are kawaii :3
09:41 AM LeoNerd: That word again
09:42 AM Lambda_Aurigae: isn't that an island in the pacific?
09:42 AM Emil: >char Unicode scalar values like 'a', 'α' and '∞' (4 bytes each)
09:42 AM Emil: Rust, why must you into retardion?
09:43 AM Emil: Why have tuples when you already have arrays
09:43 AM Emil: why have bool when you have u8
09:43 AM Emil: usize and isize are good, though
09:43 AM LeoNerd: I like the information to the reader of the code, that it's a boolean
09:43 AM LeoNerd: Useful in .h files
09:46 AM specing: < Emil> s8, s16, s32, s64, u8, u16, u32, u64, f32, f64 are kawaii :3
09:46 AM specing: I remember making my own vimsyntax file for highlighting those
09:47 AM specing: < Emil> Why have tuples when you already have arrays
09:48 AM specing: s/arrays/structs
09:48 AM specing: tuples are just syntax sugar/anonymous structures
09:49 AM specing: < Emil> why have bool when you have u8
09:49 AM specing: so that the compiler can freely choose how to store true/false values
09:58 AM Emil: Hmm, that's true
09:58 AM Emil: using int is _far_ faster than char on x64
09:59 AM Emil: Also arrays and structs are not the same thing
09:59 AM Emil: Whereas arrays are always of known size struct size can way due to aliasing
10:00 AM Lambda_Aurigae: you can have an array of structs containing arrays and pointers to arrays!
10:13 AM Lambda_Aurigae: http://i.imgur.com/d5H7E7H.jpg some people will do anything to avoid using an arduino!
10:19 AM Emil: :D
10:20 AM Emil: Motorized pots are kewl
10:20 AM * LeoNerd has four 100mm motorised linear faders :)
10:20 AM LeoNerd: Gonna build me a lighting desk
10:20 AM LeoNerd: Even at £18 a pot, *significantly* cheaper than buying a £6000 monster
12:16 PM polprog: heh, i made a monster
12:16 PM polprog: i put an IEC socket to that camera
12:16 PM polprog: i'll show you in a mo
12:18 PM polprog: https://drive.google.com/file/d/0B7nrducTAtMTMDEtZDZNdVplYUU/view?usp=drivesdk
12:21 PM polprog: there's 20cm of mains cable stuffed inside, not seen on the pic
12:23 PM aczid: looks neat :)
12:24 PM polprog: gives quite a clear BW composite picture
12:24 PM polprog: i'll get another one next weekend
12:24 PM polprog: maybe with the lens too
12:32 PM xentrac: 14:29 < Emil> Whereas arrays are always of known size struct size can way due to aliasing
12:32 PM xentrac: this sounds like you're trolling ;)
12:32 PM xentrac: 14:28 < Emil> using int is _far_ faster than char on x64
12:32 PM xentrac: okay, yes, definitely trolling
12:34 PM polprog: i dont see why would a char be faster on an x64, but an int64_t would be slower on an 8-bitter
12:34 PM xentrac: 10:00 < specing> try that in Ada and your code will not compile at all
12:34 PM xentrac: yes, this is in fact an advantage of Ada
12:37 PM xentrac: LeoNerd: your idea about Rust is interesting; I don't know, but that does seem like the kind of thing it would be good at
12:37 PM LeoNerd: Mhmm. I'm kindof curious to try it out, anyway
12:37 PM xentrac: I don't think Rust has been ported to any small machines
12:39 PM LeoNerd: Most of my entire point was that AVR -> LLVM -> Rust is a thing
12:41 PM xentrac: maybe? I mean avr-llvm has been mainstreamed but that doesn't imply that everything built on llvm will automatically work on AVR
12:41 PM LeoNerd: I didn't say "automatically"
12:41 PM xentrac: am I misunderstanding what you mean by "is a thing"?
12:42 PM LeoNerd: You can't just take any old arbitrary C program and run it through avr-gcc and expect it to work either
12:42 PM Lambda_Aurigae: how does one setup an LLVM-AVR toolchain?
12:42 PM xentrac: I agree that Rust would be super helpful for AVR stuff
12:42 PM Emil: polprog: you can test it yourself
12:42 PM Emil: polprog: read data from a fd to an array
12:43 PM Emil: as ints or as chars
12:43 PM Emil: ints are a lot faster
12:43 PM Emil: xentrac: mate pls
12:43 PM xentrac: oh, you mean ints are less than four times slower? :)
12:43 PM Emil: xentrac: on x86/64
12:43 PM xentrac: detecting problems at compile time becomes more important when all you can do at run time is, say, blink an LED
12:43 PM Emil: xentrac: invest in reading comprehension
12:44 PM xentrac: Emil: you're talking nonsense; the problem is not my comprehension ;)
12:44 PM Emil: mate wat :D
12:44 PM Emil: x86/64!=8-bit avr :D
12:44 PM xentrac: certainly true!
12:44 PM Emil: xentrac: well then
12:44 PM Emil: you can time it yourself
12:45 PM xentrac: I have!
12:45 PM xentrac: incrementing a char on amd64 *is* slightly slower than incrementing a long
12:45 PM Emil: native register size operations are pretty much always faster than special ones used to go through byte size
12:45 PM xentrac: int is not native register size on either avr or amd64
12:45 PM Emil: siigh
12:45 PM Emil: xentrac: y must u troll
12:45 PM Emil: oikea mestarirölli
12:45 PM xentrac: I mean I don't know of any ILP64 amd64 platforms; they're all LP64 AFAIK
12:46 PM xentrac: other issue: when you're reading data form a file descriptor to an array, you can't do it as either ints or chars; you do it by invoking read(2) with a pointer and a buffer size (measured in bytes)
12:47 PM xentrac: the OS will typically copy the data into your buffer in fairly large chunks
12:47 PM Emil: xentrac: mate can you even into basic linux operations?
12:47 PM xentrac: int is not native register size on either avr or amd64p correcting you
12:47 PM xentrac: oops, mispaste
12:47 PM xentrac: so you're talking nonsense at such high density that I can't keep up correcting you
12:47 PM Emil: why troll though?
12:48 PM xentrac: s/form a/from a/
12:48 PM xentrac: You tell me. I guess you must think it's fun?
12:48 PM Emil: also very hostile hmm
12:48 PM Emil: are you having a bad day?
12:48 PM xentrac: yeah, actually. I have a kindof painful cold
12:48 PM xentrac: thanks for asking :)
12:49 PM Emil: hmm, well get better soon :)
12:49 PM xentrac: thanks :)
12:49 PM xentrac: anyway I think you're confused about a lot of basic things here
12:49 PM * Lambda_Aurigae has a terminal case of bastarditis.
12:49 PM xentrac: first of all, on amd64 (at least on Linux and Win64) ints are not 64 bits
12:49 PM xentrac: they are 32 bits
12:49 PM Emil: Do you know any good sound to colour algorithm?
12:49 PM APic: Uh oh.
12:50 PM Lambda_Aurigae: Emil, most involve LSD
12:50 PM Emil: Lambda_Aurigae: hehe, I wish
12:50 PM xentrac: That's what "LP64" means
12:50 PM xentrac: longs and pointers are 64 bits; ints are not
12:50 PM Emil: Lambda_Aurigae: I came up with a rather good one but it's rather hectic
12:51 PM xentrac: cool!
12:52 PM Emil: https://www.youtube.com/watch?v=-t3O3YiFnaI
12:52 PM Emil: I have changed it since a bit
12:53 PM Emil: but the overall feel is the same
12:56 PM xentrac: it's awesome
12:57 PM Emil: thanks ^.^
12:57 PM xentrac: I feel like mapping a high-dimensionality signal like sound into color is inevitably going to be lossy
12:57 PM Emil: that's fine
12:57 PM xentrac: since color is only three dimensions
12:57 PM Emil: but umm
12:57 PM xentrac: so the question is mostly what aspects of the sound you want to key off of
12:57 PM Emil: sound is only one dimensional
12:58 PM xentrac: sure, but sound as we hear it is a spectrum
12:58 PM xentrac: of a few hundred frequency bins
12:58 PM Emil: I maintain that time series analysis is superior :D
12:58 PM Lambda_Aurigae: amplitude and frequency
12:58 PM Lambda_Aurigae: I count two dimensions
12:59 PM Emil: FFT is lossy
12:59 PM Emil: Lambda_Aurigae: only amplitude
12:59 PM xentrac: the FFT is lossy?
12:59 PM Emil: xentrac: and also imprecise
12:59 PM Emil: it doesn't capture the wavelet nature of signals
01:00 PM xentrac: I don't think any of that is true
01:00 PM xentrac: if you carry out the FFT in a group, the inverse FFT results are bit-identical
01:00 PM xentrac: if you carry it out in floating-point, it's lossy, but usually only slightly
01:01 PM xentrac: it doesn't *distinguish* the wavelet nature of signals the way the DWT does
01:02 PM xentrac: but it doesn't lose it either
01:04 PM Emil: if only dtf and fft were cheap to compute
01:05 PM xentrac: I guess I mean "a field", not "a group"
01:27 PM Emil: Hmm, how retarded am I now: so I have 450 bytes to push through at 800kbps which should logically take 4.5ms but somehow the fucking manages to achieve that in 0.92ms :D
01:28 PM Emil: 0.902625ms*
01:28 PM xentrac: measurement error?
01:28 PM xentrac: do you mean μs>
01:28 PM xentrac: ?
01:29 PM xentrac: oh, no, 4.5ms
01:29 PM xentrac: just as you said
01:32 PM Emil: I do: TCNT1=0; ws2812_setleds(leds, LEDS); timenow(); and results are 14442 so I don't see how the heck it could be measurement error
01:33 PM Emil: please, avr gods help me
01:34 PM xentrac: maybe ws2812_setleds loads data into a buffer to be sent out over SPI from an interrupt handler
01:35 PM Emil: It shouldn't
01:35 PM xentrac: so maybe it is returning before actually sending the data?
01:35 PM Emil: Because it's not on spi pin
01:35 PM Emil: and the lib is interrupt safe
01:35 PM xentrac: so there's no way for it to send the data in the background because it doesn't use an interrupt?
01:36 PM Emil: https://github.com/cpldcpu/light_ws2812
01:38 PM xentrac: yeah, sure enough, in https://github.com/cpldcpu/light_ws2812/blob/master/light_ws2812_AVR/Light_WS2812/light_ws2812.c it has an assembly loop to send the data out synchronously
01:38 PM Emil: indeed
01:39 PM xentrac: but it disables interrupts while it's doing that
01:39 PM Emil: indeed
01:39 PM xentrac: where does timenow() get its time? maybe a counter in memory that gets incremented by a timer interrupt?
01:39 PM xentrac: because that would make it not count the time while interrupts were disabled
01:40 PM Emil: xentrac: timenow just grabs TCNT1 as a local copy and sends it out of serial
01:40 PM xentrac: how many bits is TCNT1 again?
01:40 PM Emil: 16
01:40 PM Emil: ah
01:40 PM Emil: lol
01:40 PM Emil: apparently reaaaally retarded
01:40 PM xentrac: heh
01:41 PM xentrac: no, overflow errors hit everyone
01:41 PM xentrac: you could maybe prescale the timer clock to run slower to get a lower precision timing
01:41 PM Emil: I mean, I even fucking calculated that TCNT1 is good for 4.096ms :D
01:41 PM Emil: and it still didn't occur to me
01:42 PM Emil: xentrac: oh I know
01:42 PM xentrac: at least you didn't blow up Ariane 5 when your timer overflowed, unlike specing
01:42 PM Emil: xentrac: story time? story time.
01:43 PM xentrac: you want to tell a story, or you want the Ariane 5 story?
01:43 PM Emil: latter
01:45 PM Emil: please?
01:45 PM xentrac: the short version is that in Ada, arithmetic overflow throws a fatal exception by default, and Ariane 5's in-flight control systems were programmed in Ada, and a part of the inertial guidance system that was integrating accelerometer readings over time to get velocity (IIRC) overflowed its accumulator
01:46 PM xentrac: that accumulator wasn't actually being used in that part of the flight, so without the fatal exception it wouldn't have caused a problem
01:47 PM Emil: ah, I thought it was specin specifically :D but heh, that's a bad side effect
01:47 PM xentrac: there were redundant systems, but they all ran the same code, so they all crashed at once
01:47 PM xentrac: no, that was just a joke about specing constantly advocating Ada despite having no experience with it ;)
01:47 PM xentrac: it was automatically restarted but immediately crashed again
01:47 PM Emil: yeah I realised the instant you started :D
01:48 PM Emil: https://en.wikipedia.org/wiki/Ariane_5 doesn't mention this :o
01:48 PM xentrac: it was the first flight of an Ariane 5, in 1996
01:49 PM xentrac: it does mention it: https://en.wikipedia.org/wiki/Ariane_5#Notable_launches
01:49 PM Emil: Ah, "explosion" nor "overflow" resulted in anything :o
01:49 PM Emil: :D
01:49 PM xentrac: specifically it was a type coercion overflow, not an arithmetic overflow
01:51 PM xentrac: initial reports at http://catless.ncl.ac.uk/Risks/18/18#subj4
01:54 PM xentrac: the inquiry board's report is at http://web.archive.org/web/20010602154447/http://www.esrin.esa.it:80/htdocs/tidc/Press/Press96/ariane5rep.html
01:55 PM Emil: ooh
01:55 PM Emil: interesting
01:57 PM xentrac: yeah, there's a kind of disaster porn aspect to it
02:02 PM xentrac: and apparently I was wrong about the automatic restart
02:14 PM mindw0rk: guys, say I wan't run usb full speed with an atmega32u4, but power it just with 3v3. Is that feasible, if not is there another chip I could look for?
02:22 PM xentrac: I haven't tried; what does the datasheet have to say on the matter?
02:23 PM polprog: i'm slightly skeptical about that 3v3 signalling
02:25 PM xentrac: USB signals are single-ended, aren't they? but I'm not sure what the required voltage levels are
02:25 PM LeoNerd: Differential
02:26 PM xentrac: yeah, differential, you're right
02:26 PM xentrac: so low-voltage signaling is plausible
02:26 PM xentrac: and the 32u4 apparently has an internal voltage regulator
02:28 PM xentrac: apparently the voltage levels are 3.0 to 3.6 volts, which is what the internal regulator is for --- deriving that voltage from the 5V provided by USB
02:29 PM xentrac: mindw0rk: see figure 21-2 in the 32u4 datasheet (doc 7766)
02:29 PM bss36504: xentrac: Pay attention to the schematics provided in the datasheet for how to connect the power supplies in different modes
02:31 PM xentrac: yeah
02:31 PM xentrac: why on earth do they draw the power supply in figure 21-5 as a current source?
02:39 PM bss36504: good question
02:40 PM xentrac: this datasheet doesn't feel like it's up to Atmel's usual quality standards
02:43 PM bss36504: Must be they had the new guy write it
02:43 PM xentrac: who doesn't speak English very well or know electronics
02:44 PM xentrac: still, it's very helpful
02:44 PM xentrac: (I guess I shouldn't say that before trying the circuits they give)
02:44 PM bss36504: The circuits are correct, just dont make the mistake I did and miss the nuances of which pins should be connected to what in the different power supply circumstances
02:47 PM specing: xentrac: I have exp in Ada, just not much and not in AVR Ada
02:47 PM specing: Emil: ^
02:48 PM specing: Ariane blew up because someone didn't catch the overflow exception
02:49 PM Emil: but if it wsasn't used
02:49 PM Emil: That means that unnecessary cycles were dedicated to monitoring it automatically
02:58 PM specing: cost of extra mhz is negligeable compared to the cost of a rocket
03:27 PM mindw0rk: xentrac, polprog: yeah but as the figure shows, I would have to go with 8Mhz crystal, and that automatically means I can't do USB full speed, no?
03:28 PM polprog: i have never implemented usb, so i don't know
03:34 PM Lambda_Aurigae: I do believe you can generate the internal 48MHz for USB from an 8MHz crystal.
03:34 PM Lambda_Aurigae: internal PLL does it.
03:38 PM Lambda_Aurigae: in fact
03:38 PM Lambda_Aurigae: the PLL requires 8MHz.
03:38 PM Lambda_Aurigae: so you would have to divide down a 16MHz clock.
03:38 PM Lambda_Aurigae: it's right in the datasheet.
03:49 PM mindw0rk: ah damn it
03:51 PM mindw0rk: thanks, I must've completely missed it
05:10 PM carlos4242: has anyone got any suggestions or experience using clang with avr?
05:11 PM Emil: why though?
05:11 PM Emil: why not just gcc
05:11 PM Emil: why break the nicely working free and open toolchain
05:11 PM carlos4242: clang is open too
05:12 PM carlos4242: I'm planning to build from clang, via llvm IR.
05:12 PM Emil: y tho
05:12 PM carlos4242: Then try to use other languages to create the LLVM IR later. :)
05:13 PM carlos4242: I hear rust have had some success.
05:26 PM specing: carlos4242: you have Ada with GCC, which blows Rust out of the water, then beats it unconscious
05:28 PM carlos4242: yeah, well each person loves their own language :)
05:29 PM Tom_L: i program everything in english
05:30 PM carlos4242: my mission is to get llvm ir working at least a bit then you get a choice!
05:30 PM Lambda_Aurigae: you can't do IR with C?
05:34 PM carlos4242: well clang can compile to llvm ir, and that compiles to assembly
05:34 PM carlos4242: that all works, I've done it before, it's the whole principle of llvm
05:35 PM Lambda_Aurigae: ok.
05:35 PM Lambda_Aurigae: guess we have a name conflict
05:35 PM carlos4242: so in theory I can do this... there's an llvm-avr project but it looks like it's not in standard builds of llvm
05:35 PM Lambda_Aurigae: IR = InfraRed
05:35 PM carlos4242: so it's going to be an uphill battle
05:35 PM carlos4242: ha... OK
05:37 PM carlos4242: yeah, my biggest target is Swift compiled to AVR
05:37 PM carlos4242: I may be insane. :)
05:41 PM grafi is now known as Guest12304
05:45 PM carlos4242: cheers guys, I'll come back when I've made some progress
05:50 PM Emil: Another person who is dreaming
05:50 PM Emil: Swift for avr :D
05:51 PM Lambda_Aurigae: what about COBOL?
09:14 PM xentrac: mindw0rk: Lambda_Aurigae is right