#avr Logs
Jan 07 2018
#avr Calendar
12:06 AM NonaSuomy is now known as NoSu2
02:47 AM hetii: Hey :)
04:51 AM rue_mohr: writing a program to make fft code for me....
04:51 AM rue_mohr: it seems
04:51 AM rue_mohr: http://paste.debian.net/1003868/
04:51 AM rue_mohr: ok so far
04:53 AM rue_mohr: the fractal nature of the resulting order of the state machine is curious
06:46 AM _ami_: rue_mohr: http://amitesh-singh.github.io/stm32/2018/01/07/making-i2c-slave-using-stm32f103.html <-- might be useful for your project related to i2c.
11:05 AM christner: anyone experienced with pin change interrupts w. the atmega328?
11:05 AM nuxil: im messing around with that now. :p
11:06 AM nuxil: but on a atmega3254
11:06 AM nuxil: *324
11:06 AM christner: I'm seeing a funny issue: when I define one of the PCINT vectors, another pin doesn't seem to hold it's value
11:07 AM christner: even when PCINTn isn't enabled
11:08 AM nuxil: read this
11:08 AM nuxil: https://sites.google.com/site/qeewiki/books/avr-guide/external-interrupts-on-the-atmega328
11:08 AM nuxil: christner, i think you will find it helpfull
11:09 AM christner: yea, I've been throught that one
11:09 AM nuxil: ther are basically 2 types of intertupt. INTX and PCINTX
11:09 AM christner: still no dice
11:10 AM christner: I swapped my simple circuit around to match what he had and copy/paste'd his code in and it still wouldn't cooperate. I'll give it another go just to be sure.
11:12 AM nuxil: i just do: BITS_SET(PCICR, PCIE1); BITS_SET(PCMSK1, PCINT8, PCINT9, PCINT10, PCINT11, PCINT12, PCINT13, PCINT14, PCINT15);
11:12 AM nuxil: ISR (PCINT1_vect) { uint8_t cbs; cbs = PINB ^ portbhistory; portbhistory = PINB; if(cbs & (1 << PB0)) {foo()}}
11:17 AM hetii: Hi
11:17 AM nuxil: the problem with pcint vectors is that they do trigger on any logical change. as with intN vector you can set to trigger on either falling, rising edges.
11:17 AM nuxil: hi hetii
11:28 AM christner: yea, same issue, what's especially weird is that defining PCINT0_vect has an effect even if I only call cli() and never sei()
11:29 AM christner: I have the pin enabled for pull-up, and I can see with my multimeter that it goes low as expected when I press the button
11:30 AM christner: And when I swap it out for polling code, it works as expected, so no bad hookups hardware-wise as far as I can tell
11:30 AM nuxil: maybe paste rellevant code so people can take a peek ?
11:30 AM christner: https://paste2.org/CHJUWIwn
11:32 AM christner: that one has PCINT1_vect defined, it's supposed to be PCINT2_vect, but thats the point, I don't have any of the PCMSK2 interrupts enabled, but defining PCINT1_vect has an affect on the code for some reason
11:32 AM christner: *PCMSK1
11:33 AM nuxil: PCMSK2 |= _BV(PCINT16);
11:33 AM nuxil: you want it to intertup on 1 pin only ?
11:33 AM christner: Yes, just PD0
11:35 AM christner: And if you take out sei() as well, same odd behavior
11:35 AM nuxil: portD
11:35 AM nuxil: but
11:36 AM nuxil: isnt PCMSK2 |= _BV(PCINT16); for portC ? PCINT[23:16] ?
11:36 AM christner: From the datasheet: PD0 (RXD/PCINT16)
11:36 AM nuxil: maybe not.l i dont have datasheet for you chip.
11:37 AM christner: I think PORTC is the next 8 down
11:41 AM Tom_itx is now known as Tom_L
12:00 PM nuxil: christner, i just noticed something. have you enabled the global interupter ?
12:01 PM nuxil: i dont know if your atmega328 does it the same way my atmega324. but, BITS_SET(SREG, 7); to enable global interrupt.
12:01 PM LeoNerd: sei()
12:02 PM nuxil: or that
12:02 PM nuxil: ^^
12:02 PM PsySc0rpi0n is now known as HelloShitty
12:02 PM nuxil: LeoNerd, it will set the interuport bit in SREG ?
12:02 PM nuxil: arg. i cant type :p
12:03 PM LeoNerd: That's what sei() does yes
01:22 PM rue_mohr: christner, did you get it working?
03:34 PM ferdna: hey have any of you used this service:
03:34 PM ferdna: https://www.youtube.com/watch?v=SwSU7YoNWZY
04:07 PM christner: nuxil: yea, I used sei()
04:08 PM christner: rue_mohr: no, not yet. I've dug through a bunch of examples, but I still don't see what I'm doing wrong.
04:17 PM rue_mohr: ok,
04:17 PM rue_mohr: so, your trying to do something with a pin change interrupt, tell me about it hardware wise
04:24 PM Jartza: christner: DDRD &= ~_BV(DDD0); ???
04:25 PM Jartza: shouldn't it be DDRD &= ~_BV(DDRD0);
04:26 PM christner: Jartza: let me check
04:26 PM Jartza: also why #if 0 ? :)
04:26 PM Jartza: the PCINT is never set
04:26 PM Jartza: also you use wrong vector
04:27 PM christner: that's to block comment out the setting for enabling the interrupt
04:27 PM Jartza: for PCIE2 it should be PCINT2_vect
04:27 PM christner: yea, that's all part of the point
04:27 PM Jartza: PCINT1_vect is for PCIE1
04:27 PM christner: nope, DDRD0 isn't defined, and in all of the examples I find DDD0
04:28 PM christner: I've also just used hex constants directly with the same results
04:28 PM rue_mohr: christner, if your interested in my help, tell me what it is your trying to do, then I'll take a look at the source and go over it with ya
04:29 PM Jartza: and how do you know nothing happens in ISR?
04:29 PM Jartza: there's no code in it
04:31 PM Jartza: christner: what toolchain version you're using?
04:31 PM Jartza: I'm always using the bit names from datasheet
04:32 PM christner: rue_mohr: I've started a project w. an atmega328p (trinket pro 5v) and I was just running through all the basics as a refresher. I have a very basic setup, the onboard LED is on PB5 and I have a momentary push button switch attached to PD0 which, when I configure to use as a pin change interrupt, gives me unexpected behavior (the light doesn't turn all they way on or off)
04:32 PM Jartza: ah. it really seems later they've changed to DDD in bits
04:32 PM christner: Jartza: avr-gcc (GCC) 4.9.2
04:33 PM rue_mohr: christner, ok
04:34 PM christner: rue_mohr: when I write it as polling code, every thing works correctly, but when define any PCINTn_vect, PB5 quits cooperating
04:35 PM rue_mohr: christner, so, the basics would be, set the led port up as an output, set the button pin as an input, ... let me dig a second...
04:35 PM Jartza: christner: https://paste2.org/pLX83hOy
04:35 PM Jartza: does that code do anything?
04:36 PM Jartza: it should flip pin B5 when PCINT happens
04:36 PM christner: rue_mohr: yes, I have an example here: https://paste2.org/DdmN5Gjw
04:36 PM rue_mohr: hold on
04:36 PM Jartza: I could quickly plug atmega328p to breadboard and test
04:36 PM rue_mohr: PD0 is your button
04:36 PM christner: if I remove the ISR declaration, the LED is bright and shiny as expected, if I add it, no more bright and shiny
04:37 PM rue_mohr: thats PCINT16
04:37 PM christner: Jartza: I'll try that now
04:37 PM christner: Yea, PD0 (RXD/PCINT16)
04:37 PM rue_mohr: the mask for it is in PCMSK2
04:37 PM christner: Yea
04:38 PM rue_mohr: and that would make it PCIE2 of PCICR
04:39 PM christner: correct
04:40 PM rue_mohr: ISR(PCINT2_vect) {
04:40 PM christner: jartza: that code does the same thing mine did, the led just sits @ about 25% brightness and doesn't change
04:41 PM christner: rue: that matches up, yes
04:41 PM rue_mohr: dear god, not even putting clearbit and setbit in the topic works
04:41 PM christner: Did I not mask one of them correctly?
04:42 PM rue_mohr: ok, NEVER EVER EVER put a delay in a ISR
04:44 PM rue_mohr: LED PB5 button PD0
04:44 PM christner: yes
04:45 PM rue_mohr: I wont tell ya yet
04:45 PM rue_mohr: hodl on
04:46 PM Jartza: rue_mohr: well yeah, never put, it was just a stupid test now
04:46 PM rue_mohr: http://paste.debian.net/1003923/
04:46 PM Jartza: poor man's debounce :D
04:46 PM rue_mohr: see if I'm sane, try that
04:47 PM Jartza: but agreed, in real code, never ever put delay in ISR :)
04:48 PM rue_mohr: christner, ?
04:48 PM rue_mohr: I didn't clear the flag, that happens automatically when you read... a register dosnt it?
04:48 PM rue_mohr: oops?
04:49 PM rue_mohr: where ist he flag register for the pin change?
04:49 PM rue_mohr: the bastards
04:50 PM christner: rue: same thing happens, you mean the interrupt flag?
04:50 PM rue_mohr: oh
04:50 PM christner: It is supposed to clear it @ ISR exit, but PCIFR
04:51 PM rue_mohr: christner, one of the thigns I corrected, is that your writing to PIN and not PORT
04:52 PM rue_mohr: christner, does it do nothing, lock on, or lock off?
04:53 PM christner: rue: it locks off
04:53 PM Jartza: christner: hmmh. the example works for me...
04:54 PM rue_mohr: datasheet says flag is cleared when the interrupt is services
04:54 PM rue_mohr: odd, I'v used it before
04:54 PM christner: jartza: I'll try digging around and see if I have another board here and try that too, I don't think I do
04:54 PM rue_mohr: christner, give me a few mins
04:55 PM Jartza: just plugged atmega328p to breadboard
04:55 PM Jartza: https://paste2.org/mjyZN38z
04:55 PM Jartza: and with this code, button attached to D0 shuts down led when pressed and lights up when released
04:56 PM christner: actually, I've got a super old nano, let me check the pins and give it a go
04:57 PM rue_mohr: // this is pin change for port B, bit 5
04:57 PM rue_mohr: SetBit(PCIE0, PCICR);
04:57 PM rue_mohr: SetBit(PCINT5, PCMSK0);
04:58 PM rue_mohr: ISR(PCINT0_vect) {
04:59 PM rue_mohr: oh, duh, toggle via write to PIN register, sorry
04:59 PM rue_mohr: hey, there is a 328 infront of me right now
04:59 PM rue_mohr: christner, just to be sure, your button goes from ground to the input pin, right?
05:01 PM christner: Yes
05:02 PM Jartza: christner: https://www.youtube.com/watch?v=TNbkxXvWhHw
05:05 PM rue_mohr: christner, I'm sure that code is right, I'll try it now
05:09 PM rue_mohr: reformatting, stand by
05:10 PM christner: yea, it works for the nano, somethings gotta be up with this trinket
05:10 PM rue_mohr: aha
05:11 PM Jartza: my example code works with plain mega328p on breadboard
05:11 PM Jartza: so code is right
05:11 PM rue_mohr: oh yea, well there
05:11 PM rue_mohr: something is up witht eh tricket
05:11 PM christner: yea, but how many times have you blamed the hardware and been wrong?
05:12 PM christner: it's like saying "oh, this will be easy", if you say it out loud, the universe will re-arrange itself to make you wrong
05:12 PM rue_mohr: and for sanity sake, please use SetBit and ClearBit macros so the code is readable?
05:13 PM rue_mohr: just remmeber they only set and clear 1 bit, do other stuff for multiple bits at ocne
05:13 PM christner: Yea, I'll be sure to do that
05:14 PM christner: thanks for running through it with me gentlemen
05:14 PM christner: I think I'll go post on the adafruit forums and see if they have an answer or will let me RMA it
05:15 PM rue_mohr: arg, what arudino pin is D0?
05:16 PM rue_mohr: dude, thats RXI
05:16 PM Jartza: christner: I blame hardware daily, and daily I find bugs in hardware :D
05:16 PM rue_mohr: thats your serial port
05:16 PM rue_mohr: why did you pick that?
05:16 PM Jartza: at customer project, I spent 7 days trying to figure out why the hell fuel gauge code doesn't work
05:16 PM Jartza: everything looked swell, also schematic
05:16 PM rue_mohr: christner, use D2 instead, its just a generic io port,
05:17 PM Jartza: then I happened to check the layout. well. someone connected batgnd to gnd
05:17 PM Jartza: effectively routing around shunt resistor
05:17 PM rue_mohr: christner, ??!!!??!
05:17 PM christner: rue: i tried several, D0 i just had an online example for it to verify against, also it was the closest to the end of the board
05:17 PM rue_mohr: thats your serial data line
05:18 PM rue_mohr: !!!
05:18 PM christner: I'll try it again just to be sure, but if I don't set it up to run as a serial line, does it still behave as a serial line?
05:18 PM christner: That would defeat the purpose of multiplexing the pins wouldn't it?
05:19 PM rue_mohr: if the board has a built in usb serial port, it cant be shut off
05:19 PM rue_mohr: that serial line is the programming mechanism for the arduino
05:19 PM Jartza: ahh, that's very true
05:19 PM rue_mohr: change the code to PD2 INT18
05:19 PM christner: the trinket has another one, also, oddly enough, it's the arduino it works on, not the trinket
05:20 PM rue_mohr: what has an onboard serial usb chip
05:20 PM rue_mohr: arduino pin "2"
05:21 PM christner: it isn't an FTDI chip on the second input, it looks like adafruit set up the bootloader to use a usb interface to behave as a tinyUSB flashing device
05:21 PM christner: did you intend to comment out //DDRD &= ~_BV(DDD0); // set as input
05:21 PM christner: for your example?
05:22 PM christner: or are they inputs by default?
05:22 PM rue_mohr: the pins default to input on reset
05:22 PM rue_mohr: you do not need to set them to input
05:24 PM rue_mohr: try this...
05:24 PM christner: ah, it looks like PD2 is in use by them and "can't" be used in code
05:25 PM rue_mohr: who, what?
05:25 PM christner: them being the fellows @ adafruit
05:25 PM rue_mohr: ok how about pd3?
05:25 PM christner: Trying that now
05:26 PM rue_mohr: hold on,
05:26 PM rue_mohr: try this, it cleans up some stuff
05:26 PM rue_mohr: http://paste.debian.net/1003928/
05:26 PM christner: nope, same issue with PD3
05:26 PM rue_mohr: DOES ADAFRUIT LEAVE ANY PINS YOU CAN USE?
05:27 PM christner: Yea, just PD2 can't
05:27 PM rue_mohr: ok i did the code in that paste for pd3
05:27 PM rue_mohr: pin "3"
05:27 PM christner: I mean same issue as in "PD3 behaves the same way as PD0"
05:27 PM rue_mohr: wtf
05:27 PM christner: It runs correctly on the arduino
05:27 PM rue_mohr: what pin CAN you use
05:27 PM rue_mohr: pd4???can you use pd4????
05:27 PM christner: Any except for PD2
05:28 PM rue_mohr: or dit they take that too?
05:28 PM rue_mohr: ok so you can use pd3?
05:28 PM christner: yes
05:28 PM rue_mohr: http://paste.debian.net/1003928/
05:28 PM rue_mohr: http://paste.debian.net/1003928/
05:28 PM rue_mohr: http://paste.debian.net/1003928/
05:28 PM rue_mohr: ^^ pd3
05:28 PM rue_mohr: }:|
05:29 PM rue_mohr: 8-| does it work!?
05:29 PM rue_mohr: the comments at the top are wrong, and I should have macrod it more
05:29 PM christner: no, it's locked off
05:30 PM rue_mohr: arduino pin "3"
05:30 PM rue_mohr: is it an adafruit arduino?
05:30 PM rue_mohr: god, I'm glad I just buy the chineese ones
05:30 PM christner: no, it's a trinket pro
05:30 PM rue_mohr: isn't that just a ripoff of a pro mini?
05:30 PM christner: basically though
05:30 PM christner: yea
05:31 PM rue_mohr: for what it cost you could have bought 5 pro minis
05:31 PM rue_mohr: ARG
05:32 PM rue_mohr: christner, the code isn't at fault
05:33 PM christner: nope
05:33 PM rue_mohr: throw the adafruit junk away, get some realiable chineese hardware
05:33 PM rue_mohr: :)
05:33 PM rue_mohr: I'm going back to my fourier code!
05:34 PM christner: Waiting for a month is a whole lot less fun than spending a day realizing "it be broke bro"
05:34 PM christner: thanks for your help
05:34 PM rue_mohr: thats why, for $15 you stock 5 of them
05:35 PM rue_mohr: for the prices from china, stock lots of things you might need
05:35 PM rue_mohr: if your in a hurry, charge the north american prices to the person your doing the work for
05:40 PM christner: I'm doing the work for me!
05:41 PM christner: however, I'll go ahead and order a few for one month from now me
05:41 PM christner: do you use banggood? or is there a better one?
05:48 PM nuxil: ebay :p
05:48 PM nuxil: there is also https://eu.mouser.com/
07:40 PM rue_mohr: on avr, for ram, does anyone know if data[foo+1] is more or less of a hit than *(foopointer+1)
07:47 PM nuxil: do a test :p
07:48 PM rue_mohr: I'm slugging thru it now
07:48 PM nuxil: memory access through pointers is said to be more efficiant
07:48 PM rue_mohr: generally, but its different on avr
07:48 PM rue_mohr: maybe not for ram but definitly for program memory
07:50 PM nuxil: if you do a simple test. i'll be you the pointer version will have less instructions.
07:50 PM rue_mohr: I'm trying to decipher wtf the compiler did
07:50 PM nuxil: lol
07:53 PM rue_mohr: 9e: 8f 5f subi r24, 0xFF ; 255
07:53 PM rue_mohr: a0: 80 32 cpi r24, 0x20 ; 32
07:53 PM rue_mohr: a2: e1 f7 brne .-8 ; 0x9c <main+0x1c>
07:54 PM rue_mohr: that seems to be the for loop increment, compare against 32, and loop jump
07:55 PM rue_mohr: 9a: 80 e0 ldi r24, 0x00 ; 0
07:55 PM rue_mohr: ok thats initializing the for counter to zero
07:55 PM rue_mohr: data[i+4] = i;
07:55 PM rue_mohr: 9c: 81 93 st Z+, r24
07:55 PM rue_mohr: so, ...
07:56 PM rue_mohr: wtf set up the Z pointer
08:00 PM nuxil: also. your loop. does it matter how its written? example
08:00 PM nuxil: char a[10]; char *p; p=a;
08:01 PM nuxil: for (p; p < &a[10]; ++p) printf( p[i]);
08:01 PM nuxil: vs
08:01 PM nuxil: for (i = 0; i < 10; ++i) printf( p[i]);
08:01 PM rue_mohr: so Z is registers 30 & 31?
08:02 PM nuxil: yea iirc 30 is zl
08:02 PM nuxil: and 31 zh
08:02 PM rue_mohr: I'v seent eh table but cant find it
08:03 PM nuxil: my atmega 324 datasheet has it on page 21
08:03 PM rue_mohr: whats the section called?
08:04 PM nuxil: AVR CPU Core
08:04 PM nuxil: Overview
08:04 PM nuxil: section 8.0
08:04 PM rue_mohr: aha!
08:04 PM rue_mohr: thanks
08:05 PM rue_mohr: yea, X, Y, and Z are up against the end of the register set ok
08:05 PM Tom_L: http://tom-itx.no-ip.biz:81/~webpage/abcminiuser/articles/progmem_basics_index.php
08:06 PM rue_mohr: 98: 35 96 adiw r30, 0x05 ; 5
08:06 PM rue_mohr: thre is it adding (?) 4 to the offset
08:06 PM nuxil: Nice Tom_L
08:09 PM nuxil: Tom_L, that your page right ? just a tip. make bigger fonts. i need binoculars to read your page :p
08:09 PM Tom_L: zoom in on it
08:09 PM Tom_L: ctrl mouse roller
08:09 PM Tom_L: in ff anyway
08:10 PM nuxil: yes.
08:10 PM Tom_L: it varies from one brouse to the next
08:10 PM Tom_L: *brouser
08:11 PM rue_mohr: ok ok
08:11 PM rue_mohr: they read the stack pointer, subtract 255 for the array I made
08:12 PM nuxil: so your conclusion?
08:12 PM nuxil: which is more effective
08:12 PM Tom_L: rue_mohr, pics in robotics
08:13 PM rue_mohr: then it presets the status register...
08:13 PM rue_mohr: Tom_L, hold on
08:14 PM Tom_L: deep in thought ehh
08:14 PM rue_mohr: it changes the stack pointer
08:14 PM rue_mohr: restores the status register
08:14 PM rue_mohr: more modify stack pointer, then sets up the pointer to the array
08:14 PM rue_mohr: wow
08:22 PM rue_mohr: the compiler is being annoying
08:23 PM Tom_L: i broke a tap off so i had to move one of them over a tiny bit
08:23 PM Tom_L: pisser
08:24 PM rue_mohr: :-s
08:24 PM Tom_L: 4-40
08:25 PM rue_mohr: well theres your problem
08:25 PM rue_mohr: you got a peice of HSS in this block of aluminum
08:26 PM Tom_L: it's gonna stay there too
08:26 PM Tom_L: i think the tap was getting dull
08:26 PM Tom_L: i was just cleaning out the hole after tapping it
08:27 PM rue_mohr: yup
08:27 PM rue_mohr: I hate trying to shatter a peice of tap out of an aluminum project
08:32 PM Tom_L: took a while to do those since i had to take the rails off etc
08:34 PM rue_mohr: OK
08:34 PM rue_mohr: the answer is, that becasue the instructions reduce to a store with the Z pointer as an offset, it dosn't matter
08:35 PM rue_mohr: they become the same thing
08:37 PM rue_mohr: for (i = 0; i < 24; i++) {
08:37 PM rue_mohr: *(p+PINB) = PIND;
08:37 PM rue_mohr: }
08:37 PM rue_mohr: now lets be evil
08:37 PM _ami_: rue_mohr, trying to crash AVR? ;)
08:38 PM rue_mohr: I have to choose number sources the compiler cant optimize out on me
08:38 PM _ami_: or trying to check the possible intel silicon bug beneath avrs? :P
08:38 PM rue_mohr: haha
08:38 PM _ami_: ok :)
08:39 PM rue_mohr: trying to workout what method of memory arry handling is most efficient on avr
08:40 PM rue_mohr: oh thats right, gcc uses r1 as a fixed "zero" value
08:40 PM rue_mohr: ok random offset indexing isn't pretty
08:41 PM rue_mohr: it has to manually add the offset
08:41 PM rue_mohr: I thought there was an instruction for relative addressing
08:42 PM rue_mohr: no
08:43 PM rue_mohr: there is just indexed addressing with the option to postincrement or predecrement
08:44 PM rue_mohr: ouch, and its 2 cycles
08:45 PM rue_mohr: _ami_, writing (kinda) fft code for an avr
08:45 PM rue_mohr: code thats not blindly translated from a paper written in 1976
08:45 PM _ami_: hmm, looks interesting..
09:03 PM _ami_: mt fpga board has arrived. :) https://pbs.twimg.com/media/DS-3gD4VwAARh0U.jpg
09:05 PM nuxil: have fun :)
09:05 PM nuxil: how much did you pay for it ?
09:06 PM Tom_L: did they give you the pinouts for all the stuff on it?
09:06 PM Tom_L: and what fpga is it?
09:07 PM Tom_L: xilinx or something else?
09:09 PM rue_mohr: geez, this fft code keep taking me back to the towers of hanoii
09:12 PM nuxil: looks like altera cyclone
09:12 PM nuxil: Tom_L, i think it this one http://rzrd.net/product/?79_502.html
09:18 PM nuxil: rue_mohr, har nut to crack? its for your speach thingy ?
09:19 PM rue_mohr: its kinda a tangent
09:19 PM _ami_: Tom_L, its Altera(Intel) Cyclone 4
09:19 PM _ami_: 35$
09:19 PM rue_mohr: I want to do fft on avr,
09:19 PM rue_mohr: and the mess of code everyone is using has me on a rampage
09:20 PM nuxil: this stuff ? https://rosettacode.org/wiki/Fast_Fourier_transform#C
09:20 PM _ami_: i have to setup the dev environment for altera board on linux today night when i get back to home.
09:21 PM _ami_: Tom_L, nuxil : https://www.aliexpress.com/item/FPGA-development-board-ALTERA-Cyclone-IV-EP4CE-four-generations-SOPC-NIOSII-send-send-remote-control-to/32691369830.html
09:21 PM rue_mohr: nuxil, well, yes, BUT that is the recursive version thats not gonna happen on an avr
09:21 PM _ami_: hopefully i able to run a blink led program on this board today. :P lets see how it goes.
09:22 PM nuxil: ^^
09:23 PM _ami_: Tom_L, i got the datasheet for this board from seller.
09:23 PM _ami_: have not looked at it yet
09:23 PM _ami_: but seller has provided the softwares and other guides
09:23 PM _ami_: softwares are for windows so i am not gonna use them
09:26 PM _ami_: rue_mohr, https://www.youtube.com/watch?v=9R3-0-Xg_Ro its pretty good guide.
09:27 PM rue_mohr: no, I'm redoing the 1976 based code
09:27 PM rue_mohr: everyone just uses prettymuch the same code
09:27 PM rue_mohr: the recursive version is one of the most modern things done to it
09:39 PM rue_mohr: it dosn't add up to me that they would go to all the trouble to reindex all the values, and then go to more trouble to order the calculations in the order they did
09:40 PM rue_mohr: and I cant see thru both layers at the same time
09:50 PM Tom_L: _ami_, pretty cheap for all you get on that
09:50 PM Tom_L: i'm not sure about altera tools though
09:50 PM Tom_L: i've got xilinx webpack on windows and linux here
09:50 PM Tom_L: haven't done much with it lately though
10:09 PM rue_mohr: and its funny, cause the authors were so amazing good at crafting these complex number sequences
10:12 PM _ami_: Tom_L, yes, i invested a bit time in finding the cheapest one. :P
10:12 PM tpw_rules: rue_mohr: are you using FFTPACK
10:12 PM tpw_rules: maybe you can get a fortran compiler up for avr
10:13 PM _ami_: i could have bought like ~100$ FPGA board but i was afraid that if i don't find fpga programming interesting enough.
10:14 PM rue_mohr: tpw_rules, I'm rewriting the code, casue ALL the code I see online has HORRIBLE THINGS going on
10:14 PM rue_mohr: its like arduino code, actaully
10:14 PM tpw_rules: what was the source
10:14 PM tpw_rules: use FFTPACK
10:14 PM rue_mohr: all sources I have found
10:14 PM rue_mohr: maybe you dont understand, all th code online is horrid
10:14 PM rue_mohr: it may work, but its horrid
10:15 PM rue_mohr: for (i = 0; i < 256; data[i] = i, i++); // wee!
10:15 PM Tom_L: _ami_, this is one i got years ago: http://tom-itx.no-ip.biz:81/~webpage/temp/xilinx1.jpg
10:15 PM tpw_rules: link me a source
10:15 PM rue_mohr: for ( i = 0; i < 32; printf("%d \n", data[i]), i++); // you may now file me for loop abuse
10:15 PM tpw_rules: and yeah that's what a) numeric and b) scientific code looks like
10:15 PM tpw_rules: you should be glad there are comments
10:15 PM Tom_L: alot smaller fpga but similar
10:15 PM rue_mohr: tpw_rules, any source online, its all awefull
10:15 PM tpw_rules: link me one
10:16 PM rue_mohr: I'm working with a derivitite of the code in numerical methods
10:16 PM _ami_: Tom_L, nice.
10:16 PM tpw_rules: yeah that's your problem
10:16 PM rue_mohr: I'm ashamed of them for publishing it
10:16 PM Tom_L: it's pretty dated
10:16 PM Tom_L: but i had fun with it
10:16 PM rue_mohr: they just copied it from the 1976 stuff
10:16 PM _ami_: does xinlix tool still support it?
10:17 PM Tom_L: webpack
10:17 PM tpw_rules: why are you trying to do fft on avr anyway
10:17 PM rue_mohr: anyhow, I'm kinda burried in it just now
10:17 PM Tom_L: yes
10:17 PM tpw_rules: don't you at least want something with hardware float
10:17 PM Tom_L: at least i think it does
10:17 PM rue_mohr: tpw_rules, cause, anyting can do it, and I never have
10:17 PM rue_mohr: this is a been there, done that excersize
10:17 PM tpw_rules: i've only done dct
10:17 PM rue_mohr: no, I'm prolly gonna do it in 8 bit integer
10:18 PM rue_mohr: I have a lot of cleanup to do
10:18 PM Tom_L: _ami_, some code here: http://tom-itx.no-ip.biz:81/~webpage/temp/xilinx/
10:18 PM rue_mohr: its just, the ... the code stunns me
10:18 PM Tom_L: i forget what it does
10:18 PM Tom_L: but it may drive the led display
10:18 PM tpw_rules: rue_mohr: that's the kind of code scientists write
10:18 PM Tom_L: as a counter or something
10:18 PM tpw_rules: they just want fast FFTs
10:18 PM tpw_rules: not pretty code
10:18 PM tpw_rules: also they never know what they're doing
10:19 PM rue_mohr: I can tell that
10:19 PM rue_mohr: they went to a LOT of work to make a mess
10:19 PM _ami_: Tom_L, cool, thanks. made a note of it.
10:19 PM tpw_rules: it was probably the fastest way of filling an array for some compiler in 1973 and if you suggest changing it they'll murder you
10:19 PM rue_mohr: its like its layers of people not completely knowing whats going on, but that they want it to work just a *bit* different
10:19 PM tpw_rules: and/or it's a direct transliteration of the original fortran
10:19 PM rue_mohr: thats what I'm trying to find out
10:20 PM rue_mohr: the origional source is from an ieee book (paper?) published in 1976
10:20 PM _ami_: btw, guys. i was hacking i2c on stm32f103 recently. here is write up on how to create a custom 2$ i2c 32bit slave device: http://amitesh-singh.github.io/stm32/2018/01/07/making-i2c-slave-using-stm32f103.html
10:20 PM _ami_: code is pretty simple and easy to understand.
10:20 PM rue_mohr: "A new principal for fast fourier transformation" CM rader and NM Brenner
10:21 PM tpw_rules: the code on wikipedia isn't too horiffic
10:21 PM rue_mohr: not gonna try to do the recursive code on an avr
10:21 PM rue_mohr: already need most of the ram for the array
10:21 PM rue_mohr: OR ARRAYS
10:21 PM rue_mohr: I'm torn right now on the difference between using one array or two arrays
10:22 PM rue_mohr: (split or interlace the real and complex numbers)
10:22 PM tpw_rules: i don't think you have to recurse if your input is a power of two
10:22 PM rue_mohr: I honestly cant say there is a difference in having them interlaced
10:23 PM tpw_rules: oh you still do
10:23 PM tpw_rules: well any recursion can be rewritten as a loop.
10:23 PM tpw_rules: it's not like you're allocating new storage
10:23 PM tpw_rules: on every recurse
10:24 PM tpw_rules: i think you can do the separate loop with the xor swap trick
10:24 PM tpw_rules: oh, maybe not
10:24 PM tpw_rules: but still, that only requires a local storgae
10:24 PM tpw_rules: i believe in you! use the wiki method
10:25 PM Tom_L: _ami_, http://www.asic-world.com/verilog/veritut.html
10:26 PM rue_mohr: obviously I'm not using that non-threadsafe swap macro
10:26 PM tpw_rules: why not
10:26 PM rue_mohr: general policy of not using threadsafe methods
10:26 PM Tom_L: _ami_, http://www.xess.com/projects/
10:26 PM tpw_rules: what
10:26 PM rue_mohr: I just use the xor method, takes just as long
10:27 PM rue_mohr: er, sorry
10:27 PM tpw_rules: i don't understand
10:27 PM rue_mohr: wrote that wrong
10:27 PM tpw_rules: 99% of code you write and use is not threadsafe?
10:27 PM rue_mohr: general policy of not using unthreadsafe methods
10:27 PM rue_mohr: ~
10:27 PM rue_mohr: I forgot the not :)
10:27 PM tpw_rules: anyway, the wikipedia one is threadsafe and can be rewritten without recursion
10:28 PM _ami_: thanks Tom_L
10:28 PM Tom_L: i had a tutorial but the link appears dead
10:29 PM rue_mohr: tpw_rules, what code are you looking at?
10:29 PM rue_mohr: I'm pretty sure I'v seen it all
10:29 PM tpw_rules: https://en.wikipedia.org/wiki/Cooley%E2%80%93Tukey_FFT_algorithm
10:29 PM tpw_rules: you can trivially rewrite that to be not recursive
10:29 PM tpw_rules: and the separate method doesn't need that temp array
10:30 PM tpw_rules: or to be run more than once?
10:30 PM rue_mohr: I'm on a track
10:30 PM tpw_rules: hm?
10:32 PM rue_mohr: I'm 2 days into rewriting the numberical methods code
10:32 PM tpw_rules: ooookay
10:32 PM rue_mohr: I'm not changing what I'm doing from where I'm at now
10:32 PM rue_mohr: I'll end up in the same place anyhow
10:35 PM rue_mohr: I'm not saying your wrong, I'm saying I dont want to ditch my current work and start on soemthing else that might not work out right now
10:36 PM rue_mohr: oh god, this is crazy
10:37 PM rue_mohr: the array reindexing is just so that they can work up instead of down
10:37 PM rue_mohr: ah, it makes the order match the .. ugh
10:38 PM tpw_rules: i mean i'm saying i can get a working fft implementation for avr in a couple hours while you're about to justifiably kill yourself from reading too much code written by mathematicians
10:38 PM rue_mohr: I know you can copy and paste the horrid code form the internet
10:38 PM rue_mohr: thats not my goal
10:38 PM tpw_rules: what is your goal
10:39 PM tpw_rules: "This works, and is visibly clear about what is happening where."
10:39 PM rue_mohr: I want to understand a bit more about whats going on and see if the mess thats being used is justified or not
10:39 PM tpw_rules: it's almost certainly speed
10:40 PM rue_mohr: no, its because they were interperting it from fortran or soemthing
10:40 PM rue_mohr: it looks like there must be simple things in C that aren't simple in fortran
10:40 PM rue_mohr: or whatever hell language this is from
10:41 PM tpw_rules: it's because they didn't know C
10:41 PM tpw_rules: anyway, the crazy fortran was for speed and cause they didn't know fortran either
10:41 PM rue_mohr: I'm pretty sure in 76 it didn't exist
10:41 PM tpw_rules: C did in 73
10:41 PM tpw_rules: i checked for the purpose of the joke earlier
10:41 PM rue_mohr: :)
10:42 PM tpw_rules: well i gotta go to bed. Godspeed. self-care is important
10:42 PM rue_mohr: oh I should have supper...
10:42 PM rue_mohr: hey its not 3am again!
10:42 PM rue_mohr: I can code a bit longer...
10:42 PM rue_mohr: mmax= 002, m= 000, i= 000, j= 004
10:42 PM rue_mohr: mmax= 002, m= 000, i= 002, j= 006
10:42 PM rue_mohr: mmax= 002, m= 000, i= 001, j= 005
10:42 PM rue_mohr: mmax= 002, m= 000, i= 003, j= 007
10:42 PM rue_mohr: mmax= 004, m= 000, i= 000, j= 002
10:43 PM rue_mohr: mmax= 004, m= 000, i= 001, j= 003
10:43 PM rue_mohr: mmax= 004, m= 001, i= 004, j= 006
10:43 PM rue_mohr: mmax= 004, m= 001, i= 005, j= 007
10:43 PM rue_mohr: mmax= 008, m= 000, i= 000, j= 001
10:43 PM tpw_rules: oh no
10:43 PM rue_mohr: mmax= 008, m= 001, i= 004, j= 005
10:43 PM rue_mohr: mmax= 008, m= 002, i= 002, j= 003
10:43 PM rue_mohr: mmax= 008, m= 003, i= 006, j= 007
10:43 PM rue_mohr: m isn't important, I need to generate code for that sequence
10:59 PM rue_mohr: it strikes me that j is almost a grey code count
11:09 PM Casper: oh hey... it's rue_mohr the spammy
11:09 PM Casper: as bad as those spammer...
11:09 PM Casper: still hasn't learn to use a pastebin?
11:09 PM rue_mohr: sory, did I interrupt your conversaton with OH RIGHT YOU WEREN'T
11:10 PM rue_mohr: :P
11:20 PM Casper: rue_mohr: you start to sound like flyback...
11:21 PM day__ is now known as day
11:30 PM rue_mohr: eeek