#avr Logs

Oct 04 2019

01:12 AM kini is now known as fs
09:54 AM julius: this works: for (char *p = buf; *p; p++) { but shouldnt the stop condition not be: *p != '\0' ?
09:56 AM Fuchikoma: Well "0" logically equates to false, so if *p == '\0' then that's the same as saying if *p == false
09:56 AM Fuchikoma: So as long as *p is anything but a null character the loop will continue
09:56 AM julius: allright
09:58 AM julius: c will probably optimize that check anyway?
09:58 AM Fuchikoma: That seems pretty optimal
10:15 AM _abc_: Anyone using Atmega808 etc? low end?
10:16 AM Fuchikoma: I've been working on a project around the 814
10:16 AM _abc_: Does the standard toolchain support it as is?
10:16 AM Fuchikoma: The only special thing I needed was a UPDI programmer
10:17 AM _abc_: Which one do you have?
10:17 AM Fuchikoma: I cobbled one out of an Arduino Pro Mini (with USB-UART bridge)
10:18 AM Fuchikoma: There are other methods but just using an arduino + formware someone wrote was the most straightforward for me at the time
10:18 AM Fuchikoma: firmware*
10:22 AM _abc_: mega328pb etc also needs UPDI? Or standard SPI?
10:23 AM Fuchikoma: Pretty sure that series is still SPI
10:36 AM djph: 328PB is still SPI
10:40 AM julius: is there a debugging environment for the avr on linux that you use?
10:44 AM djph: nope
10:45 AM Fuchikoma: I use Windows so no. Also I've never actually used an in-circuit debugger
10:45 AM djph: but I do have a USB cable and programmer ...
10:56 AM julius: yes, but thats all i got. never used any debugging technic with avrs
10:58 AM Fuchikoma: I suppose it's something I should try but meh
10:59 AM djph: I'm playing around with unit testing (but this means compiling for x86_64, not avr) ... it's going pretty "meh"
11:11 AM cehteh: djph: depends on your code. writing portable and dont do hardware related things
11:14 AM djph: cehteh: yeah, I'm plodding through this ... the whole thing is starting to come off as "these guys want to sell training classes"
11:29 AM _abc_: I also do code proto on linux in C then port it to avr.
11:29 AM _abc_: simulavr and simavr are 2 options, they are way out of date and a bit clunky. Used them just a little.
11:30 AM _abc_: In the past I spent time improving gpsim with patches, I did a lot of PIC coding in the past.
12:17 PM Kliment: Fuchikoma: I have a dedicated UPDI programmer/debugger now
12:17 PM Kliment: Fuchikoma: got an xplained board, lifted the MCU, added a resistor
12:18 PM Kliment: Fuchikoma: I put in a jumper for powering from USB, it works great
12:21 PM Fuchikoma: heh
12:27 PM Kliment: Fuchikoma: WAY cheaper than the official debugger, which I also have
12:28 PM Fuchikoma: Is there anything special about it that lets it work as a debugger?
12:29 PM Fuchikoma: Also the main uC is a 328p isn't it? Did you load custom firmware or anything?
02:47 PM vmt: julius: i take it, works now?
04:23 PM julius: vmt, yes the thermometer works since you fixed it yesterday
04:24 PM julius: at least i hope so, need to add floating point division to get the .5 of 21.5 displayed
04:27 PM cehteh: no you dont
04:28 PM cehteh: dont use floats on avr's and moreover floats are not about fractional parts in base 10
04:28 PM cehteh: you can do that all in integer
04:28 PM cehteh: the sensor gives you an integer already
04:31 PM cehteh: convert that to 1/10 °C or whatever precision you need (215 for 21.5°C) ... then integer=temp/10; fractional=temp-integer; print integer "." fractional
04:31 PM cehteh: (printf or whatever you use for printing)
04:33 PM cehteh: that'll be more precise than using floats AND shitloads less expensive to calculate
04:34 PM vmt: it is, however the cycle itself is slow as shit and if you only need it as a thermometer it's not that big of a deal to do sw fp
04:34 PM * cehteh has some plans to put a '.' inbetween printing integers in his own ouput library that will make such even simpler
04:35 PM vmt: the cycle freq is something like .25 hz
04:35 PM vmt: well even less than that, really
04:35 PM cehteh: yeah speed isnt much matter here, but in principel you may need more space later and you want to display exact results
04:36 PM vmt: sure
04:37 PM vmt: and if space is of any concern i'd recommend against printf
04:37 PM cehteh: hence i left that open in the example
04:37 PM vmt: yeah
04:38 PM cehteh: i am using my own lib for that, not format strings but all supported types have their own functions output_uint8 (uint_t number); ... etc
04:40 PM cehteh: actually that even writes into a tagged/compressed queue such saving a lot ram
04:40 PM vmt: well it's trivial to implement your own stringifier
04:40 PM julius: djph, i couldnt live without unit testing in java/python
04:40 PM cehteh: (on the cost of the slightly more complex queue implementation)
04:40 PM julius: just a easy way to a make sure new code doesnt interfear in odd ways with old
04:41 PM vmt: java and python make me a very sad panda bear:'(
04:41 PM cehteh: thats not soo easy with avr's because you have hard times simulating side effects and hardware
04:41 PM vmt: i'm not even sure which is shittier, it seems like they've got a competition going on which one ends up being more crap
04:41 PM cehteh: but on the other hand usually avr programs are simple enough that you can debug them
04:42 PM cehteh: just use git and commit frequently
04:42 PM vmt: solution is so do your unit testing in the target device!
04:43 PM vmt: *UNIT TESTING*
04:43 PM vmt: solution is to*
04:44 PM cehteh: yes, but only as much it makes sense, some things can be tested in portable C code, some things only can be reasonable tested when integrated
04:44 PM vmt: unit testing in target is fucking ridiculous, lol
04:44 PM vmt: unit testing is a thing that doesn't really mix in to the mcu world.
04:45 PM cehteh: well sometiems it does, when you implement some specific algorithem for some task for example
04:45 PM cehteh: bit as soon it comes into timing/hardware/interrupt crap its no fun to be considered
04:45 PM vmt: of course you test the critical parts, such as an algorithm unknown to you
04:46 PM vmt: or even known, but no, you don't do any silly fucking unit testing which says you test every god damn function you write
04:46 PM cehteh: well first you need to test the correctness of the algorithm
04:46 PM vmt: sure
04:46 PM cehteh: actually first on the host/normal pc .. when you written it properly portable
04:46 PM vmt: yes i agree completely
04:46 PM cehteh: but perhaps on the mcu too just to make sure you dont overseen anything
04:47 PM cehteh: still thats hardly worth to be automated
04:47 PM vmt: yes, but this isn't the what /unit testing/ is about
04:47 PM vmt: yes, exactly
04:47 PM vmt: -the
04:47 PM vmt: my sleep deprivation deepens
04:47 PM cehteh: you do that once when you really need it and it helps, then the job is done and you dont touch that working code again
04:47 PM vmt: yes
04:50 PM vmt: unit testing also raises the threshold for refactoring too much
04:50 PM cehteh: nah
04:50 PM vmt: not talking about avr programs which are extremely simple
04:51 PM vmt: compared to e.g. x86 codebases
09:01 PM rue_mohr: --
10:04 PM davor_ is now known as davor
11:45 PM day__ is now known as day