#avr Logs
Mar 23 2018
#avr Calendar
12:14 AM day__ is now known as day
02:39 AM chat is now known as Guest78574
02:49 AM Haohmaru: is a serial bootloader doable on a stm32?
02:53 AM _ami_: Haohmaru, it has a very tiny bootloader
02:53 AM _ami_: for flashing via serial port.
02:57 AM polprog: LeoNerd: whats the black box on the old pic? https://twitter.com/cpan_pevans/status/976586717150007296?s=19
03:00 AM Haohmaru: _ami_ in my current devices which are using xmegas, i was looking forward to adding a bootloader that works via synchronous USART (in master mode) that talks to our custom high-level protocol, where it would just have a few commands, thus 512bytes of flash pages will be wrapped in "packets"
03:02 AM Haohmaru: the bootloader would just have to initialize the synchronous USART, have a decent FIFO on it, and receive those packets, then get the 512 bytes of data and stuff it in a flash page
03:02 AM Haohmaru: will this be possible with stm32?
03:03 AM _ami_: Haohmaru, yes, there is a DFU bootloader on stm32 so why not a serial bootloader.
03:03 AM Haohmaru: also, this requires being able to reset the mcu via software (so that the existing firmware can reset and indicate to the bootloader that it has to stay and wait for firmware update)
03:03 AM _ami_: Yup. doable.
03:03 AM Haohmaru: okay, good
03:07 AM _ami_: Haohmaru, check usb_dfu example in libopencm3 examples repository.
03:08 AM l9_ is now known as l8
03:08 AM l8 is now known as l0
03:08 AM l0 is now known as l9
03:09 AM _ami_: bootloader address in flash is from 0x80000000 to 0x8002000
03:09 AM _ami_: and app address starts from 0x8002000
03:09 AM Haohmaru: ugh
03:10 AM _ami_: you would need to copy Vector table base address before jumping to App address.
03:11 AM Haohmaru: 8192K bootloader size?
03:11 AM Haohmaru: ehm, i meant 8K
03:17 AM _ami_: yes, 8K. but i think it would depend upon your bootloader size.
03:17 AM _ami_: if you manage to write smaller bootloader in size, you could have lesser bootloader size. 2k or 4k
03:18 AM _ami_: you can have two application address. the bootloader here is just an application which happens to write to other part flash.
03:21 AM _ami_: i did write eeprom emulation in stm32 using flash. i was storing after 64k address of stm32 (hidden/undocument feature of actual flash size to be 128kb ;))
03:27 AM _ami_: also you need point MSP to your app address before the jump.
03:28 AM _ami_: so just two things before jumping to different application address.
03:28 AM _ami_: Vector table and MSP
03:28 AM _ami_: and jmp to APP_ADDR + 4
03:39 AM polprog: quick question
03:40 AM polprog: couldnt you put the actual flash writing part in 0x8000000 and the rest somewhere else?
03:41 AM polprog: [09:18] <_ami_> i did write eeprom emulation in stm32 using flash. i was storing after 64k address of stm32 (hidden/undocument feature of actual flash size to be 128kb ;))
03:41 AM polprog: interesting ^^ :)
03:42 AM _ami_: because flash address starts from 0x08000000
03:42 AM _ami_: so at startup, it would look up for app at this address.
03:44 AM polprog: what do you mean "because"
03:45 AM _ami_: oh.. i misunderstood.
03:45 AM _ami_: yes, bootloader starts from 0x080...
03:46 AM _ami_: and the app is from 0x080... + Offset (2k, 4k, 8k) depending upon bootloader size.
03:46 AM _ami_: for this eeprom emulation case, i was writing to 0x080... + 64k
03:46 AM _ami_: obviously.
03:47 AM polprog: so 0x80.. +64k is the advertised end of the memory?
03:47 AM _ami_: yes
03:47 AM polprog: okay
03:47 AM polprog: hmm.. need to try this at home ;)
03:48 AM _ami_: most of the time, u don't need a bootloader.
03:48 AM _ami_: generally app address is set to 0x08000000
03:49 AM _ami_: you give this address to flash tool while flashing
03:49 AM polprog: oh, yes, i remember
03:49 AM _ami_: st-flash write skeleton.bin 0x08000000 -> in case of st link programmer
03:50 AM polprog: i need to refresh my makefile
03:50 AM polprog: take a look at it, dont remember much
03:50 AM polprog: gtg
04:18 AM LeoNerd: polprog: GPIO box. 8 buffered LED monitors + 8 buffered & debounced button outputs
04:18 AM _ami_: LeoNerd, prety neat!
04:19 AM polprog: awesome!
04:19 AM LeoNerd: I need to make a better one sometime, with configurable invert, pulse-stretching, etc
04:42 AM _ami_: polprog, i just checked my eeprom code, my base address was 120kb :)
04:43 AM polprog: ok
04:43 AM _ami_: polprog, http://www.enlightenment.org/ss/e-5ab4cbef0aae39.04332608.png
04:44 AM polprog: visual wow
04:44 AM polprog: im thinking about replacing my cb with it
04:44 AM polprog: maybe it will crash less. and its generally a nice ide
04:44 AM polprog: with git integration and all that jazz
04:44 AM polprog: basically i need ide now to develop gtk gui
04:45 AM polprog: as i usually use emacs for avr
04:45 AM polprog: or ill just write myself a gtk makefile and cut out all that bs
04:45 AM _ami_: i moved to vscode from vim and i am happy with my productivity :D
04:46 AM _ami_: polprog, for making ui by dragging/droping widgets?
04:47 AM _ami_: like Qt editor?
04:47 AM polprog: nah
04:47 AM polprog: ill just use a plain makefile
04:48 AM _ami_: ok
04:49 AM _ami_: time to go home
04:49 AM _ami_: happpy weekend guys!
06:27 AM Haohmaru: polprog C::B crashes on you often? on linux?
06:28 AM polprog: unfortunately
06:28 AM Haohmaru: disable the symbols browser
06:28 AM Haohmaru: C::B v16, right?
06:40 AM Haohmaru: polprog settings > editor > Code completion > Symbols browser > "Disable symbols browser"
06:40 AM Haohmaru: then close C::B (so it save the settings to disk)
06:48 AM polprog: hmm.ill give it a shot
07:07 AM Haohmaru: this Makefile4CubeMX thing assumes i'm running linux
07:38 AM polprog: apply corrections to your workflow
07:38 AM polprog: i recommend debian or arch ;-)
07:38 AM polprog: also
07:38 AM polprog: disabling symbol browser wont kill autocompletion, right?
07:40 AM Haohmaru: nope
07:41 AM polprog: goid
07:41 AM polprog: good*
07:41 AM Haohmaru: i don't want to install this cubeMX program on the debian
07:42 AM Haohmaru: besides that, i use the debian for kicad/cad stuff
07:48 AM Haohmaru: i almost compiled the makefile under debian
07:48 AM Haohmaru: *almost*
08:15 AM polprog: https://puu.sh/zNQSF/210c159ec3.png
08:15 AM polprog: having fun at programming at scho
08:15 AM polprog: ool
08:16 AM polprog: whats wrong with this keyboard
08:17 AM skz81: <Haohmaru> i don't want to install this cubeMX program on the debian >> cygwin, then ?
08:18 AM Haohmaru: does that mean i have to install the arm-gcc into cygwin too?
08:19 AM Haohmaru: i am currently trying to set up a Code::Blocks to just build the code using its built-in build system
08:19 AM Haohmaru: and i have *some* progress, it builds .o files so far, now i'm up to the linker errors ;P~
08:20 AM Haohmaru: i'm stealing compiler arguments from the makefile ;P~
08:20 AM * Haohmaru such a theaf
08:22 AM polprog: lol
08:24 AM Haohmaru: that would be good for me cuz then i can just add more .cpp files to the project without dealing with dark makefile voodoo magic
08:35 AM Haohmaru: do i need to have this: -Wl,-Map=$(BUILD_DIR)/$(TARGET).map,--cref ?
08:46 AM Haohmaru: Output file is test2.sys with size 66.20 KB
08:46 AM Haohmaru: wowz
09:26 AM Haohmaru: Output file is test2.sys with size 156.45 KB Process terminated with status 0 (0 minute(s), 7 second(s)) 0 error(s), 0 warning(s) (0 minute(s), 7 second(s))
09:26 AM Haohmaru: \o/
09:46 AM polprog: \o/
09:46 AM Emil: Haohmaru: I have a very simple makefile
09:46 AM Haohmaru: i think this was easier than getting the espressif extensa crap
09:47 AM Haohmaru: ..working
09:47 AM Emil: It just includes all files :D
09:47 AM Haohmaru: Emil i have four makefiles for this same chunk of code, and none of them works
09:48 AM polprog: Emil: g++ *.cpp :p
09:49 AM Emil: polprog: emil.fi/d/makefile
09:49 AM Emil: https://emil.fi/d/makefile
09:50 AM Emil: just have src and obj directories and the makefile automatically includes everything for oyu
09:50 AM polprog: nice one
09:51 AM polprog: OBJS = $(CFILES:%.c=%.o)
09:51 AM polprog: this was a breakthrough to my makefiles
09:52 AM Emil: so it takes all the c files and changes the extension to .o?
09:52 AM polprog: mm
10:18 AM Emil: https://emil.fi/d/2018-03-23_17-16-44_ZSqdAeWu.png
10:18 AM Emil: Daily reminder that most frameworks in C look and feel horrible :D
10:21 AM polprog: im looking at a terminal
10:21 AM polprog: akchually
10:21 AM polprog: im doing gtk last two days
10:24 AM aczid: have you heard the gospel of our lord and nigga GObject?
10:27 AM Emil: the translation of that picture on my part is:
10:27 AM Emil: ohfuckingnice
10:27 AM Emil: ewwwfuckthat
10:27 AM Emil: The meaning is quite specific and very hard to express in very few English words
10:28 AM polprog: magnificient language indeed
10:32 AM Emil: I wholeheartedly agree
10:33 AM skz81: <Haohmaru> does that mean i have to install the arm-gcc into cygwin too? >> sorry was away. Should not, cygwin is able to launch any windows executable.
10:38 AM Haohmaru: but the dumb makefile was trying to call /usr/bin/...gcc
10:39 AM Haohmaru: doesn't matter, i don't need the makefile now
10:39 AM skz81: ok
10:39 AM Haohmaru: C::B saved my day again
10:40 AM skz81: Emil >> why $(OBJDIR)/%.o: $(SRCDIR)/%.c (just after the "all" rule)? Can't you just $(OBJ) : $(SRC) ?
10:41 AM Haohmaru: what kind of a person uses "char*" argument to pass strings like __FILE__ >:/
10:41 AM Emil: skz81: I dunno
10:41 AM Emil: skz81: it's mostly copied from somewhere else
10:41 AM Emil: skz81: I should test if it works like you said
10:41 AM Haohmaru: Emil u theif!
10:42 AM Emil: Haohmaru: you think I could come up with everything myself? :D
10:42 AM Emil: I'm not _that_ good
10:43 AM skz81: OK. It SHOULD work, (the next rule uses $(OBJ) as dependencies...) and reads a bit simplier.
10:43 AM Emil: but thank you for the trust :3
10:43 AM Emil: skz81: nowait
10:43 AM Emil: skz81: hmm
10:43 AM skz81: Haohmaru, that a new game : "Grand Thief OSS"
10:43 AM Emil: I think it might be because those files don't exist yet
10:44 AM Emil: no
10:44 AM Emil: I dunno
10:44 AM Emil: I should try
10:44 AM skz81: Emil : those two variable are evaluated/expended first
10:44 AM Emil: oh heh
10:44 AM Emil: I was looking at this unrelated twitter post
10:44 AM Emil: https://twitter.com/dylanmckaynz/status/976369275324678145
10:45 AM Emil: noticed the guy is LLVM AVR backend maintainer :D
10:45 AM Emil: >code owner what
10:49 AM skz81: ruby and avr-llvm ? o_O http://www.lefigaro.fr/medias/2013/11/15/PHO411b8414-4e14-11e3-bd02-e4d15a3d1322-640x230.jpg
10:54 AM Emil: haha :D
11:56 AM nohitzzz2: congrats antto
12:08 PM Emil: what did antto get
12:08 PM Emil: or do
12:09 PM Emil: https://emil.fi/d/2018-03-23_19-06-20_hsHRWsCk.png also check dat gun
12:09 PM Emil: a motafukin charging handle on a pistol :D
12:26 PM polprog: http://paste.debian.net/1016293/
12:26 PM polprog: im having problems with threads and gtk
01:01 PM unclenorton: is it possible to use USI without timer0?
01:05 PM antto: Emil i managed to build the cubemx generated code with my IDE's build system
01:06 PM antto: cuz i couldn't make the dumb makefiles work
01:11 PM polprog: damn. its working
01:12 PM unclenorton: i'll try to ask again, is it possible to use USI without timer0?
01:16 PM polprog: yes
01:16 PM polprog: those two are not connected iirc
01:16 PM polprog: which chip?
01:17 PM polprog: ping unclenorton
01:18 PM unclenorton: attiny85
01:19 PM unclenorton: i've seen multiple examples use timer0 and USI_OVF_vect
01:26 PM polprog: usi_ovf is usi overflow
01:26 PM unclenorton: does anyone have USI examples that don't use timers or interrupts?
01:27 PM unclenorton: polprog, yes, that gets called when the usi transmission is done i believe
01:28 PM polprog: theres a drawing on p105 in the datasheet, it has "tim0 comp" input. im trying to find out when its used
01:29 PM Ameisen: I'm tinkering with compiler codegen with various promises (if (!(c)) __builtin_unreachable();) and some algorithms
01:29 PM Ameisen: it's actually interesting seeing the compiler's output change, and how.
01:29 PM Ameisen: like a fucntion that iterates over a string and does things based on char values
01:30 PM Ameisen: it doesn't really optimize much knowing the length of the string. Not at all, really. Unless itknows it's not zero.
01:30 PM Ameisen: If it's not zero, it trims a few ops
01:30 PM Ameisen: though if it knows the length at compile-time, and knows its below a certain value, it will sometimes unroll the loop instead.
01:30 PM polprog: unclenorton: https://puu.sh/zO0pn/2e34edb9fd.png
01:31 PM polprog: see when usics[1:0] = 01
01:32 PM polprog: from what i understand its used when there is no master clock input (ie uart or the chip is the master)
01:38 PM Ameisen: since you guys are AVR folks... one second
01:38 PM Ameisen: https://pastebin.com/iL8TbvMJ
01:38 PM Ameisen: those are AVR results
01:38 PM Ameisen: the ARM results, and x86-64 results are different
01:39 PM polprog: well they are like two totally different architectures :^)
01:39 PM Ameisen: Yes, but the compiler makes radically different decisions sometimes
01:39 PM polprog: on the high or low level?
01:39 PM Ameisen: note that if you actually know additional constraints, like 'len' is always < 10
01:39 PM Ameisen: the compiler will do much better
01:40 PM Ameisen: high
01:40 PM Ameisen: before arch reduction
01:40 PM polprog: hnm
01:40 PM polprog: arch reduction is..?
01:40 PM polprog: :p
01:40 PM Ameisen: when they take their compiler IL from the middle end and generate architecture-specific code from it
01:40 PM Ameisen: by reducing operations through a set of rules and tables
01:41 PM Ameisen: it's one of the places that AVR code sucks in GCC, and is nonexistent in LLVm
01:41 PM polprog: ok. IL == instruction language? some kind of internal compimer language
01:41 PM polprog: ?
01:41 PM Ameisen: it's very difficult to reduce for an 8-bit CPU
01:41 PM Ameisen: IL = intermediate language.
01:41 PM Ameisen: frontend generates IL from the code. Optimizer works on IL. IL is passed to the backend which generates machine code via reduction
01:42 PM polprog: okay
01:42 PM Ameisen: both GCC and Clang work this way
01:42 PM Ameisen: though their IL and optimizers are different
01:42 PM Ameisen: MSVC et al do as well
01:42 PM Ameisen: Very few compilers DON'T work this way these days.
01:46 PM Ameisen: What I find interesting is that I use two different algorithms overall
01:46 PM Ameisen: I use the while *str++ != '\0' algo
01:46 PM Ameisen: and the size_t i = 0; str[i] != '\0'; ++i algo
01:46 PM Ameisen: and also provide constraints to the compiler that are sufficient to determine that both work
01:46 PM Ameisen: err
01:46 PM Ameisen: i < len, rather
01:46 PM Ameisen: not str[i] != '\0'
01:46 PM Ameisen: that is, it's informed that str[len] == '\-
01:47 PM Ameisen: str[len] == '\0';. all other values in it are != '\0'
01:47 PM Ameisen: and in the other case, that if you were to increment a value, that it would be 'len' at the end.
01:47 PM Ameisen: It still generates the code differently, meaning that their optimizer isn't smart enough to use that information fully, contextually
01:48 PM polprog: hmm
01:48 PM Ameisen: even though it's provable that both algorithms will function equivalently
01:50 PM polprog: i need to get back to the lab to test why my ckde works
01:50 PM polprog: code*
01:51 PM polprog: and make it a git rebpe
01:51 PM polprog: repo*
01:51 PM polprog: jesus this keyboard sucks
01:52 PM Ameisen: It's also not smart enough, given the information that, say, str[len+1...3] == 0, to generate integer-based operations on x86
01:52 PM Ameisen: which is disappointing
02:00 PM antto: heh, i learned something new today
02:00 PM antto: (void)tmp_var;
02:00 PM Ameisen: you can also use __attribute__ ((unused))
02:01 PM antto: isn't __attribute__ a gcc thang?
02:01 PM Ameisen: Most people are using GCC, so usually it's fine.
02:02 PM Ameisen: Clang supports it, keil's stuff does,unsure about IAR. Might use different syntax.
02:03 PM antto: i pretty much use gcc on every possible platform
02:03 PM Ameisen: I'm working on switching my ARM stuff to Clang
02:03 PM antto: so besides gcc, the only other compilers i've had to use are SDCC, XC8, and.. hm.. just those i think
02:03 PM Ameisen: Clang won't work for AVR as AVR support is at like 5% there
02:04 PM Ameisen: tohugh the GCC-AVR developers have already been rather public that they'd rather people support clang than gcc
02:04 PM antto: why clang?
02:04 PM Ameisen: because GCC and Clang are the two 'big' open copmilers.
02:04 PM Ameisen: compilers*
02:04 PM Ameisen: and are two of the only ones with near-feature parity
02:10 PM Emil: polprog: why not use c and sdl?
02:10 PM polprog: Emil: i want to be able to control it later (like have a left/right buttons)
02:10 PM Emil: polprog: or even have the frontend in javascript in browser and talk to it through websockets
02:10 PM polprog: bleh
02:10 PM Emil: polprog: sdl provides that
02:10 PM Emil: sdl2 is also the newer version
02:11 PM polprog: i know, but i wanted to try gtk. i did some sdl earlier
02:11 PM Emil: imho using c++ is just shooting yourself in the foor
02:12 PM Emil: the c thread api is super simple
02:12 PM polprog: i used posix threads before
02:12 PM polprog: in fact
02:12 PM polprog: its C++ but without classes and the like
02:12 PM polprog: i could change GThread to pthread just like that
02:12 PM polprog: and i think ill do that later
03:03 PM abcabc_: is debugwire supported by any open source host side tools?
03:09 PM polprog: avarice i think
03:13 PM Emil: really?
03:13 PM Emil: cool
03:13 PM Emil: also
03:13 PM Emil: debugwire is quite useless
03:23 PM aczid: yes, avarice
03:23 PM aczid: I've been able to debug stuff with it
03:24 PM aczid: only on a dragon though, because it needs all the secret dw stuff from atmel's blob
03:25 PM aczid: oh and I think it only worked well with the second-to-last version of atmel's update for the dragon
03:25 PM aczid: which you can only update through atmel-studio
03:26 PM aczid: fun times... not
03:33 PM * abcabc_ nods
03:33 PM aczid: I think the one that worked was the dragon update tied to atmel studio 5
03:36 PM aczid: so using the dragon with atmel studio 6 required a dragon reflash and then broke the avarice setup, so then you'd need to re-flash it in atmel studio 5 again
03:36 PM aczid: like I said. fun
03:36 PM abcabc_: what's the new pgm interface supported on? tiny104 iirc? one wire
03:37 PM aczid: idk
04:05 PM dehuman: speaking of atmel studio -- i looked the other day when i was uninstalling something
04:05 PM dehuman: like 4.5 gigs
04:05 PM dehuman: wtf!@#
04:05 PM dehuman: i dont really care i guess
04:29 PM polprog: jesus it finally works
04:29 PM polprog: i FORGOT TO ADD THE PARAMETER VARARGS
04:29 PM polprog: grrrrr
04:39 PM Tom_L: devil's in the details
04:41 PM mudkip908_ is now known as mudkip908
04:44 PM Ameisen: What's wrong with C++ threads?
04:44 PM Ameisen: std::thread and the like?
04:44 PM Ameisen: Not sure how you can really get simpler than it
04:45 PM Tom_L: dehuman, it's just a placeholder for when you run low on disk storage
04:51 PM polprog: Ameisen: i dont think there is something wrong with them
04:52 PM polprog: its just a 3rd type of thread id use :D
04:53 PM polprog: first ill have to get mutexes sorted, then think whether i leave gthreads or replace them with posix/cpp threads
04:53 PM polprog: and ill have to sort out drawing the graph as well
04:57 PM polprog: aczid: "secret"
04:57 PM polprog: iirc rue has a dw cheat sheet on his site
04:58 PM aczid: oh, well I did find a bunch of info... might be his. it's not exactly liberated codewise is what I meant
04:59 PM Tom_L: http://ruemohr.org/%7Eircjunk/
05:01 PM ac_slater: hey guys, anyone here care about avr32?
05:01 PM ac_slater: ie - avr32 uc3c
05:07 PM Emil: sure
05:07 PM Emil: but I bet not many of us have experience with it
05:08 PM ac_slater: Emil: I'd be interested in hearing if you have any qemu experience with it. I remember it (the family) being supported by qemu at some point, but now grepping for avr32 yields nothing in the qemu codebase. Super confusing
05:08 PM Ameisen: Trying to work out if I can use call signatures for fast vs slow uflib calls to optimize further. Like, if you call uflib::func(int, int, float, int)... and in one place you use the ::slow namespace one, in another, the ::fast... there's no reason not to just link them both to ::fast
05:08 PM Ameisen: since you are emitting code for both anyways
05:12 PM Emil: ac_slater: https://git.qemu.org/?p=qemu.git&a=search&h=master&st=commit&s=avr
05:12 PM Emil: tru checking here
05:12 PM ac_slater: interesting
05:12 PM Emil: https://github.com/turbosree/QEMU-AVR32/tree/master/target-avr32
05:12 PM Emil: Here's also what you are probably after
05:13 PM ac_slater: yea but I think that's abandoned. Most of the calls are stubs
05:14 PM Emil: Quite annoying to delete any traces of it
05:15 PM ac_slater: Emil: I just got a response from the OFTC qemu channel, apparently people have tried to make a qemu layer for avr32 but gave up
05:15 PM Emil: interesting
05:15 PM ac_slater: kind of makes sense since most avr32 chips are used with a very specific board setup, ie - has peripherals that are hard to emulate
05:15 PM Emil: eh
05:15 PM Emil: avrs are super simple to emulate imho
05:16 PM Emil: and since avr32 is a microcontroller
05:16 PM Emil: peripherals are really out of the scope of your standard qemu
05:16 PM ac_slater: Emil: I thought avr32 has an mmu
05:16 PM ac_slater: which makes it a lot more like an ARM and thus more complicated
05:16 PM Emil: ac_slater: they are still mcus, and I was mostly referring to the peripherals
05:16 PM ac_slater: but yea, still and mcu
05:17 PM ac_slater: I think a lot of people give up if they can only emulate/virtualize an mcu with no peripherals
05:17 PM Emil: UC3 doesn't have mmu
05:18 PM ac_slater: oh you're right
05:18 PM ac_slater: I'll look into creating a layer for it
05:25 PM ac_slater: Emil: http://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg02290.html
05:26 PM polprog: wait qemu actually emulating an 8 bit avr ?
05:27 PM polprog: holy crap
05:27 PM polprog: maybe finally a decent avr emul
05:27 PM polprog: qemu has pretty good gdb integration and radare supports it as a target
05:28 PM ac_slater: polprog: apparently the avr8 target in that mailing list hasnt been merged in since it's not properly tested
05:28 PM ac_slater: but probably works ok
05:29 PM polprog: its so far away from the typical qemu
05:29 PM polprog: after all qemu is a pc emulator
05:30 PM polprog: or rather... sonething that can run an OS... has a screen and a keyboard... at least a serial console
05:30 PM polprog: but avr doesnt even have that "by default"
05:31 PM polprog: that fork, without gdb is literally unusable since there is not a single io representation that makes sense
05:31 PM ac_slater: yea idk
05:31 PM polprog: im curious though
05:31 PM ac_slater: polprog: if you find anything useful report back please
05:31 PM polprog: after all stuff like simh is holding up
05:32 PM polprog: ill take a look at it this weekend :)
05:35 PM ac_slater: :D
05:41 PM polprog: ayy v r
05:44 PM nohitzzz2: interesting https://electronjs.org/
05:45 PM nohitzzz2: same kind of thing like cordova but for desktop
05:46 PM ac_slater: avoid tghat
05:46 PM ac_slater: that *
05:46 PM ac_slater: it's cancer
05:47 PM ac_slater: having a desktop app spawn a full instance of chromium just to make some http requests if plaguing the desktop software industry
05:47 PM ac_slater: but do what you want ;)
05:50 PM nohitzzz2: i said "interesting"
06:03 PM polprog: niters
06:13 PM Ameisen: I considered writing an AVR emulator
06:13 PM Ameisen: can't bring myself to do it
06:14 PM Ameisen: one of the issues would be how to handle things like GPIO and handling the timing of it
06:15 PM Ameisen: one of the reasons I wanted to write one though was automated algorithm performance analysis
06:15 PM Ameisen: could compile something, run it through the emulator, and it could tell you how many cycles it took