#avr Logs
Mar 15 2018
#avr Calendar
12:20 AM day__ is now known as day
03:07 AM Emil: LeoNerd: why not just make your own programmer
03:08 AM Haohmaru: u know u ain't cool if you don't make your own compiler too
03:08 AM Haohmaru: ..in assembler
03:10 AM Emil: Point is that designing the frontend is already a pretty big step
04:28 AM nuxil: whats a good method to create a "true" radom number on a avr ?
04:29 AM Haohmaru: external source
04:30 AM Haohmaru: maybe something like a noise generator into an ADC input
04:31 AM nuxil: heh. thats the thing :p im trying to create noice :p
04:31 AM Haohmaru: noice ;P~
04:31 AM nuxil: *noise
04:31 AM nuxil: :D
04:32 AM nuxil: 'i can recall it was somewhat possible to do it using the watchdog.
04:32 AM Haohmaru: eh?
04:32 AM Haohmaru: wouldn't a prng be enough?
04:32 AM nuxil: yea. i might need to dig in the logs.
04:32 AM nuxil: prng ?
04:33 AM Haohmaru: pseudo-random number generator
04:36 AM Emil: nuxil: so
04:36 AM Emil: you can create randomness
04:36 AM Emil: but it's pretty slow
04:37 AM Emil: I recommend amplifying heat noise
04:37 AM nuxil: Emil, i just need a table of size 256 where each element is a uint8. each element should be truly random. so it doesnt really matter if it takes a bit to generate this array.
04:38 AM Haohmaru: what is it used for?
04:38 AM nuxil: speed is not important.
04:39 AM Emil: nuxil: wait
04:39 AM nuxil: Haohmaru, noise table.
04:39 AM Emil: nuxil: do you need it fixed?
04:39 AM Emil: or dynamic?
04:39 AM Haohmaru: nuxil are you trying to make a digital "noise" oscillator?
04:39 AM nuxil: Emil, i just need to generate it once at startup.
04:40 AM nuxil: Haohmaru, whitenoise yes.
04:40 AM Haohmaru: then you can't do it like that
04:40 AM nuxil: why not ?
04:40 AM Haohmaru: 256 samples is too small for a noise osc
04:40 AM Haohmaru: it's gonna be periodic
04:41 AM Haohmaru: it'll probably sound like metallic-ish
04:41 AM nuxil: hmm
04:41 AM Haohmaru: white noise in computer DSP is typically made with PRNGs
04:42 AM Haohmaru: in electronics you can actually use a noise generator, no DSP
04:42 AM Haohmaru: or a prng
04:42 AM Haohmaru: it'd need to be a decent one
04:43 AM Haohmaru: you need the prng to have a long enough period, otherwise it'll sound periodic
04:43 AM nuxil: i see.
04:44 AM Haohmaru: you don't need crypto-grade prng, that's overkill
04:48 AM nuxil: ok. thanks. i'll rethink my noise approche :)
04:50 AM Haohmaru: try it in a sound editor, generate some whitenoise there, listen to it, then select a small section of the noise and play it in a loop
04:53 AM Haohmaru: i think even a whole 1 second of noise is not gonna be enough, and that would be probably more than your 256 samples
04:54 AM nuxil: Yay. got sms from DHL that my 3dPrinter will arrive within the 20th. :)
04:54 AM nuxil: about time, its been a month since i ordered it :)
04:54 AM Haohmaru: use it to print another 3Dprinter >:)
04:54 AM Emil: nuxil: so yes dynamic
04:55 AM nuxil: Emil, yea.
04:56 AM Emil: nuxil: I recommend a hardware rng
04:58 AM Haohmaru: if i could, i'd use a noise generator circuit, then you don't need to spend any efforts on your avr
04:58 AM Emil: Haohmaru: =hwrng
04:59 AM Emil: except youe hwrng will give you bytes directly
04:59 AM Haohmaru: i don't have a definition for "hardware rng"
04:59 AM Haohmaru: i meant analog(ue) noise generator
05:00 AM Haohmaru: these are used often in analog drum synthesizers
06:01 AM nohitzwork: how about this nuxil http://www.musicdsp.org/archive.php?classid=1#239
06:02 AM nohitzwork: you can ingnore everything execpt variable ShiftRegister and its manipulation in Run() (which is called @samplerate)
06:06 AM nuxil: thx. will look more into it later
06:10 AM Haohmaru: so many bitshifts there...
06:13 AM Haohmaru: i use a 16bit "marsaglia" style prng for a sequencer, and it doesn't have so many operations
06:14 AM Haohmaru: marsaglia has a technique for multiple feedback points so the period is very big even with low bit count like 16
06:30 AM dan3wik is now known as dan2wik
06:41 AM * Haohmaru slaps nuxil with https://en.wikipedia.org/wiki/Multiply-with-carry
06:47 AM Haohmaru: i think he has smaller examples in his papers somewhere, cuz that code example there is crazy
06:48 AM Haohmaru: IMO a prng with a period of about several tens of seconds would be okay
06:48 AM Haohmaru: so calculate the period based on that and your sampling rate
06:49 AM Haohmaru: with marsaglia's prngs, more feedback points are used for making the period longer, but that's also computational cost
06:51 AM cehteh: i wanted to try how well zener diode noise works for rng generation, 2 zeners on differential adc inputs with gain amp
06:51 AM cehteh: not done yet
06:52 AM cehteh: other ppl use clock jitter/drift betwenn the 128khz WDC osc and main clock
06:53 AM Haohmaru: what if one day, suddenly, the world becomes "perfect"? ;P~
06:56 AM nohitzwork: i used this kind of hack when i needed a random number between 1-6 for my speed game https://pastebin.com/V9tpxiQy
06:56 AM nohitzwork: its sucks, i know
06:57 AM cehteh: the question is if you need a prng or a real rng
06:57 AM cehteh: in many case a simple prng is good enough
06:58 AM Haohmaru: for audio whitenoise a prng is gud enough
06:58 AM Haohmaru: you might want to check what distribution you want
06:59 AM Haohmaru: cuz i think they tend to produce flat distribution
06:59 AM Haohmaru: while analog(ue) noise afaik is gaussian
07:10 AM skz81: cehteh, I did not implement yet, but i was going for a little "antenna" on an ADC pin, and sample the "low" bits. Should be enough for my application (flickering diode, the electronics is not the "big" part, it's more "art" here...)
07:10 AM cehteh: skz81: i'd prefer something which can not easily be tampered
07:10 AM cehteh: and one prolly wants to 'debias' such a thing
07:11 AM cehteh: aka, it is likely that the distribution of low and high lsb is not equal
07:11 AM Haohmaru: skz81 you're probably getting some russian radio stations on yer diode there ;P~
07:11 AM cehteh: which will hack you!
07:11 AM Haohmaru: or soviet stations
07:12 AM Haohmaru: for audio alone, you can use an analog(ue) noise generator and just don't digitize it..
07:13 AM cehteh: there are noise-diodes, dunno about their prices, any better idea about some extra noisy component?
07:13 AM Haohmaru: but in any case, prng is nice because it's more "controlled"
07:13 AM skz81: Ok. Nevertheless, the "bias" is probably NOT is the 4 low bits... They can hack my diodes for fun, I just want to "avoid" repetitive flickering patterns :)
07:13 AM skz81: Unsure if human would notice anyway...
07:13 AM cehteh: skz81: bias is on every bit because of tolerances in the ADC internals
07:13 AM Haohmaru: cehteh i'm no electronics guru, but in my drum machine, the noise generator is made by (ab)using a transistor, plus a few components around it
07:15 AM skz81: ho and I will use the grabbed values to seed the PRNG, not to generate values...
07:15 AM cehteh: its little, but makes the rng imperfect if not handled, for simple things it might be ok as is, but then you can already use a prng
07:15 AM cehteh: when you need true random you need to do some (correct) massaging
07:15 AM skz81: cehteh, can you go on ? On every bits ? Do you have a link or something pls ?
07:15 AM cehteh: datasheet
07:15 AM skz81: lol ok
07:16 AM cehteh: no matter how exact your adc is there is some value when one bit registers as high/low determined against some reference
07:17 AM cehteh: but each of these components have some tolerances
07:17 AM cehteh: its only natural that such cant be 'perfect'
07:25 AM Haohmaru: stick a photo resistor on a long cable, put it inside a dance club where they play abstract rave music, pretty decent random noise there ;P~
07:32 AM skz81: cehteh, unsure to understand. What you call "bias", here, is the mean of the sampled signal ? Or smth else ?
07:53 AM skz81: anyway, need to go away, be back later...
08:15 AM Emil: cehteh: isn't that also just heat noise
08:16 AM Emil: also the wdt osc is rc clock so heat noise is the source of random there also
08:16 AM Emil: but it's a lot slower in producing bits
08:16 AM Emil: nuxil: one easy way to have a prng
08:16 AM Emil: that produces extremely good results
08:17 AM Haohmaru: is to embed Emil on your board
08:17 AM Emil: is having aes in some mode other than ecb and then just generate a random key once on a computer
08:17 AM Emil: Haohmaru: I'm extremely predictable!
08:17 AM Haohmaru: you can be trained
08:17 AM Emil: nuxil: so if your key is exposed of course your rng is no longer rng since it's deterministic
08:18 AM Haohmaru: with force >:)
08:18 AM Emil: but if you don't expose the key the results are really good
08:18 AM Emil: and you only need a single source of random once for many gigabytes of random
08:19 AM Emil: Haohmaru: if you beat me with a wrench (or attept to) I'll be extremely, extremly predictable
08:20 AM Haohmaru: don't worry, there are methods for everything
08:21 AM * Haohmaru slaps Emil on da head with a book "Negative reinforcement training"
08:25 AM LeoNerd: Emil: PSU/frontend is fairly simple stuff. The actual programmer part is USB hackery. That's already built for me, so I can just reüse it as a module
11:24 AM Xark_ is now known as Xark
12:48 PM Ameisen- is now known as Ameisen
12:58 PM Ameisen: getting really frustrated with the gcc build system
02:10 PM Ameisen: hmm
02:11 PM Ameisen: easier to put strings in program memory on arm
02:11 PM Ameisen: since it's a unified address space
02:36 PM Casper: not that hard on avr
02:48 PM Ameisen: PITA in avr-g++
02:48 PM Ameisen: putting it into progrma memory isn't _that_ hard, but accessing it is a pita
02:59 PM Emil: eh?
02:59 PM Emil: wot
02:59 PM Emil: super easy
03:00 PM Emil: In C++ even easier because you can overload
03:42 PM Ameisen: Emil - C++ lacks __flash
03:43 PM Ameisen: thus, you can only access the data in program member using program memory asm instructions (or macros wrapping them)
03:43 PM Ameisen: Unfortunately, those macros/asm instructions are also not constexpr, because how could they be
03:43 PM Ameisen: So you cannot access program memory array data in a generic constexpr/runtime context
03:43 PM Ameisen: I had to write a bunch of janky code to make that work
03:43 PM Ameisen: Past that, C++ offers zero type safety natively for program memory, because there are no pointer modifiers for program memory (again, __flash doesn't exist)
03:44 PM Ameisen: a const char * in SRAM is the same as one in const char * in flash
03:44 PM Ameisen: so you can't overload on one or the other.
03:44 PM Ameisen: you have to write wrappers
03:45 PM Ameisen: that'd be an interesting feature in C++, actually... strong typing modifiers. Don't impact behavior, they just describe a type as being different than another
03:45 PM Ameisen: int __a, int __b
03:45 PM Ameisen: would overload only to int __a and int __b
03:45 PM Ameisen: could do something similar with strong typedefs, but C++ lacks those.
03:45 PM Ameisen: regardless of how many times they've been proposed.
03:46 PM Ameisen: https://github.com/ameisen/Tuna-i3-Plus/blob/master/Tuna/tunalib/flash.hpp
03:46 PM Ameisen: this header was my janky solution to the problem
03:48 PM Ameisen: Also could be 'solved' by having program-memory reading intrinsics that were constant expressions.
04:11 PM Emil: Ameisen: all my wat
04:11 PM Emil: C++ supports PROGMEM just fine
04:12 PM Emil: avr/pgmspace.h
04:12 PM Emil: Those absolutely are available on c++
04:17 PM Ameisen: yes...
04:17 PM Ameisen: what about it?
04:17 PM Ameisen: all that does is say "I want the memory for this symbol in program memory"
04:18 PM Ameisen: the only way to _read_ the memory is to use program memory instructions, or the macros that wrap them
04:18 PM Ameisen: it does not imply any read semantics to the compiler as there is no support for that in g++
04:18 PM Ameisen: nor is it a type modifier in g++ because, again, there is no extension support for it
04:18 PM Ameisen: __flash and PROGMEM are not the same thing
04:19 PM Ameisen: I'm confused, did you actually read what I'd written, or read the first line, presume something, and decide to get haughty?
04:19 PM Emil: <bro
04:19 PM Ameisen: because I'm pretty sure that strcmp("PROGMEM", "__flash") != 0
04:19 PM Emil: IAR uses nonstandard __flash
04:20 PM Emil: avr gcc uses __attribute__ ((progmem)) which is PROGMEM
04:20 PM Ameisen: ok?
04:20 PM Emil: __flash and PROGMEM are the same thin
04:20 PM Ameisen: Yes. And you can ONLY FUCKING READ THE DATA USING PGM INSTRUCTIONS BECAUSE THE COPMILER HAS NO IDEA THAT THE POINTER IS SPECIAL
04:20 PM Ameisen: jesus christ
04:20 PM Ameisen: are you even reading what I'm writing
04:20 PM Emil: Ameisen: lul fuck off
04:20 PM Ameisen: No, they're fucking not
04:20 PM Emil: are you even reading what you write?
04:20 PM Emil: retard
04:20 PM Ameisen: https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
04:20 PM Ameisen: read it.
04:20 PM Ameisen: __flash
04:20 PM Ameisen: The __flash qualifier locates data in the .progmem.data section. Data is read using the LPM instruction. Pointers to this address space are 16 bits wide.
04:20 PM Ameisen: Notice that attribute progmem locates data in flash but accesses to these data read from generic address space, i.e. from RAM, so that you need special accessors like pgm_read_byte from AVR-LibC together with attribute progmem.]
04:21 PM Ameisen: so, you're telling me the GCC documentation is wrong
04:21 PM Ameisen: k
04:21 PM Ameisen: they are _similar_ but __do not do the same thing.__
04:22 PM Ameisen: This is trivial to determine, is part of GCC, adn is part of the embedded extensions spec for C
04:22 PM Ameisen: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1290.pdf
04:24 PM Ameisen: __flash, __flashN, and __memx are _not_ supported in g++, as the embedded extensions spec is not part of C++.
04:25 PM Emil: what part of the fucking documentation do you not understand?
04:25 PM Ameisen: and, _as the documentation says_, the progmem attribute (which is what PROGMEM wraps) only puts the data INTO program memory - it does not grant _any_ semantics to the compiler for reading it. The compiler will treat the pointer as though it is in SRAM unless you use assembly instructions.
04:25 PM thardin: can't you make a special class using templates or some shit
04:25 PM Ameisen: What part do YOU not understand?
04:25 PM Ameisen: It's incredibly clera.
04:25 PM Ameisen: clear*
04:26 PM Ameisen: Notice that attribute progmem locates data in flash but accesses to these data read from generic address space, i.e. from RAM, so that you need special accessors like pgm_read_byte from AVR-LibC together with attribute progmem.
04:26 PM Ameisen: but accesses to these data read from generic address space, i.e. from RAM, so that you need special accessors like pgm_read_byte
04:26 PM Emil: https://emil.fi/d/2018-03-15_23-25-05_RCrR4blO.png
04:26 PM thardin: like template<int sz> class {PROGMEM char data[sz]; operator[](){blah blah}}
04:26 PM Ameisen: PROGMEM isn't an attribute in C++
04:26 PM Emil: Ameisen: you are making issues out of nowhere
04:26 PM Ameisen: err
04:26 PM Ameisen: a modifier.
04:26 PM Emil: Ameisen: sure is
04:26 PM Emil: bro
04:26 PM Ameisen: Emil - you are a fucking moron
04:26 PM Emil: Ameisen: top quality coding you ahve there
04:26 PM Ameisen: you literally are telling my the GCC documentation is incorrect
04:26 PM Ameisen: and that the C extension specification is wrong
04:27 PM Ameisen: because you're an arrogant dick
04:27 PM Emil: Ameisen: We can both be dicks :)
04:27 PM thardin: get a room you two
04:27 PM Ameisen: And you for some reason show me a picture of IAR source code to 'prove' I'm wrong
04:27 PM Ameisen: because apparently you still can't fucking read the GCC documentation WHICH I PROVIDED YOU
04:27 PM Emil: >IAR source code
04:27 PM Ameisen: what the fuck is your problem
04:27 PM Emil: :DDDDDDDD
04:28 PM Ameisen: I don't know what the fuck IAR is
04:28 PM Ameisen: and I don't care
04:28 PM thardin: fugg
04:28 PM -!- #avr mode set to +o by ChanServ
04:28 PM Ameisen: __attribute__((progmem)) and __flash are NOT the same thing
04:28 PM Tom_L: behave mkay?
04:28 PM Ameisen: as the GCC documentation _very clearly states_
04:28 PM Tom_L: IAR is a compiler
04:29 PM Tom_L: just like GCC
04:29 PM Ameisen: I started the entire discussion by saying avr-g++
04:29 PM Ameisen: so why would he bring up IAR?
04:29 PM Ameisen: ... to prove that I'm wrong about g++?
04:29 PM Emil: This just keeps on giving :D
04:29 PM thardin: huh didn't know attiny had code and data in the same addr space
04:29 PM Jartza: depends of attiny
04:29 PM Jartza: reduced core attinies have it
04:29 PM thardin: you got von neumann in my supposed harvard machine
04:29 PM Jartza: like attiny5, attiny10...
04:30 PM Tom_L: i'm not remotely interested in the discussion, rather keeping the channel on track
04:30 PM Jartza: I didn't even read it :D
04:30 PM thardin: neato
04:30 PM Jartza: but IAR is good compiler
04:30 PM Ameisen: Emil - explain how what IAR defines those things to be has _any_ relevance to g++?
04:30 PM Jartza: that's my contribution to this discussion :D
04:30 PM thardin: or not neato, depending. it's a security risk
04:30 PM Tom_L: just walked into a heated discussion and decided to throw some ice on it
04:30 PM Ameisen: given that I gave you the GCC documentation which _very_ clearly states what gcc/g++ defines them to be
04:30 PM Ameisen: IAR is simply completely irrelevant
04:31 PM Emil: Jartza: STOP, this channel is not ##stm32, please refraim from shilling poropietari software
04:32 PM Ameisen: thardin - regardless, as I said
04:32 PM Ameisen: PROGMEM (__attribute__((progmem))) is not considered to be a type modifier in g++
04:32 PM Ameisen: it is a symbol modifier only
04:32 PM Ameisen: the only thing progmem does in g++ and gcc is put the symbol in the program memory address space
04:32 PM thardin: I'm positive it's possible to come up with some arcane syntax that makes thing a bit more bearble
04:32 PM Ameisen: gcc has __flash which does that _and_ provides it with access semantics. __flash is not part of g++.
04:33 PM Ameisen: You can. I did it in my flash.hpp.
04:33 PM Tom_L: i may be wrong but iirc, early pdfs used IAR for some of their code examples
04:33 PM Ameisen: It's not nearly as nice as having an actual type modifier.
04:33 PM Emil: Tom_L: most of AT90 iirc
04:33 PM Emil: at least
04:33 PM Ameisen: you end up with something janky like flash<uint32_t>
04:33 PM thardin: so you have to to PROGMEM my_special_class<100> foo; or so?
04:33 PM Ameisen: my_special_class has to define access semantics to read from progrma memory
04:34 PM Ameisen: IE - overload accessors
04:34 PM thardin: oh yeah, of course. and you put that stuff on the members. but then things like memcpy doesn't work
04:34 PM Ameisen: the problem is then you end up breakin the ability to read things as constexpr values
04:34 PM thardin: fun fun
04:34 PM Tom_L: http://tom-itx.no-ip.biz:81/~webpage/abcminiuser/articles/progmem_basics_index.php
04:34 PM Tom_L: in case someone needs training wheels
04:34 PM Ameisen: there's no good way in gnu avr-g++ to define a generic access semantic for program memory data
04:35 PM Ameisen: __flash was added to GCC as part of the extension proposal I linked to earlier, which _was_ adopted into C
04:35 PM Ameisen: the proposal basically adds address space support, acts as a type modifier, and enables read semantics
04:35 PM Ameisen: It was never adopted into C++, so the g++ maintainers refuse to support it.
04:36 PM thardin: it's almost as if C and C++ are different languages or something
04:36 PM Ameisen: Yes, but there's no good reason the proposal wouldn't work in C++
04:36 PM * thardin releases his inner rullgård
04:36 PM Ameisen: the committee just doesn't care
04:36 PM Ameisen: There's also no good reason they couldn't just add support for it and enable it by, like, -fembedded
04:37 PM thardin: patch welcome ;)
04:37 PM Ameisen: If anything, works better in C++ because if you actually had __flash, C++ is type-restrictive
04:37 PM Ameisen: as I recall, they're not in this case
04:37 PM Ameisen: the maintainers made it pretty clear, as per GJL, that they are not interested in having the feature at all.
04:37 PM Ameisen: no such patch woudl be approved.
04:38 PM thardin: ah. bummer
04:38 PM * Ameisen still isn't sure how IAR was relevant to the discussion though
04:38 PM Jartza: Emil: IAR is still good compiler, no matter what :)
04:38 PM Jartza: expensive as hell, though
04:38 PM Ameisen: Clang has support for address spaces built-in for C and C++, it just has terrible AVR support at the moment.
04:39 PM Ameisen: thardin - this is what I'd come up with
04:39 PM Ameisen: https://github.com/ameisen/Tuna-i3-Plus/blob/master/Tuna/tunalib/flash.hpp
04:39 PM Emil: Jartza: THIS IS AN OPEN SOURCE #SAFESPACE, STOP HARRASSING US
04:40 PM Emil: Jartza: /s :D
04:40 PM thardin: has anyone in here done ada/spark on avr? seems like it would be very appropriate
04:40 PM Emil: Tom_L: there was one guy who did ada
04:40 PM thardin: instead of using garbage languages like C or C++
04:40 PM Emil: we teased him to no end about it
04:40 PM Jartza: I will use IAR as my safe word from now on :D
04:40 PM Ameisen: thardin - with it, you can use something like "foo_bar"_p
04:41 PM Ameisen: which will put it into program memory, and will return type flash_char_array<>, which can be used as said type, or devolve into flash_string
04:41 PM Jartza: for my own projects I still use open source, but lot of customer projects use iar
04:41 PM Ameisen: it cannot be implicitly cast to const char * because otherwise it becomes type ambiguous
04:41 PM Jartza: and I use their licenses then
04:41 PM Jartza: I'm not crazy enough to buy iar license myself
04:41 PM Emil: ah yeah
04:41 PM Emil: it was specing
04:41 PM Tom_L: Emil, rue wrote some stuff in brainfuck
04:42 PM Emil: OOOOOH SPEEEEECIIIIING (specing), come tell us about Ada
04:42 PM Emil: Tom_L: nice
04:42 PM Jartza: my colleague made some AVR cobol
04:42 PM thardin: Ameisen: you still have to manually use the right string manipulation functions though right?
04:42 PM * Ameisen notes that Emil still hasn't explained how ranting about IAR and how I'm apparently an idiot because GCC semantics don't match IAR semantics has anything to do with avr-g++.
04:42 PM Emil: Tom_L: that's pretty cool, did he transpile to C, interpret or actually compile to AVR?
04:42 PM Ameisen: thardin - no
04:42 PM Ameisen: it cannot implicitly cast to const char *
04:42 PM Tom_L: i'm not sure, you'd have to ask him
04:42 PM thardin: ah
04:42 PM Tom_L: iirc it made hackaday
04:43 PM Jartza: with meson build system
04:43 PM Ameisen: you would define program-memory specific ones that take the flash types
04:43 PM Ameisen: with concepts its actually even simpler
04:43 PM Ameisen: you can define functions as requiring normal types, or flash types
04:43 PM thardin: I made hackaday too, for managing to blow up a D-class amplifier :^)
04:43 PM Emil: Tom_L: https://hackaday.com/2013/02/27/interpreting-brainfk-on-an-avr/ probably this
04:43 PM Ameisen: it would all be far simpler if __flash were supported, though
04:44 PM Emil: Tom_L: is Dan Rues first name though? :D
04:44 PM Jartza: ha. I once made hackaday too
04:44 PM Ameisen: Tom_L - the progrma I used to benchmark my MIPS emulator was a brainfuck interpreter
04:44 PM Emil: I was so proud when OSHPark featured my simple board on Facebook <3
04:44 PM Ameisen: which generated the mandelbrot sequence
04:44 PM thardin: could only find one thing on hackaday tagged with ada: https://hackaday.com/2016/06/09/pen-plotter-firmware-written-completely-in-ada/
04:44 PM Jartza: https://hackaday.com/2014/11/30/transferring-audio-to-an-avr-at-12kbps/
04:44 PM Jartza: whoa, already that long ago :o
04:44 PM Emil: no it was this
04:44 PM Emil: http://ruemohr.org/~ircjunk/tutorials/prog/avrbf/main.html
04:45 PM Emil: But I don't think it featured on hackaday
04:45 PM Ameisen: it was an optimizing interpreter, too
04:45 PM Ameisen: It'd even be nice to get an _apology_ from Emil
04:45 PM Ameisen: but I'm giving up hope on that
04:46 PM Emil: Ameisen: aww, are you still salty and sad?
04:46 PM Ameisen: Yeah, because you were a dick for no reason, and you were wrong.
04:46 PM thardin: I don't think finns do apologies
04:46 PM Emil: thardin: hey now, don't give us Finns a bad name just because of me :D
04:47 PM Emil: we absolutely do if there's a point to it
04:47 PM thardin: that's true
04:48 PM thardin: you always know where you stand with a finn
04:48 PM Emil: naw be backstab too
04:48 PM Emil: Just a lot less
04:49 PM Emil: Loving that Rue's brainfuck page
04:49 PM Ameisen: So, you're not apologizing because I proved you wrong? Gotcha.
04:49 PM Emil: >Sorry, this is NOT an arduino project :-)
04:49 PM thardin: jej
04:49 PM Ameisen: It's like talking to torvalds
04:50 PM Emil: Tom_L: Ameisen is being mean to me and continuing the farce :(
04:50 PM Ameisen: damned far east Swedes
04:50 PM Emil: Also Torlvads is always on point
04:50 PM Emil: also
04:50 PM Emil: wait
04:50 PM Ameisen: Yeah, a Finn _would_ defend their one national hero.
04:50 PM Ameisen: :|
04:50 PM Emil: was I just compared to Linux Torvalds
04:50 PM Emil: hot fucking damn
04:50 PM Emil: that goes onto my resume
04:51 PM Ameisen: right after "I think IAR and GCC are the same thing." :)
04:51 PM Emil: Ameisen: comeone, stop with the saltiness already
04:51 PM Tom_L: u2 give it a rest mkay?
04:52 PM Ameisen: Well, you've been needlessly antagonistic for the last few days towards me, and each time you've been wrong.
04:52 PM Ameisen: So I'm a bit irate.
04:52 PM Ameisen: I generally don't like it when people are going out of their way to _try_ to prove me wrong
04:53 PM Ameisen: emphasis on try
04:54 PM thardin: oh snap
04:54 PM Ameisen: thardin - other issue - the g++ side of the code actually has _no_ concept of address spaces. At all.
04:54 PM Ameisen: I didn't like going over GCC's codebase.
04:55 PM Ameisen: felt dirty.
04:55 PM Ameisen: So, it's not trivial to fork and add, because adding it would make future merges/keeping it up to date _very_ difficult
04:56 PM Ameisen: not a tiny change
04:56 PM Emil: TYÖJÄRJESTYSPUHEENVUORO: My messages on this channel in the last few days have been: emil.fi/d/lastweek.txt
04:56 PM Emil: And of those not until today has there been any negativity towards Ameisen
04:56 PM Ameisen: [14:02] <Ameisen> It has no way to know how to initialize the 50 quadrillion ARM variants
04:57 PM Ameisen: [14:08] <Emil> Ameisen: that's not really true at all
04:57 PM thardin: Emil: how come mousewheel scrolling doesn't work on your webzone?
04:57 PM Emil: holy shit bro
04:57 PM Emil: how pc are you?
04:57 PM Ameisen: Not at all?
04:57 PM Emil: thardin: hm?
04:57 PM Ameisen: not sure what political correctness has to do with it
04:57 PM Emil: thardin: whatcha mean with that?
04:57 PM thardin: I can scroll with arrow keys but not my trackpad. for some strange reason
04:58 PM Emil: thardin: it's pure text, no html, css or js in between :D
04:58 PM Emil: thardin: if you can't scroll the issue is definitely on your end
04:58 PM thardin: I mean on the landing page
04:58 PM Ameisen: I don't usually say something factually unless I'm pretty damned sure I'm right, so I tend to get irate when people then say it's wrong, even after I provide substantial evidence.
04:58 PM thardin: which certainly links to a style.css. hmm
04:59 PM Emil: thardin: so you mean my frontapge?
04:59 PM thardin: that's the word
04:59 PM Ameisen: home page
04:59 PM Emil: thardin: you shouldn't be able to scroll at all
04:59 PM Emil: thardin: are you on a small screen?
04:59 PM Ameisen: heafodtramet in old english
04:59 PM thardin: I am. and/or I increase text size
05:00 PM Emil: thardin: hmm, lemme enable scrolling
05:01 PM Emil: it's definitely a ux issue
05:01 PM thardin: some days I feel like css was a mistake
05:01 PM Emil: thardin: noooo
05:01 PM thardin: sweet, works now
05:02 PM Emil: it was disabled because of reasons but since you can scroll anwyays it's an ux issue and should be easy for those realy needing it
05:03 PM Emil: Ameisen: I could mine salt out of you for decades, I say
05:03 PM Ameisen: Probably. I am an American.
05:03 PM Ameisen: We have a lot of salt in our diets.
05:05 PM Emil: It's extra spicy salt also. It only grows on people who are wrong and really salty about it all the time, I must refer you to my local reseller to see if we can get mining rights.
05:08 PM Ameisen: Appalachian Blue Salt
08:22 PM Jan-: ooh, is Tom_L still a user here?
08:22 PM Jan-: he is!
08:22 PM * Jan- pokes Tom_L hopefully
08:24 PM Jan-: I have one of Tom_L's ICSP programmers here, it's marked "USBTiny Mk. II LUFA Powered" and we need to connect it up to a (cheap clone of an) Arduino board. There's six pins on the board, but three different six pin sockets on the programmer.
08:24 PM Jan-: Can anyone shed any light on this?
08:50 PM Tom_L: the one that says ISP
08:50 PM learath: you'll need to know the pinout.
08:50 PM Tom_L: they are marked
08:50 PM learath: hah
08:50 PM learath: or just assume the cheap clone is wired right :P
08:50 PM Tom_L: http://tom-itx.no-ip.biz:81/~webpage/boards/USBTiny_Mkii/USBTiny_Mkii_User_manual_index.php
08:50 PM Tom_L: pinout midway down
08:51 PM Jan-: oh.
08:51 PM Jan-: hey
08:51 PM Tom_L: gotta run though..
08:51 PM Jan-: argh
08:51 PM Jan-: we traced out the power and ground on the clone
08:51 PM Tom_L: back in 20
08:51 PM Jan-: ah.
08:51 PM Jan-: might have to be tomorrow night
08:51 PM Jan-: it's 2am here
08:51 PM * Jan- has work and everything
11:31 PM Ameisen: arm-none-eabi-objcopy: lib_a-sf_scalbn.o: plugin needed to handle lto object
11:53 PM _ami_: Ameisen, ?
11:57 PM Ameisen: that's a new, intriguing error I've not dealt with
11:57 PM Ameisen: never had objcopy throw that
11:57 PM Ameisen: 'specially since objcopy doesn't take plugins