#avr Logs
May 11 2018
#avr Calendar
12:00 AM rue_mohr: tho I'm pretty sure there couldn't have been less headroom
12:08 AM day__ is now known as day
02:12 AM polprog: rue_mohr wise words
03:39 AM nux_ is now known as nuxil
04:03 AM erossi_ is now known as erossi
05:51 AM debby01: https://tinyurl.com/ya79dnx5
05:52 AM nuxil: :)
05:53 AM Haohmaru: is this a trap?
05:53 AM elektrinis: yes
05:53 AM nuxil: yes. to get your ip and browser :p
05:55 AM nuxil: so. im thinking about redoing my menu code. atm its just awefull.
05:56 AM nuxil: 300 lines of code in a switch block. and its all static menus, what would be the best way to create a dynamic menu system.
05:56 AM nuxil: dynamic as in updates menus as needed.
05:57 AM nuxil: or is there a existing lib i can use.
05:58 AM Haohmaru: dynamic?
05:59 AM nuxil: yes.. as in change the values/text on the screen in a "update" function so to speak.
05:59 AM Haohmaru: i have this dumb display+buttons device which is meant to connect to another device (via UART), and that other devices dumps menu structure stuff.. then this thing deals with displaying the menu, buttons, and navigation
05:59 AM nuxil: i dont want your code. its c++ :p
06:00 AM nuxil: i dont want to infest my avr with that stuff :p
06:00 AM nuxil: just kidding :D
06:00 AM Haohmaru: some of the menu items are "dead ends", and this thing sends an "event" to the other device when it reaches a dead end like that
06:00 AM Haohmaru: who said C++
06:00 AM nuxil: i been googeling a bit
06:00 AM Haohmaru: i did this crap on a pic18f45k80
06:00 AM nuxil: most of the stuff i find is arduino
06:00 AM Haohmaru: with SDCC
06:01 AM Haohmaru: the menu is transmitted on "connect" and kept in RAM
06:05 AM Haohmaru: the dumb thing even remembers the menu item you had focused when you press BACK
06:07 AM Haohmaru: it has mechanisms to take user input (using a valid character map) and then return the result, and also request a password , hash it, and send the hash
06:07 AM Haohmaru: i barely fitted it in that dumb pic
06:07 AM nuxil: hehe.
06:08 AM Haohmaru: sadly, the menu can't be too big cuz the pic has less than 4K ram total
06:08 AM Haohmaru: and that's the "biggest" of the pics
06:09 AM Haohmaru: i also had to modify the linker script in order to have an array bigger than 256 bytes, dafuq!
06:10 AM Haohmaru: nuxil so what's your current problem with your menu that you want to solve?
06:12 AM nuxil: http://8020.photos.jpgmag.com/2329350_248726_4b4c697b45_p.jpg
06:12 AM nuxil: that is wrong :p
06:14 AM nuxil: i just want a more elegant way of creating my menus instead of using switches and tonz of cases.
06:15 AM nuxil: thinkng about using more function and function pointers.
06:16 AM nuxil: gonna go try out some ideas.
06:21 AM polprog: function ptrs ftw
06:23 AM polprog: you can just keep a menu as a struct of menu entry structs and each menu entry is a bool and a void*, the bool tells if the void* is for another menu struct or its a function pointer
06:24 AM Haohmaru: uhm, weird
06:24 AM Haohmaru: what about sub menus?
06:24 AM Haohmaru: and who's gonna print the menu names on teh screen
06:27 AM Haohmaru: i would separate things, make a menu parser thing that deals with the navigation in the menu structure, printing stuff to the display, scrolling, etc, and this would just output a few values (menu item index) to the outside, where you'll actually do anything specific if ya see a specific index
06:29 AM Emil: https://blog.innerht.ml/google-yolo/
07:47 AM polprog: programming assignment done
07:47 AM polprog: quake time
07:47 AM polprog: rest of the class is playing CS1.6
07:50 AM Haohmaru: they win
07:50 AM Haohmaru: ++rest_of_the_class;
07:50 AM Haohmaru: --polprog;
07:51 AM polprog: movl $0, Haohmaru
07:52 AM * Haohmaru iz akchually a constant
07:53 AM polprog: what's a constant to a mov
07:54 AM polprog: fuck yo memry
07:56 AM * Haohmaru is akchually a read-only register
07:56 AM Haohmaru: naa naa nanaaa naa
08:00 AM * polprog loads Haohmaru immediate
08:01 AM * Haohmaru farts
08:01 AM Haohmaru: ooh, do that again
08:02 AM polprog: volatile asm("leave"::); ;_;
12:05 PM aarcane: https://pastebin.ca/4024952 oiy, This is odd.. I'm running this command and getting this error that google can't seem to find. Notice the resp= is increasing. I'm flashing to a chip burnt with optiboot. I can verify that the LED is flashign to indicate bootloader. I can verify that the bitrate is correct. I can verify that the μC clock speed is correct. I can verify that avrdude works fine from windows, but running this from my rpi running yocto
12:05 PM aarcane: linux... I get this error output.
12:06 PM aarcane: Oh, and the chip is communicating over a USB to serial adapter, which again works fine in windows but Björks fairly badly from Linux.
12:11 PM antto: aarcane do you have access to /dev/ttyUSB0 ?
12:11 PM aarcane: antto, yup. I've stopped the process that normally communicates with it, and I'm running as root even
12:12 PM antto: this generally ain't a good idea ;P~
12:13 PM aarcane: antto, it's an embedded device on a read-only filesystem on a closed network which will have a whole new OS flashed to it in a day or so... I'm not super worried about using root for now ;)
12:14 PM antto: yeah, but when running certain innocent programs as root you can still break some stuff in interesting ways
12:14 PM antto: just sayin'
12:14 PM antto: no idea what the issue is then
12:15 PM aarcane: running it as a regular user, I get the exact same issue.
12:15 PM aarcane: regular user definitely has access to the COM port
12:15 PM antto: k
12:17 PM aarcane: haha, Trebeck! I figured out what the error codes are
12:18 PM aarcane: they're when avrdude/boot loader quit trying to talk to each other, and my firmware starts booting again
12:40 PM aarcane: ...that doesn't tell me why the bootloader isn't responding to linux but it is to windows...
12:41 PM MrFahrenheit: first strawberries https://www.dropbox.com/s/sql0tfdoqamqqak/2018-05-11%2012.08.59.jpg?dl=0
01:02 PM Ameisen: It's funny running Windows 3.11 in dosbox
01:02 PM nn7: I'm looking for wireless communication between two AVRs. Low data rate, short distance. Reliability is my main interest. I played with RFM12 and was disappointed. I have played with an XBee series 1 and it worked pretty well.
01:02 PM * Ameisen watches avr-libx build
01:02 PM Ameisen: libc*
01:14 PM Emil: nn7: how much money
01:15 PM nn7: Emil, not a major concern
01:15 PM Emil: nn7: then bluetooth is pretty good
01:16 PM nn7: I do not have much faith in Bluetooth. :(
01:16 PM Emil: or rfm95
01:16 PM Emil: wel
01:16 PM skz81: hello people ! I'm writing an i²c slave... I can't figure out how it should behave when master send "crap"... Let me explain... Imagine after the START and adress (write mode), the master sends a command number. For some command, arguments are needed...
01:16 PM Emil: if low range is <10m then nrf24l01+ is a possibility
01:17 PM skz81: What should the slave do if the master starts reading but didn't send all the argument data ?
01:17 PM Emil: skz81: timeout
01:17 PM Emil: or just wait
01:17 PM skz81: reply nothing you mean ?
01:17 PM Emil: yes
01:18 PM Emil: if master does not respect protocol the correct way is not to send crap yourself
01:18 PM Emil: just dont reply
01:18 PM skz81: ok, thanks. I was searching for a way to say "invalid command", but found nothing...
01:19 PM skz81: Simplifies my state machine also, just go back in WAITING state, that's all !! Neat :]
01:20 PM LeoNerd: While the UART has control of the TX/RX pins, am I still able to read the state of the RX pin using the PINx register?
01:20 PM LeoNerd: What about triggering PCINT?
01:24 PM skz81: LeoNerd, I bet yes to both. Lemme check the DS for you :]
01:26 PM LeoNerd: Trying to make a robust DMX512 receiver, so I need to detect the time at which the line is in mark state after break
01:26 PM LeoNerd: (because this thing is still buggy as all hell right now :(
01:29 PM antto: i think my evil plan will work.. slapped a structure in the beginning of data RAM, moved the .data section up to make room for the struct, and this struct is never cleared, nor even on software reset
01:31 PM nuxil: u h4xor,
01:31 PM antto: all without touching the linker script
01:32 PM nuxil: black magic
01:33 PM antto: the bootloader will have ways to "detect" whether the firmware "works" or is completely f*cked up
01:38 PM skz81: LeoNerd, I'm not totally sure but given what I read in chapter 13 (ext interrupts), particularly in §13.4 (alternate port function), I don't see any mention you can't do that
01:39 PM skz81: LeoNerd, btw, the DS for atmega48 => 328)
01:39 PM * LeoNerd nod
01:39 PM LeoNerd: Oh.. well my particular chip is the 'tiny841, but hopefully similar
01:39 PM LeoNerd: I'll try it out and see
01:40 PM LeoNerd: If not, I'll just have to be a /bit/ more cunning with dis/enabling the UART all the time
01:43 PM Emil: LeoNerd: pinx is wholly separate from all logic
01:43 PM Emil: LeoNerd: so yeah of course you can use it to read pin state
01:44 PM Emil: skz81: but here
01:44 PM Emil: 's the thing though
01:44 PM Emil: skz81: if your slave does not work without master sending correct data
01:44 PM Emil: then the application developr will fix his code
01:45 PM Emil: so instead of timeout I recommend just waiting for the data
01:46 PM Emil: LeoNerd: and your PCINT is highly likely triggered on all changes on the pin
01:46 PM Emil: even if it's your peripheral that's doing the change
01:48 PM skz81: Emil, yeah, that's the way I'm going. I don't even know what yopu mean by "timeout" actually. But the current thing i'm doing is : if requested data but state != READY, then state = WAITING. So it will wait for a new (and complete) cycle of writes, nothing more
01:50 PM skz81: (NB : even if pretty clear, I precise : WAITING : the slaves waits for command / argument writtent by master, READY is when the master has written all expected data, noo more, no less)
01:51 PM skz81: And BTW, I will also write the master code, but I try to do it as clean as possible ;°)
02:07 PM Ameisen: hrmm
02:07 PM Ameisen: after recalibrating settings
02:07 PM Ameisen: 7.3: 245056
02:07 PM Ameisen: 8.1e: 238822
02:08 PM Ameisen: there are still some things that don't make sense
02:08 PM Ameisen: splitting data type sshould make AVR code better. It makes it worse.
02:08 PM Ameisen: without splitting, it requires GCC to, say, put a uint32 in 4 sequential registers
02:08 PM Ameisen: which shouldn't benefit it at all
02:09 PM Emil: skz81: skz81 you could also have an unconditional "reset device", say address + byte with value 0
02:11 PM Ameisen: annoyance with flto with avr-libc is you have to change how you include libc
02:11 PM Ameisen: with -flto, it doesn't find all the dependencies if you don't use --whole-archive. Which is fine since you should be using gc-sections anyways
02:13 PM Ameisen: I will need to do some digging to find the other regressions in GCC though
02:13 PM Ameisen: every version adds new ones for AVR
02:13 PM Ameisen: \o/
02:13 PM Ameisen: heck, they add new ones for ARM Cortex M as well
02:16 PM antto: wut? what are these numbers Ameisen?
02:17 PM Ameisen: program memory size
02:17 PM Ameisen: of the linked firmware
02:18 PM antto: you're building with -Os or -O2/3 ?
02:20 PM skz81: Emil, unsure an unconditionnal reset will help ! It is more for debugging purpose, if I spy the i²c bus, it would have helped to have a clear "error return" from the slave. But no answer at all is good enough. The protocol is not very complex anyway. It's a weight scale that is i²c...
02:21 PM skz81: so commands are pretty simple, like on, off, tare (no args), set_calibration... And gets : read_value, get_zero_offset...
02:23 PM skz81: (but a 82x82cm scale I built :p)
02:25 PM skz81: https://drive.google.com/open?id=1kybRHKpPHwTeNoFFjYVEC_wjEoIacIhj
02:26 PM Ameisen: antto - -O3 and a bunch of other flags
02:26 PM Ameisen: I need to write a few scripts to test the flags for size and speed
02:26 PM Ameisen: to determine the optimal flags for AVR for -Os, O1, O2, and O3
02:26 PM Ameisen: for speed, I need to figure out some kind of reliable benchmark to execute
02:27 PM Ameisen: which incorporates everything that would be reasonable, including function calls and such
02:27 PM Ameisen: ideally it's pretty large as well
02:27 PM Ameisen: to discourage simply flattening the entire program
02:33 PM skz81: So, nearly 21h here, i'll leave it for today. Now it's on rails, then should be straghtforward tommorow. Thanks Emil !! Good evening (or whatever) everybody !
02:34 PM Emil: skz81: good night
02:35 PM Ameisen: I'm actually investigating that right now
02:35 PM Ameisen: but am unsure _why_ so far
02:35 PM Ameisen: the idea behind fsplit-wide-types is that, as said, a 'wide' type would be allocated sparsely
02:35 PM Ameisen: which makes sense on something like AVR where there isn't really any register coherency
02:35 PM Ameisen: but the codegen is worse.
02:35 PM Ameisen: it bloats the size quite a bit
02:35 PM Ameisen: that doesn't make _any_ sense to me
02:36 PM Ameisen: if anything, it should reduce register pressure, and let functions be _smaller_
02:41 PM Ameisen: hmm
02:41 PM Ameisen: looks like since 'int' is the default word in AVR (16-bit), it will only split things into 2-byte segments
02:41 PM Ameisen: which makes senas and it doesn't
02:42 PM Ameisen: ideally it would only do that for things that will be used as pointers
02:42 PM Ameisen: I don't think GCC is sophisticated enough to split that logic, as GCC generally presumes that sizeof(void *) == sizeof(word)
02:42 PM Ameisen: which is why GCC has a lot of issues with small types in AVR
02:43 PM andre_ is now known as Guest54177
02:43 PM Guest54177 is now known as AndrevS
02:44 PM Ameisen: I have seen it suggested that the proper way to get a compiler functioning well for AVR and other 8-bit ISAs is to actually write a whole new middle/backend from scratch for it
02:44 PM Ameisen: and just use the LLVM or GCC frontend for C and C++ for it
02:45 PM Ameisen: since 95% of the optimizations that GCC and LLVM do is not really relevant for AVR, and they make a ton of presumptions that are very much wrong
02:48 PM AndrevS: There is sdcc, afaik no avr support, but there is support for a bunch of 8 bit mcus
02:49 PM Ameisen: yeah
02:49 PM Ameisen: I don't think writing a sane backend would be _terribly_ hard
02:49 PM Ameisen: the frontend is usually what is very hard
02:50 PM Ameisen: and that's already done
02:50 PM Ameisen: can rip LLVM'
02:50 PM Ameisen: LLVM's or GCC's
02:50 PM Ameisen: LLVM's is easier to work with since it was actually designed to be split off
02:50 PM Ameisen: take the parsed language code which is emitted as a simplified logical bytecode, and use that to generate instruction graphs for 8-bit
02:50 PM Ameisen: then utilize optimization passes that are geared explicitly for it
02:51 PM Ameisen: that's where GCC and LLVM really fail - they are very much based around the principle that a register is at least the size of a pointer.
02:51 PM Ameisen: That, and they don't default to mint8 (for a variety of reasons), and thus generate 2-register code by default
02:51 PM Ameisen: so register allocation for AVR sort of... makes no sense
02:51 PM Ameisen: it's suboptimal (and sometimes very much so)
02:52 PM Emil: I'm highly doubtful of your analysis being correct
02:52 PM Ameisen: Emil - given that this is what I've been _explicitly told_ by the GCC developers
02:52 PM Ameisen: you're doubting them, not me
02:52 PM Ameisen: this includes GJL's analysis of GCC and the AVR regressions.
02:52 PM Ameisen: this isn't _my_ analysis.
02:52 PM Emil: link to gjl?
02:53 PM Ameisen: I'd have to dig up the emails I had with him, but there's a number of posts by him on a few boards including the GCC ones
02:53 PM Ameisen: the optimizers in GCC are geared towards pointer-word ISAs (x86, ARM, etc)
02:54 PM Ameisen: the 8-bit ISAs it supports it supports basically as afterthoughts
02:54 PM Emil: hmm
02:54 PM Emil: interesting
02:54 PM Ameisen: if it supported x86-16 with segments natively, that could potentially be extended to AVR tohugh
02:54 PM Ameisen: since the addressing modes in AVR are somewhat similar to x86 segments
02:54 PM Ameisen: only a few compilers out there still support that though
02:55 PM Ameisen: there's actually a disturbing amount of hardcoded assembly in avr.c in GCC
02:55 PM Ameisen: which suggests that it's not really doing much optimizating, but is instead looking for fixed patterns.
02:55 PM Ameisen: optimizing*
02:55 PM Ameisen: basically trying to work around the GCC optimizer
02:55 PM Ameisen: but since it's hardcoded, it's not particularly flexible
02:55 PM AndrevS: If you're looking for x86-16 support, I think OpenWatcom would be the answer.
02:56 PM Ameisen: I still have two performance regressions that I've reported that I'm looking into as well
02:56 PM Ameisen: one of them SHOULD be easily fixable
02:56 PM Ameisen: the other... is questionable
02:56 PM Ameisen: both are actually bugs that technically exist on all architectures
02:56 PM Ameisen: but only manifest negatively on AVR
02:56 PM Ameisen: one of them actually results in a code change in x86-64, but the code change has no performance or size impact
02:56 PM Ameisen: on AVR, it bloats the code hguely
02:57 PM Ameisen: it's been verified, but nobody is working on it
02:57 PM Ameisen: the other one is investigating why GCC emits relative accesses instead of absolute accesses when accessing member variables of a static object
02:57 PM Ameisen: on x86, it's irrelevant since mov has like 10,000,000,000 addressing modes and is turing complete
02:57 PM Ameisen: on AVR, that is 2-3x the size
02:58 PM Ameisen: on the mov note, I like movfuscator
02:58 PM Ameisen: it's fun
02:58 PM Ameisen: https://github.com/xoreaxeaxeax/movfuscator
02:58 PM Ameisen: compiles x86 software entirely using mov
02:59 PM Ameisen: LLVM's AVR backend isn't mature enough to show most of these issues, but likely will
02:59 PM Ameisen: I have submitted a few patches for it, but it has a long way to go
02:59 PM Ameisen: I still have to go through _every combination of bit shifts and implement them_
02:59 PM Ameisen: blegh
03:00 PM Ameisen: I should check if the avr-rust people have made any progress there
03:00 PM Ameisen: They took some of my patches and integrated them. I know that they were working more on it, so they may have made more improvements.
03:01 PM Ameisen: 99% of the work there is common with getting C and C++ working for AVR under LLVM, so I follow them loosely
03:04 PM Ameisen: Hmm... might be neat to try to take the gcc LTO bitcode and use that to directly emit AVR machine code.
03:05 PM Ameisen: the LTO bitcode already has a few language optimizations in place, though, which make certain things a bit harder to handle.
03:09 PM Ameisen: still tinkering with build options. avr-libc takes a very long time to build.
03:09 PM Ameisen: I blame the fact that it wants to run ./configure for every damned target, and does so one at a time
03:11 PM Ameisen: it spends more time configuring than building.
03:36 PM LeoNerd: Possibly silly question: if I have two AVR chips linked by SPI, one slave and one master, should I set the *same* CPOL/CPHA settings on both chips, or should one differ from the other?
03:37 PM LeoNerd: I'm getting odd data synchronisation issues between them, where sometimes the master reads data from the slave one bit shifted from what it should be
03:39 PM LeoNerd: But only sometimes; sometimes it's fine
03:51 PM LeoNerd: Bah.. I think it was clock bounce down my logic probe cable or ISP cable
03:51 PM LeoNerd: As soon as I remove both of those it becomes reliable
04:01 PM AndrevS: The logic probe? Maybe a grounding problem?
04:02 PM LeoNerd: Not quite...
04:02 PM LeoNerd: It's an extra bit of cable on the SPI line. Left unterminated, that can cause reflections, especially on high-speed digital edges, like SPI clocks
04:03 PM AndrevS: Ah I see
04:44 PM Ameisen: also looking into how to do huffman/arithmetic encoding of strings in program memory at link time
04:44 PM Ameisen: has to be at link time since it needs to know all the strings being stored to generate a weight table
05:01 PM antto: hm
05:01 PM Ameisen: I'm not sure how to defer a stage of compilation to LTO
05:01 PM antto: i wonder what the AppTable flash section on the xmega is for
05:01 PM Ameisen: I could require it to be a two-stage compile, but I really don't like that
06:05 PM nuxil: LeoNerd, are you makeing a poor mans tdr using spi :p
06:58 PM Emil: Operation Odessa
06:58 PM Emil: I can recommend
07:21 PM McDonaldsWiFi: this schematic relies on a crystal rail-to-rail with a 328p to drive another chips clock... if i use a 4 pin oscialltor can will I still be able to use XTAL2?
07:22 PM McDonaldsWiFi: trying to figure out how to build this without a 16mhz crystal and using my 4 pin oscillator I already have on hand :(
07:31 PM rue_mohr: what schematic
07:31 PM nuxil: McDonaldsWiFi, to drive another chip you enable the clko fuse on PB0
07:31 PM nuxil: and afik oscilators only have 1 output and no inputs
07:32 PM nuxil: crystal need to be driven with a output. but not required for oscilators and resinators if i am correct
07:34 PM nuxil: McDonaldsWiFi, and depending on the other chip. you enable clki fuse or whatever the datasheet requires you to set the fuses to.
07:35 PM nuxil: and yes Xtal becomes a normal i/o pin.
07:35 PM nuxil: *xtal2
07:42 PM McDonaldsWiFi: hmmm
07:42 PM McDonaldsWiFi: what does XTAL2 do if that fuse isn't set?
07:43 PM McDonaldsWiFi: by default
07:43 PM McDonaldsWiFi: maybe some context will help..
07:43 PM nuxil: by default the chip is set to internal RC so its a I/O pin
07:43 PM McDonaldsWiFi: http://searle.hostei.com/grant/MonitorKeyboard/index.html
07:43 PM McDonaldsWiFi: ooohhh
07:43 PM McDonaldsWiFi: if you ctrl f "SOURCE CODE AND PROGRAMMING" you will see the bit about the crystal
07:44 PM McDonaldsWiFi: I wonder fi I can get away with driving both of the chips with the oscialltor output pin insteal of using XTAL2 to drive the other chip
07:44 PM nuxil: you dont use Xtal2 to drive another chip.
07:45 PM McDonaldsWiFi: doesn't surprise me that i'm totally ignorant here xD
07:46 PM McDonaldsWiFi: "Must use XT rail-to-rail clock for the video processor because this also clocks the 74HCT166"
07:46 PM McDonaldsWiFi: OH
07:46 PM McDonaldsWiFi: so the XTAL2 is rewuired for the crystal oscillator
07:46 PM McDonaldsWiFi: but since i have it all in one package its not required now
07:46 PM nuxil: on your driver "atmega328" you set your CKSEL fuses to 0000 and enable CKOUT
07:47 PM nuxil: CKSEL[0:3] set to 0000 should allow you to use a oscilators "external clock"
07:48 PM McDonaldsWiFi: Yeah I was just worried about the other chip. Basically I was scared there was some voodoo going on with XTAL1-2
07:48 PM McDonaldsWiFi: and running the shift register off the same oscaillator wouldn't be sufficent because ther was some kind of magic with XTAL2
07:48 PM nuxil: you only use xtal for crystals. not oscilators
07:48 PM McDonaldsWiFi: some slight delay or something
07:48 PM McDonaldsWiFi: gotcha
07:48 PM nuxil: *xtal2
07:48 PM McDonaldsWiFi: so ill just drive both chips with the oscillator and cross my fingers
07:48 PM nuxil: http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42735-8-bit-AVR-Microcontroller-ATmega328-328P_Datasheet.pdf
07:48 PM nuxil: page 49
07:49 PM McDonaldsWiFi: Yeah i read taht earlier and it mentioned the inverting amp
07:49 PM McDonaldsWiFi: but that's just use to make the crystal resonate?
07:49 PM nuxil: you make chip 1 have the oscilator.. put it on xtal 1. and then drive the other chip with pb0 on its xtal1 or clkIn pin
07:50 PM McDonaldsWiFi: okay awesome I think i got it
07:50 PM McDonaldsWiFi: thanks for the help ^^
07:50 PM nuxil: np.
08:02 PM nuxil: McDonaldsWiFi, you spend to little time in the datasheits :p
08:03 PM nuxil: althi i shouldnt be talking :p
08:04 PM McDonaldsWiFi: well I checked that first thing tbh
08:04 PM McDonaldsWiFi: then i read the inverter amp part and was like.. shit
08:04 PM McDonaldsWiFi: idk if that affects anything xD
08:04 PM nuxil: yea. its just to keep the crystal resonating
08:05 PM nuxil: xtal1 is basically a input. from crystal. and xtal2 is output. to keep it resonating.
08:05 PM nuxil: *for crystal.
08:06 PM McDonaldsWiFi: http://img264.imagevenue.com/loc233/th_046032162_Image015_122_233lo.jpg
08:07 PM McDonaldsWiFi: so would the point on the bottom left next to C1
08:07 PM McDonaldsWiFi: see the same clock that XTAL1 does?
08:07 PM McDonaldsWiFi: errr shit i got that backward
08:07 PM nuxil: so i tip, if you ever want to mesure crystal frequency. enable clkout or if you must put a probe on one of the xtal pins. use xtal2 as its a output and therfor will not be as affected by the probe vs probing the input
08:07 PM McDonaldsWiFi: ahh ty
08:08 PM McDonaldsWiFi: all I have now is an old school analog oscope
08:08 PM McDonaldsWiFi: bout to buy a digital one soon
08:08 PM McDonaldsWiFi: hopefully going to nab a logic analyzer while I'm at it
08:08 PM nuxil: hey.. they are gold worth if you like doing analouge stuff
08:08 PM nuxil: i have too only analoge crt scopes :p
08:09 PM McDonaldsWiFi: hahah they do have novelty!
08:10 PM McDonaldsWiFi: afk
08:10 PM nuxil: :D polprog, gets a orgasme each time he sees a old crt scope, i belive he has a fetish for old crt scopes :p
08:44 PM LoRez: Tom_shop: The PDI interface on this thing is pinned like one would expect, right?
09:19 PM Ameisen: well, I made a quick attempt at implementing float24
09:19 PM Ameisen: now we'll see if it builds/works
09:19 PM Ameisen: probably not.
09:19 PM Ameisen: My guess is that libgcc won't have any helpers for it
09:27 PM Ameisen: I did add __uint40/48/56 as well, though, and also added __uint8/16/32/64 to be explicit about them
09:27 PM Ameisen: so when you have --mint8 you can still specify them
09:35 PM nuxil: float24? how many bits you intend to use for the exponents ?
09:39 PM Ameisen: whatever GCC chooses
09:39 PM Ameisen: gcc doesn't quite give you a choice
09:39 PM Ameisen: I doubt it's going to fully function
09:39 PM Ameisen: will probably have to implement it as a software library
09:40 PM Ameisen: however, following with 754... I'd guess 9 exponent bits, and 15 significant bits
09:42 PM nuxil: dont you need a sign bit aswell ?
09:43 PM nuxil: like.. a sign bit, for positive/negative , n exponents bits and n significand bits.
09:44 PM Ameisen: Hrmm, I just described the interchange format
09:44 PM Ameisen: 14 significant bits
09:50 PM nuxil: hey Ameisen do you like math about floating-point arithmetic ?
09:50 PM nuxil: here you got some good stuff https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html :)
09:52 PM Ameisen: one of the things I've been looking at is alternate representations tha twould be faster to emulate
10:00 PM * Ameisen is curious what gcc will do if he defines __uint1 and __uint4
10:24 PM nuxil: heh.
10:26 PM nuxil: well if that was possible. you waste alot of space.
10:29 PM nuxil: unless you come up with an algorythme that manages to put 8 of thouse together and knowing its bitlocation in the bytefor each of them.
10:38 PM Ameisen: well, that's what I'm wondering
10:38 PM Ameisen: if GCC will be smart enough to pack them
10:39 PM Ameisen: my guess is no
10:41 PM nuxil: my guess is no. since you basically need 2 addresses. one for the byte location in mem and one for the location in the byte.