Back
[00:07:46] <Emil> Hmm
[00:07:54] <Emil> https://emil.fi/jako/cap.c
[00:09:03] <Emil> Any idea why that is still triggerin on interrupts during other other interrupts?
[00:09:25] <Emil> Hmm, there might be a bug in putn
[00:09:45] <Emil> Yes, there is
[00:11:53] <Emil> Better
[00:12:15] <Emil> Except it still fails
[00:13:04] <Emil> Now it should work
[09:54:43] <avrdude> semi-unrelated question: i have a pic32mx, and it has ICSP (same as ISP?) and EJTAG.. it doesn't really say much more than that, so I'm not entirely sure how I'm going to program this thing
[09:55:04] <avrdude> can I use an AVR Dragon for example to flash code onto it?
[12:20:17] <bss36504> avrdude: it is highly unlikely that microchip's ICSP is in any way compatible with Atmel's, or with atmel programmers.
[12:23:23] <DKordic> avrdude: Which device? DevBoard?
[12:29:01] <DKordic> [[
http://ww1.microchip.com/downloads/en/DeviceDoc/60001145S.pdf][PIC32 Flash Programming Specification]] is clearly linked from, for example, [[
http://www.microchip.com/wwwproducts/en/en552033][PIC32MX534F064H]].
[12:29:18] <DKordic> BTW there is also ##pic.
[12:30:35] <bss36504> Theres also a develoopment tools tab linked from that product page; you can use a Pickit 3 or others to program it.
[12:47:13] <FL4SHK> Why are AVRs good for C?
[12:47:40] <FL4SHK> I'm being challenged on my understanding that 8-bit can work for C
[12:47:54] <bss36504> C -> Compiler -> machine code
[12:47:56] <FL4SHK> I'm working on a new instruction set that is 8-bit
[12:48:21] <FL4SHK> bss36504: I mean the instruction sets, why are they good for C?
[12:48:31] <bss36504> That doesnt make sense
[12:48:36] <FL4SHK> Why doesn't it?
[12:48:39] <FL4SHK> Some instruction sets are not good for C
[12:49:01] <FL4SHK> The 6502 is a good example
[12:49:11] <bss36504> the instruction set is what it is, the compiler is responsible for translating the high level language (C, C++, hell, even Rust now) into assembly
[12:49:26] <FL4SHK> Er
[12:49:29] <FL4SHK> I know that
[12:50:00] <bss36504> the 6502 was designed in 1975, they didnt really have their eye on making the instruction set work well with higher languages.
[12:50:05] <FL4SHK> I know that
[12:50:22] <FL4SHK> Why are the AVR instruction sets better suited to C than the 6502?
[12:52:58] <bss36504> I don't know. More instructions? I fail to see why you couldnt make a C compiler target a 6502...your whole premise of "better" or "worse" is very hand-wavy. Show me some concrete examples. If you can say that the same C program runs better on an AVR than a 6502, then I imagine you would simply need to look at the generated assembly to answer your
[12:52:58] <bss36504> question.
[12:53:10] <FL4SHK> ahhh
[12:53:31] <FL4SHK> well, maybe it's easier to make a good C compiler for AVR than a good one for 6502
[12:53:58] <bss36504> a quick search shows the 6502 has 50 ish instructions, the AVR has over 100.
[12:54:07] <bss36504> maybe it is, I'm not a compiler writer.
[12:54:44] <FL4SHK> I'm developing my own instruction set and CPU
[12:55:42] <bss36504> Here's one concrete difference, the 6502 doesnt have a multiply instruction (as far as I know, im not exactly an expert on them). On an avr, multiplying two 8 bit numbers is 2 clock cycles. To do the same on a 6502 would involve looping and adding, which of course would be much less efficient.
[12:56:47] <FL4SHK> I see your point, though I will add that there are multiple multiplication algorithms
[12:57:04] <LeoNerd> ATtiny chips don't have MUL ;)
[12:57:15] <FL4SHK> Are ATtiny chips still okay for C?
[12:57:22] <LeoNerd> Sure
[12:57:26] <FL4SHK> okay
[12:57:26] <LeoNerd> gcc synthesizes a multiply
[12:57:36] <FL4SHK> Most of the time aren't multiplications by constants anyway?
[12:57:42] <FL4SHK> except in some specialized applications
[12:57:46] <LeoNerd> A reasonable amount
[12:58:03] <LeoNerd> Certainly any of the implicit multiplies for array access and the like
[12:58:11] <FL4SHK> Right
[12:59:00] <LeoNerd> Annoyingly, last time I looked gcc was *really* stupid
[12:59:10] <FL4SHK> GCC does a lot of stupid things on ARM as well
[12:59:21] <LeoNerd> It can make an efficient i*2 (by just adding i to i); or i*4 (by adding i to i, then adding the result to itself)
[12:59:26] <LeoNerd> but it can't make an efficient i*3
[12:59:42] <LeoNerd> It calls a generic multiply routine built into the tiny libc, with the arguments i and 3 as registers
[12:59:47] <specing> LeoNerd: it can do it even more efficiently
[12:59:59] <specing> i*4 is two shifts to the left
[13:00:02] <LeoNerd> Sure
[13:00:10] <LeoNerd> That's the same number of instructions
[13:00:17] <LeoNerd> Same timing. probably same power usage even
[13:00:27] <LeoNerd> Point being: it's *an* efficient implementation. unlike i*3
[13:01:08] <FL4SHK> efficient i * 3 can be just three adds
[13:01:45] <bss36504> Yes of course but building a good compiler isnt a trivial exercise and sometimes you make sacrifices in the name of flexibility
[13:02:05] <FL4SHK> I agree
[13:02:40] <bss36504> And potentially the overhead of adding all these if-then-else to check various conditions of the operands might be more overhead than the way they do it now.
[13:03:42] <LeoNerd> Efficient i*3 can be *two* adds
[13:04:05] <LeoNerd> MOV Rx, i; ADD Rx, i; ADD Rx, i
[13:04:05] <FL4SHK> oh yeah
[13:04:07] <LeoNerd> ;)
[13:05:20] <DKordic> ``lsl R'' has the same encoding as ``add R, R''.
[13:05:39] <FL4SHK> lsl \n add
[13:06:14] <LeoNerd> Yup :)
[13:22:30] <Evidlo> Anyone have experience with the Arduino-Makefile project? I'm trying to get it set up for a tiny85, but I'm having issues
[20:40:18] <rue_house> what kinda issues?