#avr Logs
Mar 21 2019
#avr Calendar
12:46 AM ville: rue_mohr: haven't tried it yet. was getting late last night so had to go to bed. hopefully have time this evening
12:50 AM rue_mohr: I can give you the lines I have
12:50 AM ville: rue_mohr: sure i'm interested
12:50 AM rue_mohr: you just want to flash a hex file?
12:50 AM day_ is now known as day
12:58 AM rue_mohr: ville,
12:59 AM ville: rue_mohr: right now i am kind of unclear what i want exactly in very detailed terms. i want to upload my program to an arduino micro to put it in very broad terms. this is my first go at anything like this
12:59 AM rue_mohr: ah
12:59 AM rue_mohr: you wrote the software in C, yes?
12:59 AM rue_mohr: is the chip atmega328?
01:00 AM ville: rue_mohr: sure. writing the program it self is fine. that part i am fairly alright with. it's the how to interact with these avr mcus. it's an atmega32u4 i believe.
01:00 AM rue_mohr: atmega32U4
01:00 AM rue_mohr: ok, let me see
01:01 AM rue_mohr: were you able to get it to compile?
01:01 AM rue_mohr: idea, are you familiar with a makefile?
01:01 AM rue_mohr: avrdude -c avrisp2 -P usb -p m32 -e -U flash:w:$(PRG).hex
01:02 AM rue_mohr: there is the makefile line to program a m32
01:02 AM rue_mohr: so
01:02 AM rue_mohr: avrdude -c avrisp2 -P usb -p m32u4 -e -U flash:w:main.hex
01:02 AM rue_mohr: thats a good bet for your chip
01:02 AM rue_mohr: ville, ?
01:03 AM ville: yes i can build the elf file fine. i've fair bit of programming experience on desktop/server architectures. it's once it gets to the avr mcu specific parts of the process that is not quite clear yet.
01:03 AM rue_mohr: http://paste.debian.net/1074028/
01:03 AM rue_mohr: there is my makefile for m32
01:03 AM rue_mohr: make; make usbinstall
01:04 AM rue_mohr: ok
01:04 AM rue_mohr: after the elf, you use objdump to make the .hex
01:04 AM rue_mohr: then avrdude to send it to the avr
01:04 AM rue_mohr: in that makefile, you want to change atmega32 to atmega32u4 and m32 to m32u4
01:05 AM ville: yes right now i've my setup produce a flash and eeprom .hex files
01:05 AM rue_mohr: avrdude -c avrisp2 -P usb -p m32u4 -e -U flash:w:main.hex
01:07 AM ville: is the translation from something like "atmega32u4" to "m32u4" necessary for the -p argument? think i saw someone pass "atmega8" in their makefile
01:08 AM rue_mohr: take a look at my makefile
01:08 AM rue_mohr: you just need to add the u4 to the part numbers
01:08 AM rue_mohr: http://paste.debian.net/1074028/
01:11 AM ville: i've looked at the output from "avrdude -p ?" and looked up that atmega32u4 corresponds with m32u4. while the man page seems to sugget it is necessary, i saw someone pass in the mcu name "untranslated" and made me wonder if it's optional these days for the -p
01:12 AM ville: an yes i am looking at your makefile, thanks for the reference
01:12 AM rue_mohr: avrdude should be using m32u4
07:38 AM ville: anyone with experience trying to track relative position based on readings from accelerometer+gyroscope+magnetometer? i was wondering what kind of accuracy could this approach expected to deliver with off-the shelf cheap hardware such as https://www.adafruit.com/product/3463
07:42 AM Emil: Consider joining #avrs (we have Finns there)
07:43 AM polprog: probably not much accuracy
07:48 AM Igloo: ville: If local absolute position is any use to you, then the DWM1000 looked like the most plausible reasonably priced option when I looked recently. I haven't actually tried using it, though
07:48 AM ville: the idea was for tracking head position, so off-by-centimeter scale would be alright after ~5 minutes of sitting and leaning/rotating the head
07:54 AM Igloo: Searching for "arduino head tracking" finds some things, e.g. https://www.instructables.com/id/Gyroscopic-Arduino-Head-Tracking-Unit/
07:55 AM Igloo: More at https://duckduckgo.com/?q=arduino+head+tracking&t=hv&ia=web
08:04 AM ville: yeah i've the rotation part figured out, i'd like to incorporate some crude translation part as well
08:11 AM timemage: ville, https://youtu.be/_q_8d0E3tDk?t=70
08:13 AM timemage: ville, later around 4min 15sec he mentions what's probably the more immediate objection, that it looks like he didn't zero it. that it wouldn't matter in the end.
08:15 AM cehteh: ville: you need pretty good hardware and low noise to get accurate location, and a good fusion algorithm
08:16 AM timemage: some sort of closed loop in any case.
08:16 AM cehteh: things become much eaiser when you can 'recalibrate' the position sometimes and have more sensors
08:18 AM cehteh: the better lagorithms are too much for an avr
08:53 AM Bushman: hi everyone.
08:54 AM Bushman: noob question (cause i failed miserably with googling it):
08:54 AM Bushman: in C, is there any way to indicate which part of code is for which hardware?
08:54 AM Bushman: i have a working code for mega16 but i need to port it to mega328
08:55 AM ville: cehteh: i can pretty much invoke "this is new world 0,0,0" at any time. obviosuly nicer to use if it hasn't have to be too frequent
08:55 AM Bushman: but i'd like to leave an option to go back
08:55 AM Bushman: without the need for separate versions for each µC
08:57 AM ville: Bushman: not entirely unusual would be to use the c preprocessor to determine what gets passed into the compiler.
08:58 AM Bushman: oh, ok. got any example i could learn from?
09:00 AM polprog: Bushman: not that i know of but take a look at ifdefs in io.h header from libc-avr
09:01 AM Bushman: ville: based on what you said i was able to find this:
09:01 AM Bushman: https://www.microchip.com/webdoc/AVRLibcReferenceManual/using_tools_1using_avr_gcc_mach_opt.html
09:01 AM Bushman: but it's a bit overwhelming
09:02 AM polprog: https://github.com/vancegroup-mirrors/avr-libc/blob/master/avr-libc/include/avr/io.h
09:02 AM Bushman: polprog: ok, i will
09:06 AM Bushman: polprog: will it take only one line? or how do i provide more lines for each #if defined (_MCU_TYPE_)
09:09 AM Bushman: also, i assume the (_MCU_TYPE_) like (__AVR_ATmega328P__) is what "MCU=atmega328p" stand for in makefile?
09:09 AM rue_mohr: morning
09:10 AM Bushman: mornign rue mohr
09:10 AM rue_mohr: Bushman, so, you need to specify different flags to gcc
09:10 AM Bushman: more or less
09:10 AM Bushman: i'm doing some things with interrupts
09:10 AM rue_mohr: if you include <avr/io.h> it'll automatically include the right headers
09:10 AM Bushman: but as we all know the interrupts are different
09:11 AM rue_mohr: based on the makefile flags
09:11 AM rue_mohr: if your porting code between the sereies, you need to manually recode for the different registers
09:12 AM Bushman: i know. but i would like to leave the previous registers in, in case i want to switch hardware
09:12 AM rue_mohr: oh, you want to #ifdef you code to death
09:12 AM rue_mohr: make it all read-only
09:12 AM Bushman: lol
09:12 AM rue_mohr: er, hah, write-only./..
09:12 AM Bushman: XD
09:12 AM Bushman: why would you say so? :P
09:13 AM rue_mohr: _I_
09:13 AM rue_mohr: put all the cpu specific stuffs in library files, and write the library files for each different controller
09:13 AM ville: Bushman: it's fairly easy to follow what's happenin if your ifdef is at include-specific-file granularity, and those files have implementations of the functions for each one
09:14 AM Bushman: i see
09:14 AM rue_mohr: yea, cause all ifdef code thats 3 levels deep is totally readable
09:14 AM ville: Bushman: it's rather difficult to follow what's happenining if your ifdef is at line-level granularity. that is you have single function that has many sections that are ifdeffed
09:14 AM rue_mohr: just look at how easily maintained any gnu source code is
09:15 AM rue_mohr: I'm gonna write a program that takes two source files, for two different programs, and mashes them togethor with #ifdef
09:15 AM polprog: yeah
09:15 AM polprog: Bushman: as for logc in ifdefs, you can use && and || iirc just like in C code
09:15 AM rue_mohr: so you can have the source code for 8 programs in one file and specify which program you want to compile with a #define
09:16 AM polprog: wasnt the c(++) preprocessor turing complete
09:16 AM polprog: or was it templates in Cpp
09:16 AM Bushman: lol
09:17 AM rue_mohr: just seperate out the functionality and write a versoion of the library for each platform
09:17 AM Bushman: ok, that gives me some insight.
09:17 AM rue_mohr: I suspect its just a few things, and its just a few platforms (namely 2, and 2)
09:17 AM Bushman: but still, how do i put bunch of code in one #if defined ?
09:18 AM rue_mohr: look at gnu source code for a program, like nedit
09:18 AM Bushman: do i bracket in like a function(){ some code;} ?
09:18 AM rue_mohr: you will see #ifdef ALL OVER THE PLACE
09:18 AM Bushman: heh
09:18 AM polprog: no, really
09:18 AM rue_mohr: to the point its impossable to read or maintain the code
09:18 AM rue_mohr: and its not even a bad one
09:18 AM polprog: #ifdef agagaggagaga
09:18 AM polprog: (some code)
09:19 AM polprog: #endif
09:19 AM polprog: just look it up
09:19 AM Bushman: oh, ok.
09:19 AM rue_mohr: when EVERY SECOND GOD DAMNED LINE has an #ifdef or #ifndef around it, it makes the code horrid
09:19 AM rue_mohr: which is what happens
09:19 AM ville: polprog: i believe both are turing-complete in as much as you can count something turing-complete that has some kind of limits like running out of memory
09:19 AM rue_mohr: to maintain the code, you need to filter it thru preprocessors
09:20 AM Bushman: i promise i won't create such mostrocity
09:20 AM rue_mohr: If thats true, it'll be the first time its ever happened
09:21 AM rue_mohr: again, look at any gnu software
09:21 AM cehteh: ville: simple are complementaty filters, also google for 'madgewick'
09:21 AM Bushman: i just need to initialize some timers for some time-critical stuff. I'm sure i can move it to it's own file with bunch of #ifs doing the same thing just for different hardware
09:22 AM rue_mohr: actually, if you look at most of the arduino library code you see the same thing
09:22 AM rue_mohr: write-only code
09:22 AM cehteh: when you can reset or recalibrate it to absolute mesurements (prolly slow approximation, thats what complementary filter does) then it can stay simple and wont drift too much
09:22 AM rue_mohr: thats why most bugs aren't fixed properly
09:23 AM ville: cehteh: yeah i've the madgewick paper for the rotational part
09:23 AM rue_mohr: and you see so many bandaids over things
09:23 AM Bushman: should be easy to read if it's just one function with 2 or 3 sections soing the same thing
09:23 AM polprog: write only code. i like it
09:23 AM Bushman: *doing
09:23 AM cehteh: but you have to understand the properties and errors for each sensor you use, gyros drift, accelerometers as supectible of vibrations, mag is slow and inaccurate
09:26 AM ville: cehteh: also have https://faculty.nps.edu/yun/pub/ICRA2007%20paper.pdf this on my reading list
09:27 AM cehteh: yep nice
09:28 AM cehteh: i favor simple complementary fitlers, when they work for the task. they are so nice and really easy to implement
09:29 AM cehteh: its often shown that kalman filters are not much better, despite much more complex
09:52 AM ville: cehteh: i know who to pester then when i run into problems!
10:17 AM Bushman: i get a warning for this code:
10:17 AM Bushman: https://pastebin.com/VtUpCxeE
10:18 AM Bushman: the warning is:
10:18 AM Bushman: main.c:165:4: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]
10:18 AM Bushman: p = &str;
10:18 AM Bushman: can anyone help me understand what i'm doing wrong and how the hell did that work in the past?
10:34 AM timemage: Bushman, usually you don't point a character pointer at an int. if anything a pointer to unsigned char. what were you hoping would happen?
10:34 AM timemage: Bushman, lol, nevermind, i didn't even see your global there.
10:34 AM timemage: Bushman, p = str; &str is actually a pointer to an array of char, which is technically a different thing.
10:37 AM timemage: Bushman, so you want char *p = str; &str (if you ever used it) would be used like: char (*p)[16] = &str; you almost never see explicit use of pointers to arrays.
10:42 AM Bushman: timemage: thank you for your insight.
10:43 AM Bushman: timemage: as i mentioned before i'm a bit n00bish. i don't code a lot. this is one of my older codes so i don't really know what i was trying to do back then :P
10:44 AM timemage: Bushman, yeah, it looks a little weird in general. but i usually try to answer questions directly, if i can =)
10:44 AM Bushman: i was probably shitting all over my memory space and was extremely lucky the code didn't crash every time it run this function XD
10:48 AM Bushman: the whole function is a weird thing that converts a variable 'h' height in meters into a string of characters that are to be put into the str[], to be sent as a morse code via interrupts
10:49 AM Bushman: it's a bit convoluted and for sure way overcomplicated than it needs to but it worked for me years ago :P
10:50 AM Bushman: right now i want to make it work again and later i will be changing some hardware to simplify it...
10:51 AM Bushman: cause right now i'm using software to modulate an external radio module, because it was AM and i needed FM
10:51 AM Bushman: new FM TRX modules are shipping from china but it will take some time before they get here
10:53 AM Bushman: oh boy... now i have somethign wrong with makefile cause it spits out warnings it's not linking
11:26 AM Bushman: i need your help yet again, guys.
11:27 AM Bushman: i've tried to google for what it could mean or what a working makefile should look like but i failed miserably
11:27 AM Bushman: this is the output of the make all
11:27 AM Bushman: https://pastebin.com/7uyK8yAX
11:28 AM Bushman: as you can see i get bunch of "linker input file unused because linking not done"
11:29 AM Bushman: again, this WAS a working makefile i just digged up from oblivion which is my projects folder
11:29 AM Bushman: it worked in the past, i don't understand why it's not working now.
11:30 AM Bushman: this is the actuall makefile:
11:30 AM Bushman: https://pastebin.com/pbG39uX6
11:30 AM Bushman: it was stolen from some other project and slightly modified by me.
11:30 AM Bushman: and it was working. now it's not. and i don't know why.
11:47 AM timemage: Bushman, uhh, your .c files are still .c files right?
11:48 AM timemage: Bushman, also, /home/bushman/Projects/avr/Variometer as a parameter by itself?
11:48 AM timemage: Bushman, did you mean -I/home/bushm..... ?
11:49 AM timemage: Bushman, yeah, that seems to be the problem.
11:51 AM Bushman: i don't know what i mean :D
11:51 AM timemage: Bushman, e.g.: avr-gcc -c . results in avr-gcc: warning: .: linker input file unused because linking not done
11:52 AM Bushman: https://miro.medium.com/max/754/1*snTXFElFuQLSFDnvZKJ6IA.png
11:52 AM timemage: Bushman, line 27 of your makfile
11:52 AM timemage: Bushman, or alternately line 56. one of these would need to include -I
11:53 AM Bushman: let me try with 27
11:54 AM Bushman: ok, no warnings
11:54 AM timemage: Bushman, right, so avr-gcc -I. /home/bushman/Projects/avr/Variometer -g -mmcu=atmega328p ..... becomes avr-gcc -I. -I/home/bushman/Projects/avr/Variometer -g -mmcu=atmega328p .....
11:55 AM Bushman: yup
11:55 AM Bushman: my bad. i must have messed it up when changing to a new location
11:55 AM Bushman: it's time to flash the thing and see what'll explode
11:55 AM Bushman: :D
02:56 PM kllp: i got 2 arduino pro micros but i can only flash one (using an external programmer and avrdude in the commandline). how to start debugging? how to tell the atmega32u4 is alive? (i have access to an oscilloscope)
02:58 PM kllp: i checked that the pins properly connect to the atmega32u4. i flash using MOSI, MISO, SCK and RST pin (and of course VCC and GND)
02:59 PM LeoNerd: I seem to recall the 32U4 has some extra fun involving a BOOT enable pin or button, or something...
03:00 PM kllp: yeah RST and GND need to be shorted twice
03:02 PM kllp: on the working one i can set fuses without this procedure, the other one reports 'invalid device signature'
03:03 PM LeoNerd: What signature does it read? Is it all-bits-high/low, or is it something different?
03:03 PM LeoNerd: I sometimes get random read errors if VCC isn't stable enough, turned out I had a bad USB cable to my programmer
03:04 PM kllp: i can verify that my setup is working because one controller works fine
03:05 PM LeoNerd: Yeah sometimes for me, the board would work fine and only fail at the programmer stage
03:05 PM kllp: most of the time i get all 0
03:07 PM kllp: how do i check if i need an external crystal?
03:10 PM kllp: does it report the fuse settings on any pin on boot?
06:24 PM gsi__ is now known as gsi_