#avr Logs
Aug 29 2017
#avr Calendar
02:44 AM polprog: oshix: avrdude can differentiate between memories on the chip, hence the -U option
04:03 AM enh: morning
04:03 AM enh: 5:32 here
04:07 AM dsalychev1: morning, it's 10:36 AM here :)
04:08 AM enh: germany?
04:10 AM noHitW_work: morning
04:10 AM dsalychev1: poland
04:10 AM enh: +5h is germany/france summer time, i believe
04:10 AM enh: near
04:10 AM dsalychev1: yep
04:11 AM dsalychev1 is now known as dsalychev
04:13 AM enh: i wonder if people play with avr in russia. Do not remember seeing anyone from there here
04:17 AM dsalychev: :) I'm from Russia, to be honest. Live in Poland for 1.5 years only.
04:18 AM enh: your nick sounds russian
04:18 AM dsalychev: yep
04:18 AM enh: life is good in poland?
04:18 AM dsalychev: good enough, politic situation was a reason why I moved
04:19 AM enh: like here, probably. Brazil is a political mess.
04:19 AM dsalychev: yeah, I heard
04:21 AM dsalychev: there is a lot of guys playing with all of these embedded stuff in Russia, but almost all of them are shy to talk or share :D
04:23 AM enh: shouldn't be. All russians I met in France were nice people
04:23 AM dsalychev: agree
04:26 AM ohsix: polprog: they're in the .conf file, sure; but it isn't just a list of addresses, it's broken down by region and what the probe does to initiate the read on that region
05:30 AM Lambda_Aurigae: enh, my kids are grown and gone and I haven't seen them in nearly 20 years.
05:32 AM dsalychev: wow, sad
05:37 AM Lambda_Aurigae: life in the big city.
05:38 AM Lambda_Aurigae: I'm ok with it. I have a new life and I'm happy.
05:40 AM dsalychev: ;)
05:52 AM Lambda_Aurigae: I'm still not allowed to travel to former eastern block countries or many muslem countries, but,,,I can't afford to anyhow.
05:53 AM Lambda_Aurigae: but that has nothing to do with family and everything to do with my former life in the military
05:55 AM Lambda_Aurigae: polprog, try some spi sram or spi nvsram from microchip.
05:55 AM Lambda_Aurigae: up to 1Mbit.
05:56 AM Lambda_Aurigae: the sram is capable of single, dual, or quad data channels with spi signaling.
05:56 AM Lambda_Aurigae: the nvsram is single or dual.
06:09 AM * LeoNerd wants some RMW-capable SPI RAM
06:10 AM Lambda_Aurigae: RMW?
06:10 AM LeoNerd: Read-modify-write
06:11 AM LeoNerd: SPI is full duplex. I want a chip I can be reading and writing at the same time
06:11 AM Lambda_Aurigae: hmmm.
06:11 AM LeoNerd: The idea would be you give it an address and read a byte. Then you can write a new value for that byte while reading the next byte
06:11 AM LeoNerd: So if you want to modify an entire line of, say, 160 bytes, you only have to make 161 byte-wide transfers plus the setup/address at the start
06:11 AM LeoNerd: I want to use such a memory for storing a display buffer in which I'm making small edits
06:13 AM Lambda_Aurigae: yeah,,don't know of any that do that.
06:14 AM LeoNerd: Hrmmm
06:15 AM Lambda_Aurigae: not that they don't exist..I just don't know of any.
06:18 AM Lambda_Aurigae: I've done a double buffering kind of thing for that with two chips.
06:18 AM Lambda_Aurigae: read one while writing the other on two different spi connections.
06:22 AM Lambda_Aurigae: mostly with that though I used one chip for display buffer, clocking data directly out of the chip to the video output....then the second chip I made modifications to from the processor...then during vertical blanking intervals I copied data from the modified chip to the display chip.
06:22 AM Lambda_Aurigae: or, used 3 chips.
06:22 AM Lambda_Aurigae: A and B are display chips...only displaying from one or the other, not both.
06:23 AM Lambda_Aurigae: write to the preload buffer chip.
06:23 AM Lambda_Aurigae: then the system would copy the preload buffer chip to the display chip not currently displaying..once copy is done, switch chips and copy to the other.
06:23 AM Lambda_Aurigae: was kind of overkill but a fun project.
06:24 AM LeoNerd: Ooh, two chips and seesaw the data
06:24 AM LeoNerd: That might work also
06:24 AM Lambda_Aurigae: I've done it with just two chips but had to write the data twice.
06:24 AM Lambda_Aurigae: having the third chip means the drawing/write is done once then just two sets of copies in the background.
06:24 AM LeoNerd: Mmm
06:25 AM LeoNerd: Well, what I want to do is offload part of the work to a separate chip
06:25 AM Lambda_Aurigae: at 20MHz it doesn't take long to copy from one to the other 4 bits at a time.
06:25 AM Lambda_Aurigae: love sqi mode with sequential data clock in and out.
06:25 AM LeoNerd: It's a display buffer for a string of WS2812s. What I really want to do is write the display into that buffer then hand it over to another chip to actually squirt the bits out to the LEDs themselves
06:25 AM LeoNerd: Then when it's done I'll take the buffer back and write the next frame
06:25 AM Lambda_Aurigae: so use two chips and alternate them.
06:26 AM Lambda_Aurigae: how fast do you need to clock data out of the chips?
06:26 AM LeoNerd: An ATtiny85 can -almost- do that. It has 5GPIOs if I don't do HVSP magics. WS2812, leaving 4 for SPI
06:26 AM LeoNerd: Except I get no signalling that way. So I'll have to HVSP it to get all 6 GPIOs
06:26 AM Lambda_Aurigae: http://www.microchip.com/wwwproducts/en/23LC1024
06:27 AM Lambda_Aurigae: with that chip driving the data out to the strip from the nvsram, you don't even need it to read the data from the nvsram...
06:28 AM Lambda_Aurigae: bah..sram, not nvsram
06:28 AM Lambda_Aurigae: your controller that writes the data to the buffer chip(sram) can set it to a beginning location and set it to clock out mode.
06:28 AM Lambda_Aurigae: then the tiny85 can just start toggling the clock line and let the data feed out to the strip.
06:28 AM Lambda_Aurigae: I think.
06:29 AM LeoNerd: Nope, because the data won't be the right shape
06:29 AM LeoNerd: 2812 isn't the SPI chain
06:29 AM Lambda_Aurigae: aahh
06:29 AM Lambda_Aurigae: I don't know how that works.
06:29 AM LeoNerd: It's sortof async serial. It's a single pin
06:30 AM LeoNerd: Every bit is a Low->High->Low transition; it just signals a 0 or 1 bit by difference in timing of the high pulse
06:30 AM LeoNerd: So it needs very exact timing.Hence ideally a dedicated chip to write it
06:30 AM Lambda_Aurigae: could you not encode that as binary data stream?
06:31 AM LeoNerd: I *could* encode that into the SPI RAM sure... but that means the chip writing the data in there has to do that conversion
06:31 AM Lambda_Aurigae: looking at the datasheet, if you sent a stream out like that it should work.
06:31 AM LeoNerd: The entire point of my setup is that the master chip just treats the SPI RAM as its display buffer
06:31 AM LeoNerd: Storing raw RGB values or whatever
06:31 AM LeoNerd: The separate output chip does the conversion
06:32 AM Lambda_Aurigae: so, yeah, would need 6 i/o pins for that for one buffer chip.
06:32 AM LeoNerd: I can obtain that. I have an HVSP programmer :)
06:32 AM Lambda_Aurigae: not sure how you would switch two unless you tied the chip select lines from the master controller.
06:32 AM LeoNerd: ... that I made ;)
06:32 AM LeoNerd: Actually the hard part is working out how to dual-master the SPI RAM between the two
06:33 AM LeoNerd: I think the writer has to hiZ its control lines
06:33 AM Lambda_Aurigae: yeah.
06:33 AM LeoNerd: But that's possible
06:33 AM Lambda_Aurigae: would need some extra controller chip in between...74 series buffer tristateable.
06:34 AM Lambda_Aurigae: it's too early to be designing this in my head!
06:34 AM Lambda_Aurigae: hehe
06:35 AM Lambda_Aurigae: I have yet to get any of those led strips to play with.
06:35 AM Lambda_Aurigae: haven't had a need for them.
06:35 AM LeoNerd: 74'125 or '126 chips are useful
06:35 AM LeoNerd: I keep a strip of those.. 1gate versions
06:36 AM LeoNerd: Lovely little things :)
06:37 AM Lambda_Aurigae: I have an avr programmer made from a 74125.
06:37 AM Lambda_Aurigae: parallel port programmer
06:37 AM LeoNerd: The 1G versions are SOT-23-5 sized
06:37 AM Lambda_Aurigae: all fits in a db25 hood
06:37 AM Lambda_Aurigae: this is through hole too.
06:37 AM LeoNerd: So easy to squeeze into a little gap somewhere on a board at last minute
06:38 AM Lambda_Aurigae: it's my second avr programmer I ever made...first is based on the 74244
06:38 AM Lambda_Aurigae: both still work and I still use them...more than I use the various usb programmers I have.
06:40 AM Lambda_Aurigae: https://www.amazon.com/dp/B07417BRFN/ref=asc_df_B07417BRFN5144679/?tag=hyprod-20&creative=395033&creativeASIN=B07417BRFN&linkCode=df0&hvadid=198081434346&hvpos=1o6&hvnetw=g&hvrand=2989132058383341569&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9017936&hvtargid=pla-354213312932
06:40 AM Lambda_Aurigae: now that looks useful.
06:41 AM LeoNerd: BTW, you know that https://www.amazon.com/dp/B07417BRFN/ is sufficient as a link? ;)
06:41 AM Lambda_Aurigae: hehe..didn't actually..
06:42 AM Lambda_Aurigae: when you send data out the chain for that, do you see the pixels change as the data flows down the stream?
06:44 AM LeoNerd: If the chain is long enough you can do yes
06:45 AM LeoNerd: The first pixels will update first, and then slightly later down the far end
06:45 AM enh: hi. I'm back. I asked about kids because you seem to have a lot to teach. It would be sad if you had not had the chance.
06:45 AM LeoNerd: Which is why really long chains are bad for "video wall"-type applications. You want lots of shorter ones
06:47 AM enh: My SPI protocol is now transfering data with correct signals, but the data seems to be random. I suspect the stack is overflowing. Soo annoying
06:50 AM Lambda_Aurigae: enh, I teach other peoples' kids.
06:50 AM Lambda_Aurigae: so the display doesn't shift down the chain...first pixel grabs first data then locks in and feeds subsequent data downstream?
06:51 AM Lambda_Aurigae: enh, babysteps....make one bit work, add something else, add something else...testing everything along the way.
06:51 AM dsalychev: There is a chance that someone will be interested in http://www.mcusim.org. I've worked on it for a while and there is a huge room for improvements and further development. Any help and comments are bloody welcome!
06:51 AM Lambda_Aurigae: once you learn how it all works together then it gets easier to work in bigger blocks.
06:52 AM Lambda_Aurigae: dsalychev, nice, but, it doesn't simulate any of the chips I use.
06:52 AM Lambda_Aurigae: attiny85, atmega1284p
06:52 AM Lambda_Aurigae: yeah, I like to go to extremes.
06:59 AM Lambda_Aurigae: ok...off to work to break things!
07:04 AM polprog: Lambda_Aurigae: why cant you travel to former eastern block countries?
07:05 AM Emil: watcha mean
07:18 AM enh: polprog: I believe if you do not like comunism you are not allowed too,
07:20 AM dsalychev: enh, it looks like a legal question, not a wish
07:20 AM enh: I heard russia is not a free place any more
07:20 AM enh: They do not like opposition there.
07:21 AM dsalychev: you're probably talking about goverment
07:21 AM enh: Much like it will be in Brazil if the leftists take over
07:21 AM enh: yep, dsalychev
07:22 AM enh: But this is a channel about avr microcontrollers
07:22 AM dsalychev: yeah, let's not spoil it
07:25 AM enh: have to go feed the kid
08:09 AM polprog: im just curius cos many people include PL in former eastern block countries
08:09 AM polprog: but as enh said, it's a channel about avrs
08:09 AM polprog: let's not bring any political manure here
08:10 AM dsalychev: it's expected because of https://en.wikipedia.org/wiki/Warsaw_Pact, I guess
08:41 AM hetii: Hi :)
08:41 AM polprog: o/
08:47 AM hetii: I have such code: https://pastebin.com/Yun5UxMr When I remove the printf with "foo..." then atoi return always 0
08:47 AM hetii: any idea what can happen there ?:)
08:48 AM polprog: mfw pin read-write cycle gives barely 30khz on arduino :D https://www.youtube.com/watch?v=Xk7u_1dy0fk
09:01 AM rue_bed: see, if you do that with the avr directly you get about 8Mhz
09:05 AM polprog: if you did that on a 20Mhz avr with SBI and CBI you could get 10MHz, or 5MHz if youre using RJMPs to loop
09:06 AM polprog: whoops, sbi/cbi takes 2 cycles
09:06 AM polprog: so 5 or 2.5 MHz
09:06 AM polprog: anyway 100x faster :D
09:37 AM hetii: wtf...
09:37 AM hetii: #define streq(a,b) (strncmp(a,b,sizeof(b)-1)==0)
09:39 AM hetii: if (streq(uart_rx, "avr")){ int len = strlen(uart_rx); printf("STRLEN: %d\n", len); } ==> STRLEN: 3 when I pass "avr rainbow speed 321" into uart_rx
09:39 AM hetii: and the strlen always return amount of character that is defined in if statement
09:39 AM hetii: this is ridicules
09:43 AM rue_house: you should be using a state machine anyhow
09:49 AM HighInBC: state machines ftw!
09:50 AM kvik_: your use of sizeof in streq macro seems wrong. it will always be 1 for a char string, not the length of the string. and since you are subtracting 1 from that that will result in a 0 length comparison.
09:50 AM tpw_rules: ^
09:50 AM polprog: ^
09:50 AM tpw_rules: sizeof asks the size of the type of b
09:51 AM polprog: strlen should be used?
09:51 AM tpw_rules: which is probably a char*, and thus 2
09:51 AM rue_house: while(1) getchar();
09:51 AM tpw_rules: yes, replace sizeof with strlen
09:51 AM polprog: :D
09:51 AM tpw_rules: also if you use strlen, you do not need - 1
09:53 AM polprog: is sizeof a real function or a kind of a macro
09:53 AM kvik_: it's a compiler thing
09:53 AM kvik_: like a macro yes, but it knows about sizes of types
09:54 AM tpw_rules: it's evaluated at compile time
09:54 AM polprog: thats what i saked for, so the compiler substitutes it with a hardcoded value, right?
09:54 AM tpw_rules: yes
09:54 AM kvik_: yup
09:59 AM hetii: hmm
09:59 AM hetii: as I check its not caused by streq macro
10:00 AM polprog: streq = strings equal?
10:00 AM tpw_rules: yes it is. you're using sizeof wrong. you must replace it with strlen
10:02 AM Emil: Are calls to strlen with constant argument optimised away?
10:03 AM Emil: My intuition says no
10:03 AM hetii: Now I use such code: https://pastebin.com/M5xQ7kQx
10:04 AM hetii: as we can see strlen return number of char that is equal to second argument in if so it return length of "avr "
10:04 AM tpw_rules: it looks like it's working correctly?
10:04 AM tpw_rules: does uart_rx have all the received chars in it yet?
10:04 AM tpw_rules: or only the first four
10:05 AM hetii: hmm its filled by uart interrupt, but you might have right that its read faster then uart fill it.
10:05 AM tpw_rules: uart characters come in very slow compared to the cpu speed
10:05 AM tpw_rules: you might want to wait until you receive a newline to start parsing the string or something
10:06 AM hetii: true, true, ok I will fix that and see if this is the reason ...
10:17 AM _ami_: wow, stm32f103 works pretty well at overclocked speed 128MHz
10:17 AM _ami_: usb does not work though since it needs PLLCLK of 48MHz
10:17 AM tpw_rules: try 144?
10:17 AM tpw_rules: :D
10:18 AM tpw_rules: can it divide by 3
10:19 AM _ami_: tpw_rules: i could. but there is no prescalar for this.
10:19 AM _ami_: only 1 and 1.5 is available.
10:19 AM _ami_: :?
10:19 AM _ami_: :/
10:20 AM tpw_rules: :'(
10:42 AM Emil: https://emil.fi/jako/kuvat/2017-08-29_18-11-54_SJTrasGh.png
10:43 AM Emil: Feels good designing a box after some time
12:21 PM danst: hello, I'm trying to interact with DFPlayer using attiny, found this gist should send commands to player, but how would putchar in send_buffer() know the wiring configuration?
12:21 PM danst: https://pastebin.com/Mr4mAhJk
12:32 PM hetii: Hmm interesting, I have a variable uint16_t fan_speed; and then use fan_speed = atoi(buf); and pass to it value like -32768 and got this: avr fan speed -32768
12:33 PM hetii: but atoi return signet type
12:34 PM hetii: so when I assingn returnet sginet type to unsignet variable the result should be unsginet also, or?
12:43 PM NoHitWonder: danst just make your own putchar there, name it uart_putchar()
12:44 PM NoHitWonder: void uart_putchar(char c){ UDR = c; } that's the most basic form
12:50 PM hetii: danst, or you can redirect standard stdout handler so then you can use functions like printf and directly print result to uart
12:53 PM hetii: danst, here is how I have it: https://pastebin.com/e5M8mwK8
01:52 PM polprog: damnit, another ullet dodged
01:52 PM polprog: s/ullet/bullet/
01:52 PM polprog: always check your maximum ratings!
02:00 PM polprog: http://delphys.net/d.holmes/hardware/levelshift.html
02:59 PM Emil: NoHitWonder: noooo
02:59 PM Emil: NoHitWonder: you need to wait until previous has been sent
03:09 PM enh: Please, can somebody help me with this? What do those numbers mean?
03:09 PM enh: ENH-MBP:firmware enhering$ avr-size bin/AMGPModule.out
03:09 PM enh: text data bss dec hex filename
03:09 PM enh: 16030 6 862 16898 4202 bin/AMGPModule.out
03:09 PM enh: And supposing all my variables are in the stack, how do I know the size they take?
03:10 PM aczid: dec/hex are the total, the rest is broken down by the segments
03:10 PM polprog: i think those mean the sizes of .text, .data, .bss
03:10 PM polprog: they need to be copied from flash to the stack first
03:10 PM aczid: stack is basically the size of your ram - any heap (i.e. global) data
03:10 PM polprog: http://www.nongnu.org/avr-libc/user-manual/mem_sections.html
03:11 PM enh: Thanks, polprog and aczid.
03:11 PM polprog: basically .data = initilized vars, .bss = unitialized global and static vars
03:11 PM polprog: uninitialized*
03:11 PM polprog: :D
03:11 PM enh: hum.. ok
03:12 PM aczid: it all becomes 1 memory segment in flash on the AVR
03:12 PM aczid: this is more ELF related
03:12 PM polprog: for example, .init2, part of .data, called long before main, initilizez the stack and zero_reg
03:12 PM aczid: and global data will go into the flash and get copied in on startup
03:12 PM polprog: ^^
03:13 PM aczid: see crt1.S for your avr device
03:13 PM polprog: by the way
03:13 PM polprog: shat does that contain? why te name crt1?
03:13 PM aczid: (or was it 0)
03:13 PM aczid: c runtime
03:13 PM polprog: hmm
03:13 PM aczid: there are various levels
03:13 PM polprog: where are those located?
03:13 PM aczid: I think the compiler has name crt0
03:13 PM aczid: in the avr-libc sources
03:14 PM aczid: I've used my own crt1 for bootloader thingies
03:14 PM aczid: to reroute IVT entries into apps and such
03:14 PM enh: How do I know if I am overflowing the stack, or the RAM?
03:14 PM enh: Is there a simple way beside guessing?
03:14 PM aczid: enh: your program will crash :P
03:15 PM enh: aczid: always?
03:15 PM enh: When I get erratic behavior, it is usually related to a buffer overflow
03:15 PM aczid: if you go deeper, yes
03:15 PM aczid: try to be very careful with global data
03:15 PM enh: But this time all my buffers are secured
03:15 PM polprog: the stack gets filled "downwards" from the "top" of the ram
03:15 PM polprog: ie the stack pointer decrements when you push
03:16 PM polprog: and increments when you pop
03:16 PM aczid: if you keep track of how much global space you need, you can be assured the rest of RAM is available
03:16 PM enh: I vaguely remember htis
03:16 PM aczid: you can see exactly how much space gets allocated within a function through an assembly dump with objdump or by generating a .lst file
03:17 PM aczid: requires a bit of fluency in avr assembly though
03:17 PM enh: I aint got that fluency
03:18 PM aczid: well, practise makes perfect :)
03:18 PM polprog: indeed :)
03:18 PM enh: agreed
03:18 PM aczid: mostly you can sort of estimate how much stack space a function will use just from the C level
03:18 PM aczid: eyeball it for now, stare at it when you get problems
03:18 PM aczid: that's how you learn
03:18 PM enh: In my calculations, I 'm way below the limit
03:18 PM aczid: well you are doing calculations, that sounds good enough :)
03:19 PM aczid: in the worst case you have to fix the mistakes in it!
03:21 PM enh: But I'm getting random data transferred from one module to another. And two commits before I was getting wrong signaling in the protocol. But this protocol is tested and was working before I created a general module parent class and move it inside.
03:21 PM aczid: are you using C++? :o
03:21 PM enh: yep
03:22 PM aczid: I've never used that on an AVR except with Arduino
03:22 PM enh: all my code is oo
03:22 PM polprog: avr-libc supports c++ but you have to do some voodoo
03:22 PM enh: i need some nails, probably
03:22 PM polprog: http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplusplus
03:23 PM aczid: well if Arduino can do it, so can you :)
03:24 PM aczid: what scares me about using C++ is that you can lose track of memory consumption (and leaks!) much more easily
03:24 PM aczid: especially as a novice, no offense
03:24 PM aczid: maybe I'm just bad at C++ :)
03:24 PM enh: I agree with you.
03:26 PM aczid: but I guess it's not too different from C. you will have to check the compiler's work anyway in my experience
03:26 PM enh: I take a lot of care to avoid leaks. I'm keeping the code tight and very small. Classes are used to organize the code and keep similar funcionalty in similar classes
03:26 PM polprog: every time i am unsure about something i inspect the generated assembler
03:26 PM aczid: and see which C code results in better (fewer/faster) AVR machinecode
03:26 PM polprog: with the decompiler i have it's pure pleasure
03:27 PM polprog: syntax coloring, flowcharts, all sorta stuff
03:27 PM aczid: which decompiler is that? :)
03:27 PM enh: which one, polprog?
03:27 PM polprog: radare
03:27 PM aczid: ah yeah
03:27 PM enh: free?
03:27 PM aczid: r2 is great
03:27 PM aczid: but I'm unable to use it :D
03:27 PM aczid: yes that's free enh
03:27 PM aczid: open source even
03:27 PM aczid: and very actively worked on
03:27 PM polprog: the keybindings and commands are terrible
03:27 PM polprog: but once you learn them it's cool
03:27 PM polprog: Visual mode is cool
03:28 PM aczid: so it's a bit like Vim?
03:28 PM aczid: yeah I've played with it
03:28 PM polprog: yeah
03:28 PM aczid: going fast
03:28 PM aczid: using llvm as the glue is a great approach
03:28 PM aczid: (IIRC)
03:29 PM polprog: llvm, how does that work
03:29 PM aczid: I can't even keep up with r2 anymore, I think there was some llvm related feature
03:29 PM polprog: https://puu.sh/wcxqh/805534f2fe.png visual mode
03:29 PM enh: I 'm downloading this thing
03:29 PM enh: I hope I can use it
03:30 PM polprog: the manual is missing some part
03:30 PM aczid: there is also avr-objdump and avrdisa, I tend to just use those
03:30 PM aczid: avrdisas*
03:30 PM polprog: objdump is nice
03:30 PM polprog: simple
03:30 PM aczid: is great because it can show instruction countcycle count
03:30 PM aczid: -count
03:31 PM aczid: really useful when trying to make stuff faster
03:31 PM polprog: if radare had gui like ida it would be awesome
03:31 PM aczid: I think I saw at least one attempt at a frontend
03:32 PM aczid: btw snowman decompiler is also pretty neat (no avr tho)
03:32 PM polprog: there was a frontend but it was unavailable in the repo and the user repo version would not compile no matter what
03:34 PM aczid: yeah don't hold your breath on it being very functional given the pace of the project
03:34 PM aczid: unless they include it as a main feature
03:35 PM polprog: they have a semi working web ui
03:35 PM aczid: proxmark3 has the same problem
03:35 PM aczid: there is a gui but it lags behind quite a bit
03:48 PM aczid: polprog: https://twitter.com/b1ack0wl/status/902525610173628416/photo/1
03:48 PM polprog: lol
03:51 PM aczid: oh yeah and this one too :D https://twitter.com/silascutler/status/879137926881390592
03:52 PM polprog: https://twitter.com/malwareunicorn/status/902225127798071296
03:53 PM polprog: a crosbreed of office 2016 and a disassembler. brilliant!
03:53 PM polprog: mfw your disassembler takes 500mb of ram just to render the gui
03:55 PM polprog: mfw i can do avr-objdump | less
04:18 PM aczid: yeah I've had the displeasure of using AVR Studio 7
04:18 PM aczid: pure madness
04:19 PM Tom_L: naw that's a work of art :)
04:36 PM polprog: late night fun
04:36 PM polprog: installing netbsd with quemu on a pendrive
04:36 PM polprog: qemu*
04:38 PM dsalychev: installing netbsd is a pure fun... you'd better to find a dedicated computer for it, polprog ;)
04:39 PM polprog: i know youre using bsd dimitry :P
04:40 PM polprog: i was thinking about installing void on a pendrive
04:41 PM polprog: ehh it's stuck
04:46 PM Emil: I'm pretty good
04:46 PM Emil: https://emil.fi/jako/videot/2017-08-30_00-14-05_XRapvbrW.mp4
04:47 PM dsalychev: wha?! polprog, what did you do! It was a real secret of mine! It's a time to switch to something else... windows... maybe
04:47 PM Emil: It works on mobile, too :)
04:49 PM polprog: ok, night
04:49 PM polprog: it hangs
04:49 PM polprog: shite
04:49 PM Emil: polprog: good night
04:52 PM danst: hello
05:06 PM Lambda_Aurigae: olleh
05:55 PM danst: I'm trying to send data from attiny 2313 to dfplayer over serial
05:56 PM danst: but if I connect attiny2313 tx pin to arduino uno rx (I use it as programmer), I don't see anything in serial log
05:56 PM danst: https://pastebin.com/Y296Nt6N
06:26 PM kvik_: danst, putchar i.e. stdio won't be connected to your UART device automagically, you'll have to write your own and use that or you could hook it up to avr-libc. you'll find information about how to do that in your datasheet and avr-libc documentation
06:44 PM aczid: this page http://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html
06:45 PM aczid: has an example using the FDEV_SETUP_STREAM macro
07:44 PM danst: kvik_: hey man it works thank you
07:44 PM danst: aczid: and thank you too!
07:44 PM danst: I got some garbage finally
07:44 PM danst: on serial monitor
07:50 PM Lambda_Aurigae: now to match speeds.
07:50 PM Lambda_Aurigae: your attiny, is it running on a crystal or internal rc oscillator?
07:51 PM danst: internal
07:51 PM danst: 8Mhz
07:52 PM danst: https://pastebin.com/dS4uVcun
07:53 PM Lambda_Aurigae: aaand that's why you are getting garbage
07:53 PM danst: I've set baud rate in IDE to 9600 and connected Attiny TX to Arduino RX
07:53 PM Lambda_Aurigae: the internal oscillator is not as accurate as a crystal.
07:53 PM Lambda_Aurigae: you might have to play with ubrrl a little to get it just right.
07:54 PM Lambda_Aurigae: which is why I do autobaud adjustments when I run internal oscillator.
07:55 PM Lambda_Aurigae: send U and listen to response..if it doesn't come back then adjust and send again...keep going until I get 4 or 8 U echos in a row without adjustment then initiate regular comms.
07:55 PM Lambda_Aurigae: initiating regular comms is usually as simple as sending OK..
07:58 PM danst: how do you autobaud? I tried #include <util/setbaud.h>
07:58 PM danst: and UBRRH = UBRRH_VALUE; UBRRL = UBRRL_VALUE;
07:58 PM Lambda_Aurigae: I just told you.
07:58 PM Lambda_Aurigae: I send U...the far end echos it back.
07:59 PM Lambda_Aurigae: if it doesn't come back then I adjust UBRRL a little bit at a time,,usually up one, down one, up two, down two,,,sending a U again each adjustment.
07:59 PM Lambda_Aurigae: when the U gets echoed back then send it 4 more times to make sure it's good...if I get 4 returns then I send OK and continue on with the work.
08:00 PM Lambda_Aurigae: it's not part of libc.
08:00 PM Lambda_Aurigae: it's something I learned many years ago in the 6502 and z80 days.
08:02 PM Lambda_Aurigae: in the 8051 world I used to actually use a timer to time the ones and zeros from the U character to calculate the baud rate setting....another ancient way to autobaud.
08:10 PM kvik_: that explains why you pick U still :)
08:11 PM Lambda_Aurigae: yup.
08:11 PM Lambda_Aurigae: it just works.
08:11 PM Lambda_Aurigae: the bit pattern for it is simple and usable.
08:12 PM danst: I've changed baudrate of ArduinoISP to 9600 and set UBRRL to 0x67, because (8000000/(8*9600)) -1 = 103.
08:12 PM danst: and now getting this weird NAK symbol https://i.imgur.com/XmYx82g.png
08:13 PM Lambda_Aurigae: and what are you sending?
08:13 PM danst: U
08:13 PM danst: sometimes single U takes up two NAKs and sometimes three
08:14 PM danst: printf("U");
08:15 PM Lambda_Aurigae: looks like your baud rate isn't quite right then.
08:15 PM danst: actually each even U is 2 NAKs and odd U is 3 NAKs
08:16 PM Lambda_Aurigae: seems your baud rate is still off.
08:16 PM Lambda_Aurigae: keep adjusting.
08:18 PM Lambda_Aurigae: look at the bit pattern of NAK.
08:18 PM Lambda_Aurigae: it matches U but is cut off.
08:32 PM Lambda_Aurigae: danst, note that doing this manually will make it work for a while...as the chip heats up then the frequency will change...if the voltage changes, the frequency will change.
08:39 PM Lambda_Aurigae: and, however much I would love to sit here talking to myself some more, I've been awake for 18 hours...it's bedtime.
09:39 PM JanC is now known as Guest61806
09:39 PM JanC_ is now known as JanC
11:50 PM day_ is now known as daey