#avr Logs
Nov 27 2017
#avr Calendar
12:24 AM nuxil: Tom_L, https://www.youtube.com/watch?v=WcbGRBPkrps .. next up a T-70 vatiant
01:37 AM [1]MrMobius is now known as MrMobius
01:46 AM Thrashbarg_ is now known as Thrashbarg
02:00 AM _ami_: Tom_L, hey
02:00 AM _ami_: you were asking something about protocol yesterday?
02:00 AM _ami_: i was in hurry so could not able to reply.
02:01 AM nuxil: _ami_, we where woundering why you use a arm chip on your programmer. a bit overkill :p
02:02 AM _ami_: nuxil, i plan to add other features like usb to serial support, hvp (may be)
02:03 AM _ami_: i have already added usb to serial support - did not push the code yet.
02:04 AM nuxil: ok. add hv for sure. its verry handy, esp for noobs like me who mess up clk fuses all the time :p
02:04 AM _ami_: it uses dma to transfer Tx data which is pretty FAST
02:04 AM _ami_: hvp circuit is bit tricky though
02:04 AM nuxil: not really.
02:04 AM nuxil: all you need is 12v on the reset pin
02:06 AM nuxil: maybe a jumper on the breakout board wher you can select 5v and 12v. or do it with logics.
02:07 AM nuxil: 5v to 12v dc/dc converters comes in all sizes these days
02:08 AM _ami_: nuxil, not much high current requirement on 12v? just the voltage do the job?
02:09 AM nuxil: maybe you can use a walton multiplier.
02:09 AM _ami_: does avrdude support it?
02:09 AM nuxil: _ami_, im not sure how much current it uses when 12v on the reset
02:10 AM nuxil: well. yes. avrdude supports it. cos avrdude dosent know about the pin voltage.
02:10 AM _ami_: nuxil, hvp might be useful for DIP size chips
02:10 AM nuxil: you just reset the fuse. set it back to 5v and program it as normal.
02:10 AM _ami_: i wonder how would you do hvp on a QFN chip?
02:11 AM nuxil: no idea. i just mess with dip chips.
02:11 AM * _ami_ reads at https://www.gammon.com.au/forum/?id=12898
02:11 AM cehteh: doesnt hv need some other programming protocol?
02:11 AM nuxil: not that i know of.
02:11 AM cehteh: i never checked
02:12 AM nuxil: i messed up my fuses several times on my atiny85. to reset it i set the default values. set the reset pin to 12v and upload new fuse values.
02:12 AM nuxil: works.
02:12 AM cehteh: otherwise generating 12v with a charge pump should be trivial
02:12 AM cehteh: ok
02:13 AM _ami_: cehteh, http://mightyohm.com/blog/wp-content/uploads/2008/09/hvfuse.pde -> code looks simple though.
02:13 AM _ami_: http://mightyohm.com/blog/2008/09/arduino-based-avr-high-voltage-programmer/
02:13 AM cehteh: i never needed hv
02:14 AM _ami_: yeah, same here. i did not mess up fuse settings yet
02:14 AM nuxil: better to have it and not need it. than not have it and need it :p
02:18 AM nuxil: _ami_, my selfmade atiny85 programmer looks verry much like that one. :)
02:19 AM _ami_: nuxil, seems like u really can;t do hvp on QFN, since normal board/circuit does not expect 12v on /RESET pin
02:20 AM _ami_: To use the high-voltage programming you almost certainly need to remove the chip from its circuit, and place it into a special programming jig
02:21 AM daey: nuxil: you can manually apply 12V to the reset pin and then simply flash it normally?
02:23 AM nuxil: yes
02:23 AM nuxil: wait
02:23 AM _ami_: no, the protocol is different.
02:23 AM nuxil: i only program the fuse
02:25 AM nuxil: https://pastebin.com/qsiVYazV thats all i do.. i got a jumper on my board that changes the reset pin from 5v to 12v
02:26 AM nuxil: then i set the jumper back to 5v and program it normally.
02:26 AM _ami_: nuxil, you might have done HV serial programming on t85 since it does not have enough pins for doing hv parallel programming.
02:27 AM nuxil: yes. its hvsp
02:27 AM _ami_: hvsp only works for attinys? or for all avrs?
02:27 AM nuxil: i thought it worked for all avrs.
02:27 AM nuxil: now you made me unsure
02:30 AM nuxil: _ami_, the datasheet for the atiny has a "High-voltage Serial Programming"
02:30 AM nuxil: section
02:30 AM _ami_: i think its only for attinys
02:31 AM _ami_: let me check mega ds
02:32 AM nuxil: yea my atmega324 dosnt do serial
02:33 AM nuxil: seems like a tiny thing
02:33 AM _ami_: yeah
02:34 AM nuxil: thats sad tho. cos its really simple way.
02:34 AM nuxil: + you could have 1 programmer support atiny+atmega without extra stuff
02:37 AM rue_bed: what!? I'm completely sure the 324 does serial
02:38 AM rue_bed: you mean serial programming? self flashing?
02:38 AM nuxil: hv
02:41 AM _ami_: rue_bed, high voltage
02:41 AM _ami_: not the ICSP
02:41 AM nuxil: my datasheet for my atmega324p does only speak of high voltage parallel programming.
02:41 AM nuxil: while the atiny only speaks of hvsp
02:41 AM _ami_: nuxil, yes, same for m16a
02:41 AM rue_bed: ah, controllers with a dedicated reset pin might not support hv programming
02:41 AM rue_bed: seeing as its not needed
02:41 AM rue_bed: on account of the dedicated reset pin
02:41 AM _ami_: rue_bed, yes, hv{s/p}p is valid for those case where you can actually remove the chip from circuit
02:41 AM _ami_: and place it into a some special programming jig.
02:41 AM rue_bed: why not just use a chip clip :)
02:41 AM rue_bed: dont use any of the programming pins to trigger the explosive
03:59 AM _ami_: http://www.zdnet.com/article/linux-totally-dominates-supercomputers/
03:59 AM _ami_: "all 500 of the world's top 500 supercomputers are running Linux."
04:09 AM cehteh: now we only need linux on the desktop
04:11 AM twnqx: 2018 will be the year of the linux desktop!
04:12 AM nuxil: you wish
04:13 AM nuxil: linux will never rule the desktop.
04:14 AM nuxil: all the good desktop apps are on windows. + 99% of the games are written for windows.
04:15 AM nuxil: so if you can get big corps like adobe. autodesk ++++ tonz of others to make their toolchain for linux. then maybe in 10years or so. :p
04:18 AM _ami_: nuxil, i play xonotic game on linux with my colleagues at work on Linux. :)
04:18 AM _ami_: they all run linux though :)
04:22 AM nuxil: sure. i bet you can play a solitaire clone too. my point is. without "aaa" games and proffesional tools. like adobe, Photoshop, autodesk, 3dmax, c4d, +++ linux has no way to rule the desktop.
04:22 AM nuxil: +. gcc nightmare with linux
04:22 AM _ami_: nuxil, its a FPS game
04:23 AM _ami_: gcc is pretty nice.
04:23 AM _ami_: but yeah, i get your point.
04:23 AM _ami_: there are alternatives to these softwares
04:24 AM _ami_: but yeah, not so great or not everybody is used to it
04:24 AM nuxil: not really. gimp isnt an alternative to photoshop. bender isnt a alternative to autodesk,c4d etc.
04:24 AM _ami_: and not everybody in this world is smart.
04:26 AM nuxil: besides. lets say a frim makes a tool with some old gcc. and put out the bin. unless you have the same compative gcc version its gonna cause you headache
04:26 AM nuxil: *compatible
04:27 AM nuxil: so. in short.. to many dumb people out there for linux to rule the desktop :p
04:50 AM nuxil: https://www.youtube.com/watch?v=o4PFDKIc2fs
05:10 AM _ami_: lol, that guy works at @github
05:11 AM _ami_: it was though shameless promotion of git.
05:12 AM nuxil: funny video tho.
09:04 AM enh: Good afternoon!
09:05 AM polprog: afternoon
09:05 AM enh: all right?
09:06 AM polprog: pretty good
09:06 AM polprog: gotta write a short essay about a painting
09:07 AM enh: Which painting?
09:07 AM polprog: umm, gimme a sec, i need to find the english title
09:07 AM enh: Writing is a good exercise. Writing well makes a huge difference nowadays.
09:08 AM polprog: i enjoy it
09:08 AM polprog: yesterday i had to write a Hamlet movie review
09:08 AM polprog: "Minevra Protecting Peace from Mars"
09:08 AM enh: There is a nice software to help writing novels. From Mariner soft. Helps plotting.
09:08 AM polprog: by Rubens
09:09 AM enh: never seen
09:09 AM polprog: i have most of the facts written out on paper
09:09 AM polprog: it's baroque. usual stuff on there
09:09 AM enh: interesting
09:10 AM enh: I've always wanted to write a sci fi novel, but all I could do were two thesis.
09:10 AM polprog: the english wikipedia entry is surprisingly short
09:10 AM polprog: i was thinking about scifi novels
09:10 AM polprog: with my knowledge of IT or tech in general
09:10 AM polprog: mine could actually get the tech part right :D
09:11 AM enh: it can help a lot
09:11 AM polprog: if you like scifi try to find some novels by Lem
09:11 AM polprog: he described the internet before it existed in one of his novels
09:11 AM polprog: they are also very deep
09:11 AM enh: there is the "show don't tell" thing, which is hard to master
09:11 AM enh: Lem?
09:11 AM polprog: Stanislaw Lem
09:12 AM enh: I'll do a search on amazon
09:12 AM polprog: his works were transleated into a lot of languages
09:14 AM enh: found some now. Very interesting. Recommend any?
09:15 AM polprog: been a long time since i read
09:15 AM polprog: Fables of Robots
09:15 AM polprog: this one is good
09:15 AM enh: He wrote many books...
09:16 AM polprog: my favourite tale is the one about uranium ears. and there's also Cyberiad
09:18 AM enh: They must be very good. Average price is higher than normal. Around $8
09:25 AM enh: I created a mail list for the people from this channel, in case a meteor strikes the freenode IRC servers. To join, send a message to avr-and-other-stuff-subscribe@yahoogroups.com
09:25 AM enh: It is restricted, to restrict spam.
09:27 AM enh: First ones to join will be made moderators, Last ones too.
09:27 AM polprog: anything specific in the message body?
09:27 AM enh: I believe not
09:28 AM enh: rue_bed: Emil, Casper, Tom_L, please join too
09:29 AM enh: everybody is invited
09:30 AM enh: https://groups.yahoo.com/neo/groups/avr-and-other-stuff/
09:34 AM Emil: war
09:34 AM Emil: >yahoo
09:34 AM enh: There is a file repo there. We can keep a small library
09:34 AM Emil: yeah, no
09:34 AM polprog: avr group on google groups is full of spam
09:35 AM polprog: which, cosidering the dataset google owns, is very, very unusual to me
09:35 AM enh: we can keep this restricted. Having a common library is a good thing.
09:36 AM enh: ops... Only 100MB
09:37 AM polprog: should be enough for code
09:38 AM enh: yep
09:38 AM enh: What about ebooks?
09:38 AM polprog: hmm
09:38 AM enh: Is there a place where we can keep them?
09:38 AM enh: And share between members?
09:39 AM polprog: most of us keep some files on our personal servers. decentralized. also im not sure about copyrights to those. i have a pdf of "the c programming language" among others but i dont wanna publicly upload it to polprog.net/papiery
09:39 AM enh: should be a restricted groups space
09:40 AM enh: Coud be a private repo.
09:46 AM polprog: gotta write the thing
09:49 AM enh: Made you owner of the list too. Good writing.
09:50 AM polprog: thanks
09:50 AM polprog: i hope ill write it quickly
09:51 AM enh: listen to your heart. Sometimes it is better than listening to the mind.
09:51 AM polprog: especially in baroque
10:36 AM Emil: polprog: that's why you don't do directory listing ;)
10:37 AM Emil: Unless specifically allowed
12:01 PM polprog: Emil: that might work
12:01 PM polprog: i was also thinking about setting up htaccess
12:01 PM Emil: >apache
12:01 PM Emil: bro
12:02 PM Emil: no
12:02 PM polprog: not again
01:16 PM polprog: piad for 4 pcs of the clock pcb
01:17 PM polprog: ill probably get them on the weekend
01:17 PM polprog: paid*
01:17 PM nohitzzz: nice
01:38 PM nohitzzz: are you gonna build 4 clocks ?
01:39 PM polprog: maybe
01:39 PM polprog: dad says he wants one as well ;)
01:39 PM nohitzzz: what kind of case youre gonna use
01:39 PM nohitzzz: (if any)
01:39 PM polprog: if any then a piece of acrylic
01:39 PM polprog: the idea is that pcb mostly hides behind the displays and the whole thing stands on the display side
02:04 PM polprog: i wonder if i manage to get a decent refresh rate with 8 digits
02:09 PM Tom_L: fpga
02:09 PM Tom_L: cpld
02:49 PM polprog: good night everybody
02:49 PM nohitzzz: nite
03:50 PM Fabiola: hola
03:50 PM Fabiola: que tal??
03:51 PM Fabiola: nadie??
03:52 PM Ameisen: ... si
03:58 PM Ameisen: So... one thing I want to do (presumably in clang) is add an alternate integer promotion scheme for AVR
03:58 PM Ameisen: maybe as an option
03:58 PM Ameisen: so things don't by default promote to 'int', and then implicitly go (signed->unsigned->next signed->etc)
03:58 PM Ameisen: but rather prefer to stay in their signedness, and try to promote as small as possible instead
03:59 PM Ameisen: and ops where truncation can be done (rather than requiring promotion) will prefer _demotion_, for instance, uint16_t & uint8_t... that can be treated as a demotion (uint8_t(uint16_t) & uint8_t), rather than promoting the uint8_t to a uint16_t
03:59 PM Ameisen: which will help the optimizer
04:23 PM thardin: that'd be nice
04:23 PM thardin: I did __int24 * int8_t multiplication in a project, was rather annoying to have to upcast to 32x32 then 64->32
05:11 PM Ameisen: thardin - aye
05:11 PM Ameisen: in C++, I generally explicitly cast things if they're different tpyes beforehand
05:11 PM Ameisen: I hate doing it
05:11 PM Ameisen: it makes code so messy
05:11 PM Ameisen: the alternative is writing template functions like 'multiply' instead of using *
05:11 PM Ameisen: just as messy, of course
05:12 PM Ameisen: and the promotion stuff causes bugs, sometimes, in the compiler
05:12 PM Ameisen: like the gcc bug I'm still waiting to be fixed
05:12 PM Ameisen: uint8 shifting in g++ causes... really really bad code
05:12 PM Ameisen: because of promotion rules and something not getting reduced correctly in the middle end
05:12 PM Ameisen: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82658
05:12 PM Ameisen: doesn't happen in Clang
05:18 PM thardin: doesn't C do silly things like automatically promote to int?
05:18 PM thardin: I forget what the spec has to say
05:19 PM Ameisen: C and C++ both do.
05:19 PM Ameisen: That's the basic type promotion rules
05:20 PM Ameisen: different types promote to int (if int doesn't fit, they promote to the type that fits them both)
05:20 PM Ameisen: thus why uint32_t == uint16_t can throw a 'signed/unsigned comparison' warning
05:20 PM Ameisen: on x86
05:20 PM thardin: sounds like it should be possible to implement while staying try to the spec then
05:20 PM thardin: assuming int == 16-bi
05:20 PM Ameisen: (16_t == 8_t on AVR)
05:20 PM thardin: t
05:20 PM Ameisen: the uint8_t will promote to 'int'
05:20 PM Ameisen: which is int16_t
05:20 PM Ameisen: it then compares that to uint16_t
05:21 PM Ameisen: and thus you are comparing signed and unsigned
05:21 PM Ameisen: the uint8_t SHOULD promote to uint16_t
05:21 PM Ameisen: however, that's not what the spec says.
05:21 PM thardin: hooray!
05:21 PM thardin: well, at least you have the option. unlike java
05:21 PM Ameisen: what would be even better is just a proper optimization pass that reocgnizes uint16_t and uint8_t, checks if uint16_t has any bits set in the upper byte (if it does, it's obviously not equal), then does a uint8_t compare
05:22 PM thardin: I want 40, 48 and 56-bit ints on avr too
05:22 PM thardin: feels like you could automagically generate all of them. should be a fairly regular pattern
05:22 PM Ameisen: easy to implement in Clang.
05:22 PM Ameisen: Problem is Clang is still very underoptimized for AVR
05:22 PM Ameisen: I'm helping with it
05:22 PM Ameisen: but it will be a while
05:22 PM Ameisen: very, very easy to define new integer types there though
05:23 PM Ameisen: I also want to add float16/float24
05:23 PM Ameisen: float8 seems useless
05:23 PM thardin: float8 sounds like ยต-law
05:23 PM Ameisen: possibly also a built-in fixed-precision type for C++. Unsure yet.
05:23 PM Ameisen: Since technically a class-based fixed type should be equivalent
05:23 PM Ameisen: I have an unsigned fixed_type in my C++ AVR code
05:23 PM Ameisen: which takes an underlying type, and number of fractional bits
05:24 PM Ameisen: then some autogenerators for the type where you can give max/min values and it will autogenerate a fixed type for you
05:24 PM Ameisen: self-regenerating code :)
05:25 PM thardin: I quite like generators too
05:25 PM thardin: or, I guess this is just c++ templates. which can also be fine
05:25 PM Ameisen: in C++, with constexpr, you don't need separate tools/passes to make the code, though
05:25 PM Ameisen: you can do it entirely within the compiler
05:25 PM thardin: sometimes I like to have explicit generated code
05:26 PM Ameisen: sure
05:26 PM Ameisen: but sometimes it's nice to have code that derives itself from values
05:26 PM Ameisen: so if you change something, you don't have to rewrite 50 things
05:26 PM Ameisen: also self-optimizes
05:26 PM thardin: make ;)
05:26 PM Ameisen: my integer interpolation code for temperatures will changes the types used in the function based on the values in the tables
05:26 PM Ameisen: to minimize cycles
05:26 PM thardin: clever
05:27 PM Ameisen: it will also use different algorithms for searching the table if the ADC value you give is at certain points in the table (for instance, it KNOWS the temp must be stored in an int16_t instead of 8_t)
05:27 PM Ameisen: increases PROGMEM size a bit if you enable that
05:27 PM Ameisen: but it makes it quite a bit faster
05:27 PM Ameisen: I'm on an atmega2560, so increased progmem is fine
05:27 PM Ameisen: i'm at less than 50% anyways
05:27 PM Ameisen: and my build options tend to generate smaller code than Os
05:27 PM Ameisen: https://github.com/ameisen/Tuna-i3-Plus/blob/master/Tuna/tunalib/fixed.hpp
05:27 PM Ameisen: which I did post here a few days ago
05:28 PM Ameisen: I was tinkering with the g++ build flags, found a better set of options than just using -Os
05:28 PM Ameisen: which generates _smaller_ code than just -Os, and also better code
05:28 PM Ameisen: I can go even smaller pretty easily
05:28 PM Ameisen: I haven't done more on it as my 'tiny' build is not presently a focus
05:29 PM Ameisen: https://github.com/ameisen/Tuna-i3-Plus/blob/master/Tuna/rbbuild/gcc_buildhandler.rb
05:29 PM Ameisen: some important ones are the --param flags
05:29 PM Ameisen: which alter how the internals of gcc work
05:29 PM Ameisen: mainly setting attempts/loops/etc to huge values
05:29 PM thardin: at that point I'd probably start writing asm
05:29 PM Ameisen: which forces GCC to try optimizing with larger and larger blocks, and not to 'give up'
05:29 PM Ameisen: if I turn off those params, my progmem jumps a few KiB
05:29 PM Ameisen: if you turn FAST_BUILD to 'false', it will slow down your compile about 30x
05:30 PM Ameisen: and I haven't seen a benefit yet, though it probably depends on the project
05:30 PM Ameisen: some of the options _shouldn't_ help, but do
05:30 PM Ameisen: my comments usually indicate such
05:30 PM Ameisen: like 'why the hell does this help?'
05:30 PM Ameisen: here's one
05:31 PM Ameisen: "-ftree-loop-vectorize", # Perform loop vectorization. Generates better code for some reason. TODO Investigate why, as AVR has no concept of vectored code.
05:31 PM thardin: you could also have a little loop that tries all combinations if you want to be crazy
05:31 PM Ameisen: that option should not help AVR at all
05:31 PM Ameisen: AVR has no vectored ops
05:31 PM Ameisen: it doesn't benefit from loops set up for vectorization
05:31 PM Ameisen: however, turning on loop vectorization... generates better and smaller code.
05:31 PM Ameisen: I have absolutely no idea why
05:31 PM Ameisen: probably emits better IL that lets the optimizer do a better job
05:31 PM Ameisen: other ones that SHOULD help do the opposite
05:32 PM Ameisen: I tinkered with basically every optimization flag
05:32 PM Ameisen: to find the best combinations
05:32 PM Ameisen: My Tuna firmware work is probably the most thorough avr-g++ flag testing there is
05:32 PM Ameisen: using my flags will almost always make your progmem smaller.
05:32 PM Ameisen: and should make your code faster
05:32 PM Ameisen: note that I use gcc 7.2.0
05:32 PM thardin: oh, 3d printer stuff
05:32 PM Ameisen: yeah
05:33 PM Ameisen: but compiler options shouldn't care if it's for a printer or anything else.
05:33 PM Ameisen: they're setting up the compiler/optimizer in a way that generates better/smaller code
05:33 PM thardin: does it make it print faster in the end? like parse gcode faster or so
05:33 PM Ameisen: I can almost guarantee if you use those options with TINY_CODE set to 'true', you will have smaller code.
05:33 PM Ameisen: the print should never be faster
05:33 PM Ameisen: what will be better is generally that you will miss fewer steps
05:34 PM Ameisen: accuracy will be higher since you are getting ISRs executed faster
05:34 PM Ameisen: important for my firmware since it's based on Marlin
05:34 PM Ameisen: and Marlin uses floats heavily
05:34 PM Ameisen: I haven't replaced those parts entirely yet
05:34 PM thardin: ah, that explains the fixed point
05:34 PM Ameisen: when I replace the floats with fixed, it will be 10-100x faster
05:34 PM Ameisen: floats are VERY slow to emulate in this context
05:34 PM thardin: wait so it uses a crummy 8-bit? uhh
05:34 PM Ameisen: yup
05:34 PM Ameisen: Marlin is designed for AVR8
05:34 PM Ameisen: I didn't say designed _well_
05:34 PM Ameisen: it does work though, which is why I based my code on it initially
05:35 PM thardin: guess this goes back 10 or so years
05:35 PM Ameisen: whenever I rewrote something, I knew it worked originally.
05:35 PM thardin: cortex is cheap enough now
05:35 PM Ameisen: So it should continue to work after my stuff was n
05:35 PM Ameisen: in
05:35 PM Ameisen: Makes testing easier.
05:35 PM Ameisen: Yup, but printers are still being released with atmel
05:35 PM Ameisen: like mine
05:35 PM Ameisen: :}
05:35 PM Ameisen: no idea why
05:35 PM Ameisen: regardless, my firmware, when done, should be able to do similar things to the firmwares on cortex chips
05:35 PM Ameisen: my code is way faster
05:36 PM thardin: some guys at my hackerspace are trying to resurrect an old makebot cupcake
05:36 PM Ameisen: which gives me more free cycles to do more things (like movement smoothing)
05:36 PM Ameisen: marlin 'sort of' tries to minimize jerk
05:36 PM Ameisen: but in reality it is minimizing acceleration
05:36 PM Ameisen: the higher order movement calculations require far more cycles
05:36 PM Ameisen: no way Marlin could do it with floats
05:36 PM Ameisen: you'd be missing steps all the time
05:36 PM Ameisen: once my changes are complete? It might be doable.
05:37 PM Ameisen: less jerk in the printer then, less ringing in prints, everything is nicer.
05:37 PM Ameisen: print quality goes up.
05:37 PM thardin: guess it's good for all those existing printers. I'm lazy so I'd just buy a new controller :)
05:37 PM thardin: perhaps I should tip them about this tho
05:38 PM thardin: the 3d printer guys that is
05:38 PM Ameisen: mreh, they know I'm working on it
05:38 PM Ameisen: they're incredibly skeptical of my stuff since it's rather radical
05:39 PM Ameisen: my code is rather complex and is very, very much C++17
05:39 PM Ameisen: I can prove some improvements, but nobody will be convinced until I'm actually done
05:39 PM Ameisen: most people writing firwmares like this are old school C'ers
05:39 PM Ameisen: even the C++ in firmware is usually 'C with Classes'
05:39 PM Ameisen: so my stuff is a radical departure from the norm
05:40 PM Ameisen: very, very hard to convince anyone that it's a good idea
05:40 PM Ameisen: most people still throw 'but templates bloat code!' around
05:40 PM thardin: performance speaks, in the end
05:40 PM Ameisen: a concept that hasn't been true for 10 years
05:40 PM Ameisen: but still comes up
05:40 PM thardin: c++ template syntax is awful tho
05:40 PM Ameisen: better than macros!
05:40 PM Ameisen: :)
05:40 PM Ameisen: I use constexpr more than templates when I can
05:40 PM Ameisen: C++17 constexpr allows rewriting a lot of what used to be functional templates into constant expressions.
05:40 PM thardin: yeah but compared to like.. anything. even lisp
05:41 PM Ameisen: much easier to read
05:41 PM Ameisen: this is one of my favorite things to do now
05:41 PM Ameisen: which you used to have to use templates for
05:41 PM * Ameisen is writing some code one sec
05:41 PM thardin: oh yeah the old enum hack for constants
05:42 PM Ameisen: template <size_t N> constexpr auto get_smallest_type () { if constexpr (N <= 255) return uint8_t{}; else if constexpr (N < 65535) return uint16_t{}; ... }
05:42 PM Ameisen: using some_type_t = decltype(get_smallest_type<2642>());
05:42 PM Ameisen: some_type_t is now the smallest type ('using' is a nicer replacement for typedef) that can fit '2642'
05:42 PM Ameisen: I then often wrap that further with something like
05:43 PM Ameisen: auto var = make_smallest_type<2642>
05:43 PM thardin: this feels like Ada land
05:43 PM Ameisen: which will declare 'var' to be the smallest type, and assign it 2642.
05:43 PM Ameisen: C++ has been moving towards being more functional for some time
05:43 PM Ameisen: which is good, but a lot of people haven't kept up
05:43 PM Ameisen: so the new code is bizarre to 'em
05:43 PM Ameisen: it's _incredibly_ useful in low-level code like firmware
05:44 PM Ameisen: but it's REALLY hard to convince someone who's been using C for _decades_ that it's a good idea.
05:44 PM Ameisen: https://github.com/ameisen/Tuna-i3-Plus/blob/master/Tuna/thermistors/thermistortable_1.h
05:44 PM Ameisen: the code is incredibly messy
05:44 PM Ameisen: because I haven't finished cleaning it up
05:44 PM Ameisen: but that's the thermistor lookup code that uses type/value derivation to optimize the search algo
05:44 PM Ameisen: also I need to add comments
05:45 PM Ameisen: though the function names are fairly descriptive
05:45 PM Ameisen: line 358 is the start of the actual search function
05:45 PM Ameisen: it redefines all the constraints used based upon input data and value derivation (some of it compile time, some of it runtime, based upon compile-time values) to minimize the time spent in the function
05:46 PM Ameisen: if you alter the values in the temperature table at the top, the code generated will be different
05:46 PM Ameisen: without any intervention on your part
05:46 PM Ameisen: so potentially less buggy.
05:46 PM Ameisen: some of the code is worse than it has to be because g++ doesn't support __flash
05:46 PM Ameisen: like gcc does
05:47 PM thardin: I wonder if a debugger could make sense of it
05:47 PM Ameisen: so I have to do hacky stuff to use progmem values
05:47 PM thardin: that's the real problem with stuff like this
05:47 PM Ameisen: well, constexpr functions that are resolved in compile-time...
05:47 PM Ameisen: obviously a debugger cannot debug that
05:47 PM Ameisen: since it is never executed.
05:47 PM Ameisen: otherwise, it should have zero issue
05:47 PM Ameisen: templated functions are instantiated separtely (unless code-folding folds it)
05:47 PM Ameisen: and their debug data is as well
05:47 PM Ameisen: My MIPS emulator uses ELF and normal debugging data
05:47 PM thardin: refactoring C++ code is an unsolveable problem. as in, just renaming something in any kind of not-dumb way
05:47 PM Ameisen: works absolutely fine with fancy C++
05:48 PM Ameisen: Hell, I was able to tie gdb into Visual C++'s debugger
05:48 PM Ameisen: I was debugging my MIPS programs, running in my MIPS emulator, line by line in Visual C++
05:48 PM Ameisen: with full ability to read values, hover over things, change things, etc
05:48 PM Ameisen: it was neat as hell
05:48 PM Ameisen: debuggers don't really have difficulty with C++ these days.
05:48 PM Ameisen: 10 years ago, maybe
05:48 PM thardin: my experience with debugging anything clever has always been pain
05:48 PM Ameisen: well, in the case of this, the cleverness is mostly compile-time
05:49 PM Ameisen: otherwise it's a normal templated function
05:49 PM Ameisen: the debugger will see it as such
05:49 PM Ameisen: I actually tested these algorithms on my PC with Visual C++ first
05:49 PM Ameisen: I had zero difficulty debugging it
05:50 PM Ameisen: the main thing which can be sometimes difficult to derive is if it's a templated function, _which_ template instantiation are you in
05:50 PM Ameisen: the data is there, just sometimes the debugger doesn't know how to tell you
05:50 PM thardin: myeah
05:50 PM Ameisen: like, are you in binsearch_temp_get_branched<true, true>? binsearch_temp_get_branched<true, false?
05:50 PM Ameisen: The debugger knows.
05:50 PM Ameisen: It shows the right data. It just doesn't always tell you nicely.
05:50 PM Ameisen: That's a fault with the debugger, though, IMO
05:51 PM Ameisen: Visual C++'s debugger does it right now-a-days
05:51 PM Ameisen: haven't tried it in GDB, it _probably_ does
05:51 PM Ameisen: You should be able to use my gdb bridge actually with visual c++, and debug AVR software using VC++'s debugger
05:51 PM Ameisen: if it works for MIPS, it should work for AVR
05:52 PM Ameisen: so long as you have a gdb hook somewhere
05:52 PM Ameisen: which I imagine most AVR simulators do
05:52 PM Ameisen: it's hard to beat VC++'s debugger - it's what everyone else tries to emulate
05:52 PM thardin: indeed
05:52 PM Ameisen: Seriously, though
05:52 PM Ameisen: I cannot overstate how awesome it was to debug MIPS programs in VC++
05:53 PM Ameisen: which were running in an emulator.
05:53 PM Ameisen: all of which I wrote
05:53 PM Ameisen: it was like 'holy crap this is awesome'
05:53 PM Ameisen: the pinnacle of emulation support.
05:53 PM Ameisen: then VC2017 came out
05:53 PM Ameisen: and they changed how gdb worked with it
05:53 PM Ameisen: and my bridge broke.
05:53 PM Ameisen: :(
05:55 PM Ameisen: I get really excited about these things.
07:11 PM Ameisen: Are there any good multicore ARM boards that have a substantial number of GPIO
09:42 PM [1]MrMobius is now known as MrMobius
10:57 PM anonnumberanon: was this channel created when the avr first came about?
11:01 PM Casper: close
11:01 PM rue_mohr: hah no
11:01 PM rue_mohr: it was created a few years before arduino became aminstream
11:35 PM day__ is now known as daey