#avr Logs

Oct 26 2017

12:07 AM day__ is now known as daey
03:40 AM rue_bed: installed it in the pendant, installed the jack and called it a day
03:41 AM rue_bed: next I need to make up the rs232 converter and the 5V regulator
07:58 AM Emil: cehteh: are there smd capacitors that I can use for that capacitive power supply?
07:59 AM cehteh: dunno, but likely
08:00 AM cehteh: do a great voltage overating
08:00 AM Emil: So I should set voltage rating ac to like, 450 volts?
08:00 AM Emil: minimum
08:00 AM Emil: 325v is the peak voltage
08:01 AM Emil: 300V AC rating should be enough?
08:01 AM cehteh: yes, or the mroe the better
08:01 AM cehteh: think about voltage spikes/transitents on main
08:01 AM Emil: true
08:01 AM cehteh: and need to be x2 rated, self healing foil
08:02 AM Emil: film?
08:02 AM Emil: x2 rated?
08:02 AM cehteh: yes .. dunno the exact specs and how is that called in english
08:03 AM cehteh: basically means when it arcs over due a voltage peak it just burns its coating away locally, making the defect isolated
08:03 AM cehteh: loosing a bit capacitance, but will not go up in smoke
08:04 AM cehteh: i tihnk i only seen through hole ones
08:04 AM Emil: What do you recommend as mains protection? polprog liked varistors but tvs might be enough?
08:15 AM cehteh: just a fuse
08:15 AM Emil: https://emil.fi/jako/kuvat/2017-10-26_15-44-10_2MU95u6g.png
08:15 AM Emil: I can use a tvs like that, right? :D
08:16 AM cehteh: failure mode would be that the cap shorts
08:23 AM Emil: There is a fuse already
08:26 AM cehteh: should be enough, you have a zener to cap the voltage?
08:26 AM Emil: https://emil.fi/jako/kuvat/2017-10-26_15-54-51_y4ZKs2qN.png
08:27 AM cehteh: looks good
08:27 AM cehteh: well where is said fuse?
08:28 AM Emil: It's before this circuit
08:28 AM cehteh: only protecting the cap-PS?
08:28 AM cehteh: then you can use a fast, little one
08:28 AM Emil: No
08:28 AM Emil: Also protecting additional circuitry
08:29 AM cehteh: mhm how much current does that draw?
08:29 AM Emil: Iirc the fuse is a 2A one
08:29 AM cehteh: woah
08:29 AM cehteh: way too high
08:29 AM cehteh: you want a small one
08:30 AM cehteh: 2A @ 230V ... 460Watts :D ..
08:30 AM Emil: Yes, it's for the whole device
08:30 AM Emil: You reckon I should have another fuse
08:31 AM Emil: For this section only?
08:33 AM cehteh: yes .. or maybe the cap-ps + you have some ps for your avr? .. just the low current parts
08:34 AM cehteh: just think what you want to protect, when the cap on the PS fails then it shorts, that means 230V~/2A going over all traces and components in the way
08:34 AM cehteh: thats prolly as good as having no fuse, the resistors will blow :D
08:35 AM cehteh: and the zener
08:35 AM cehteh: and the opto ..
08:35 AM Emil: Hmm
08:35 AM cehteh: and . well you get the idea :)
08:35 AM Emil: Can I use a polyfuse with AC
08:36 AM cehteh: no, expect that this fuse is only for protection and should never blow under normal circumstances, when it blows, then something else bad
08:36 AM cehteh: resetting polyfuse would be counterproductive
08:40 AM Emil: true
08:40 AM Emil: I'll add a small fuse
08:40 AM Emil: cehteh: regarding the CP supply
08:41 AM Emil: only the capacitor and the bleed resistor need to be rated for high voltages, right
08:41 AM cehteh: yes
08:42 AM cehteh: the 100ohms should/could be explicitly low rated, often resistors of blow open type are used instead of a fuse
09:22 AM Emil: https://www.mouser.fi/ProductDetail/Cornell-Dubilier-CDE/715P10458MD3/?qs=sGAEpiMZZMv1cc3ydrPrF%2fXaoGEw890JCgzwkD%2flR84%3d
09:23 AM Emil: Would that work?
09:23 AM Emil: cehteh:
09:23 AM Emil: https://www.mouser.fi/ProductDetail/Illinois-Capacitor-CDE/104PPA850K/?qs=sGAEpiMZZMv1cc3ydrPrF6UOBDifjZuPKmFvV8Kv3I15BxZ974ILGw%3d%3d
09:23 AM Emil: Or this
09:25 AM Emil: https://www.mouser.fi/ProductDetail/WIMA/MKS4J031004C00KSSD/?qs=sGAEpiMZZMv1cc3ydrPrFwgzP98AO9id9hLtIP3emJc%3d
09:25 AM Emil: Those first two were really expensive
09:26 AM cehteh: i'd go for the mks
09:26 AM cehteh: but try to get better tolerance (that tolerance is reflected directly in the current you get)
09:27 AM cehteh: 10% maybe ok .. but you need to account for that
09:27 AM cehteh: (calibration)
10:18 AM mudkip908_ is now known as mudkip908
11:07 AM Ameisen: back and head hurt today
11:07 AM Ameisen: however
11:07 AM Ameisen: I've made a number of improvements to the clang/llvm AVR backend
11:08 AM Ameisen: there's still more to do
11:08 AM Ameisen: In many common cases, howveer, code will be drastically faster/smaller
11:08 AM Ameisen: in some cases, better than GCC's output
11:08 AM Ameisen: doesn't handle higher-order shifts well, yet. Trying to figure out the Clang syntax.
11:08 AM Ameisen: Also trying to figure out if the optimal shifting pattern for higher orders is something that can be factored down, or must be explicit
11:09 AM Ameisen: like, is breaking down a uint32 shift into two uint16 shifts optimal, or do I need to define 32 shifts for that instead
11:10 AM Ameisen: however, before doing uint16 * 2 encoded _37_ instructions
11:10 AM Ameisen: now it should encode like 4.
11:10 AM Ameisen: It also uses one fewer register than gcc (no __zero_reg__).
11:10 AM * Ameisen returns to his engineering cave
11:12 AM Emil: Ameisen: any shifts by 8*n can be optimised to just writes to sram/register
11:18 AM Ameisen: Emil - I know
11:18 AM Ameisen: these optimizations have to be hand-written in the compiler optimizer, though
11:18 AM Ameisen: GCC has those already, Clang had a 'todo', and implemented all shifts as, well, a loop of shifts
11:18 AM Ameisen: I've implemented _most_ of those, but the higher orders have syntactic difficulties I'm trying to figure out - otherwise it doesn't maintain instruction ordering which breaks things
11:19 AM Ameisen: I also implemented additional capabilities for primitive operations on int8/int16 types. Int16s, I also added support for detecting/optimizing masked adds/subs, like say you add 0xEE00 to an int16
11:19 AM Ameisen: you don't have to touch the lower byte
11:19 AM Ameisen: clang now knows and handles that
11:20 AM Ameisen: before it emitted an add, adding 0, then an adc on the high byte
11:20 AM Ameisen: the implementation in Clang is just very naive because it's very new
11:20 AM Ameisen: so most of the edge case optimizations are not there
11:20 AM Ameisen: I've been going over simple binaries and comparing the GCC and Clang output, and bringing Clang to the same or better for ops
11:21 AM Ameisen: I'd really like to see more than one choice in compiler.
11:21 AM Ameisen: One thing that's wrong in Clang that I haven't fixed - I'm pretty sure AVR has its own ABI (probably designed off of Itanium ABI) like MIPS does
11:22 AM Ameisen: so I need to add that - right now clang presumes a pure Itanium ABI (still not sure why all these random archs use the IA64 ABI), so it may have linkage issues with libraries built by other toolchains
11:23 AM Ameisen: neither the GCC nor the LLVM middle-end make optimization decisions or reduction decisions that make sense for micro-architectures like AVR, so a lot has to be hand-written
11:23 AM Emil: eh?
11:23 AM Emil: what AVR ABI?
11:23 AM Ameisen: GCC's still acts odd re: uint8
11:23 AM Ameisen: Not sure. I'm presuming Atmel defines an ABI somewhere?
11:23 AM Emil: There's AVR-LIBC ABI, sure
11:24 AM Ameisen: Usually architectures (like MIPS) have their own ABI that's tuned to their arch
11:24 AM Ameisen: usually based off of IA64
11:24 AM Emil: And avr-libc is developed a lot by Atmel
11:24 AM Ameisen: I haven't investigated that part heavily, I only have it noted in my todo ilst
11:24 AM Ameisen: list*
11:25 AM Ameisen: https://gcc.gnu.org/wiki/avr-gcc
11:25 AM Ameisen: Clang should replicate what GCC does re: abi, unless it can be done in a better-yet-compliant fashion
11:25 AM Ameisen: I'm not sure if the ABI is equivalent to IA64, or has differences. If it has differences, they need to be handled
11:26 AM Ameisen: I haven't heavily looked into that yet
11:26 AM Ameisen: still alot of codegen issues I'm dealing with
11:27 AM Emil: But it's super awesome that you are doing this!
11:27 AM Ameisen: Which does remind me - instead of doing dumps/using my head for _every single shift case_, is there a table somewhere detailing the optimal instruction sequences for every bit-shift number on every type size?
11:27 AM Emil: Even if it is for Clang and not GCC ;)
11:27 AM Ameisen: I did a little bit of work for GCC. GCC is far harder to build and use on other systems (like Windows), and their interface/instruction APIs internally are harder to use then Clang's
11:27 AM Ameisen: Clang's code is far easier to use and more modern
11:27 AM Ameisen: it makes my head hurt somewhat less
11:28 AM Ameisen: Clang can also be built within IDE's like MSVC, and actually works with Intellisense... which makes doing some things so much easier
11:28 AM Ameisen: I hate using what is basically a simple text editor on something as large and complex as GCC.
11:28 AM Ameisen: which itself is an odd mix of C++ interfaces and macros
11:29 AM Ameisen: but yeah, an 'optimal shift' table would be great - it would save me a lot of time
11:29 AM Ameisen: otherwise, I have to derive one by looking at GCC's output
11:29 AM Ameisen: and that also implies that I trust GCC to always emit optimal shifts
11:29 AM Ameisen: since I'm also adding int48_t to clang, that's more difficult since GCC doesn't have that.
11:30 AM Ameisen: I figured, might as well have all the pow2 int types in AVR, there's no downside.
11:30 AM Ameisen: int8/16/24/32/48/64
11:30 AM Ameisen: pow2/factors-of-pow2
11:30 AM Emil: nice
11:31 AM Ameisen: one better thing (since I still have that outstanding GCC bug for C++) - LLVM doesn't generate different IL for c++ than for c
11:31 AM Ameisen: GCC does
11:31 AM Ameisen: thus g++ currently emits very, very unoptimized code for uint8_t shifts
11:31 AM Ameisen: clang currently emits optimal code.
11:31 AM Ameisen: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82658
11:32 AM Ameisen: I submitted that bug
11:36 AM Emil: What the fuck :D
11:36 AM Emil: That's a really strange issue
11:49 AM Ameisen: Well, preliminary investigation is already done
11:49 AM Ameisen: the C++ frontend is altering the interpreted instruction sequence, which prevents lowering
11:49 AM Ameisen: However, it's made me very wary of continuing my AVR code that relies heavily on shifting if it's generating code that bad
11:50 AM Ameisen: which is also one of the reasons I'm doing Clang work
11:50 AM Ameisen: two toolchains = more flexibility
11:50 AM Ameisen: I also want to add __flash to C++, and the g++ maintainers won't allow it.
11:50 AM Ameisen: whereas Clang actually already has address space support in C++
11:50 AM Ameisen: and C
11:51 AM Ameisen: the interfaces are equivalent - they don't have specialized nodes for C and C++ like GCC does
11:51 AM Ameisen: which simplifies things
11:52 AM Ameisen: I was talking with another Clang person about __zero_reg__ though
11:52 AM Ameisen: at some level, __zero_reg__ needs to be supported to match how GCC does things, as there's inline assembly out there presuming it exists
11:52 AM Ameisen: IMO, it should be a flag
11:52 AM Ameisen: -fno-zero-reg
11:52 AM Ameisen: I haven't seen __zero_reg__ improve codegen particularly, and it wastes a register
11:58 AM Ameisen: Do you know of an 'ideal shift instruction' table though?
11:58 AM Ameisen: I'm seriously looking for one
11:58 AM Ameisen: I don't want to have to derive them all manually. Tedious.
12:13 PM Emil: Hm?
12:13 PM Emil: Shouldn't generating one be pretty easy?
12:16 PM polprog: Ameisen: isn't that the stuff compilers normally do?
12:17 PM polprog: somebody has to program it eventually :P
12:17 PM Ameisen: polprog - kinda
12:18 PM Ameisen: compilers perform reduction
12:18 PM Ameisen: however, oftentimes you have to define what 'reduction' means for an arch for certain things
12:18 PM Ameisen: otherwise it will presume the best usual case, which on AVR certainly isn't correct
12:18 PM Ameisen: most architectures have fast barrel shifters. I don't think AVR even has a barrel shifter.
12:19 PM Ameisen: So you have to write custom reducing routines for shifts
12:19 PM Ameisen: otherwise it will literally emit something like lsr lsr lsr lsr lsr lsr lsr lsr lsr
12:19 PM Ameisen: well, stick a ror in there
12:23 PM polprog: interesting
12:23 PM polprog: i dont know much about compilers
12:24 PM polprog: how would such a table look like?
12:26 PM Ameisen: I mean, it would literally just be a text file
12:26 PM polprog: i guess
12:26 PM Ameisen: "uint8_t shift left 1: _instructions_ ..."
12:26 PM Ameisen: and so on
12:27 PM polprog: aha, so just writing out subroutines for shifting
12:27 PM Ameisen: yeah
12:27 PM Ameisen: Otherwise I have to derive them manually or by looking at GCC's output
12:27 PM Ameisen: which is tedious and potentially wrong
12:28 PM polprog: how else than by repeating LSR/RSR you'd accomplish a shift?
12:38 PM Ameisen: depends on the shift size
12:38 PM Ameisen: Here's a table that I created (not sure if it's ideal) of 'good' shifts (just use the 'other' instruction to shift the other way):
12:38 PM Ameisen: https://pastebin.com/VGxuVGGB
12:38 PM Ameisen: I can tell you with certainty that my uint16 shifts there are not all ideal
12:39 PM Ameisen: gcc outputs some that are one instruction better, using xor magic
12:39 PM polprog: hmm
12:39 PM polprog: R4
12:39 PM Ameisen: SWAP is a nibble swap
12:39 PM polprog: im trying to crack it
12:39 PM polprog: yeah i knwo
12:39 PM Ameisen: 0bAAAABBBB becomes 0bBBBBAAAA
12:39 PM polprog: ah
12:39 PM Ameisen: also, by the way, binary literals in C++ are one of favorite features
12:39 PM Ameisen: :D
12:39 PM polprog: that's a right shift duh
12:40 PM Ameisen: well, left shift 4 is basically the same
12:40 PM polprog: yeah
12:40 PM Ameisen: SWAP a; ANDI a, 0b11110000 instead
12:40 PM Ameisen: the trick is to reduce (thus why copmilers call it instruction reduction) the cost by reducing it to simpler operations which can do equivalent behavior
12:41 PM Ameisen: the problem is that the compiler, built-in, can only reduce to logic it already knows
12:41 PM Ameisen: like multiplying by 2 is == shift left by
12:41 PM Ameisen: 1
12:41 PM polprog: r4 for 16-bit, make sure the register is not used
12:41 PM Ameisen: It doesn't understand architecture specific things like ROR
12:41 PM Ameisen: or that shifts are expensive
12:41 PM Ameisen: thus you have to override the reduction logic
12:41 PM Ameisen: yes
12:41 PM Ameisen: usually you specify to the compiler that you require a new register for it
12:41 PM Ameisen: on GCC, at least
12:42 PM Ameisen: on Clang, you mark it as a new value node
12:42 PM Ameisen: you can do it without the temp register if you're willing to be a little less efficient
12:42 PM polprog: brb
12:43 PM Ameisen: Also, things like doing the work on a uint32_t will have different code depending on if you're using register pairs or not
12:43 PM Ameisen: since if you aren't, you can't use word-instructions like movw
12:47 PM polprog: so you are trying to port clang for avrs? or improve an existing port?
01:00 PM Ameisen: improving it
01:01 PM Ameisen: it's new on clang, still experimental
01:01 PM Ameisen: I'd like to have an alternative to gcc
01:06 PM polprog: nice
01:07 PM Ameisen: just not suitable yet
01:07 PM Ameisen: codegen is pretty bad
01:07 PM Ameisen: getting better as I add more optimizations
01:31 PM atk is now known as oop
01:32 PM oop is now known as atk
01:51 PM Emil: cehteh: you know what I've come to realise
01:52 PM Emil: This optocoupler solution becomes way too complex
01:52 PM Emil: unnecessarily
01:52 PM Emil: If I just do it with a resistor and an opamp it's linear and works
01:52 PM Emil: :D
01:56 PM cehteh: mhm?
01:57 PM cehteh: whats so much more complex?
01:57 PM Emil: Linearity
01:57 PM cehteh: and you get isolation
01:57 PM Emil: and calibration
01:57 PM Emil: and component selection
01:57 PM cehteh: it is pretty linear
01:57 PM cehteh: and you need calibration anyway
01:57 PM Emil: If the impedance is like 10MOhm I'm okay with that isolation :D
01:58 PM cehteh: dunno .. 10Mohm also sound like its a noise-trap
01:59 PM Emil: Or even just 1Mohm
02:00 PM cehteh: cap PS is current source, which should be quite linear on the opamp
02:00 PM cehteh: well do whatever you want
02:00 PM cehteh: i'd have more confidence in my solution, just because its insulated for sure
02:01 PM Emil: it's not about the linearity of th cap ps
02:01 PM Emil: that's fine
02:01 PM Emil: the issue is the opto
02:02 PM cehteh: you dont need much linearity anyway, you have only 3 states (off, 110v, 230v) ... and/or maybe you want to measure the freq
02:02 PM cehteh: if i recall correctly many optos are (or have a linear range) as well
02:03 PM cehteh: for just this 3 states it should be pretty simple anyway
02:03 PM cehteh: but whateve
06:24 PM robinak is now known as robink
09:01 PM enh: good night