#avr Logs

May 01 2018

#avr Calendar

12:42 AM nux_ is now known as nuxil
03:00 AM JanC_ is now known as JanC
07:19 AM nuxil: good day
07:20 AM nuxil: it's so quiet in here today
09:04 AM Jartza: indeed
09:05 AM nuxil: you too. you been quiet for a long time.. what are you working on since you dont have time to irc? :)
09:36 AM polprog: im having a good timenin my summer house in deep forest in the center of poland
09:36 AM polprog: time in*
09:36 AM polprog: barely any cell coverage but irc works
09:37 AM polprog: i have to teach maths to my sis, but she doesnt want to learn
09:37 AM polprog: heh
10:03 AM Jartza: nuxil: I've been renovating the house because it's no snow anymore :)
10:04 AM Jartza: as you might know, finnish summer is short :D
10:54 AM twnqx: Jartza: wanna instead drop by here in germany and renovate? :P
11:09 AM Emil: >summer
11:09 AM Emil: it aint no bloody summer yet
11:09 AM Emil: tis spring
12:09 PM grafi_: Anyone here with silabs experience?
12:09 PM grafi_: Trying to get a Si1062 dev kit to work
12:40 PM noob12: hello
12:41 PM noob12: i'm trying to make a really small blinky program that runs on the attiny85 and i'm down to this: https://hastebin.com/gezetuxoti.sql
12:41 PM noob12: can someone gimme suggestions to go smaller?
12:42 PM noob12: i read there's a PIND with newer uCs but not sure if it's present in the t85
12:55 PM MrFahrenheit: heh, sql
12:59 PM Emil: noob12: shouldn't be
12:59 PM Emil: noob12: iirc it's just on megas
01:01 PM noob12: i'm just getting started with timers, so idk much
01:02 PM noob12: compare output mode looks promising
01:04 PM Emil: also
01:04 PM Emil: Why have you equated TCCR1 with something?
01:04 PM Emil: Isn't timer1 control still split to multiple registers
01:04 PM Emil: on attiny85
01:05 PM noob12: Emil: i am setting the prescaler to CLK/16k
01:05 PM Emil: yes but why are you naming it TCCR1
01:05 PM Emil: instead of TCCR1B
01:06 PM Emil: ah because there is just TCCR1A
01:06 PM Emil: and not B
01:06 PM Emil: carry on
01:07 PM noob12: yea was gonna mention there's only one register
01:09 PM Jartza: twnqx: probably I will visit germany this year, no idea when, though
01:42 PM noob12: hmm, down to 8; https://hastebin.com/uperanuxox
01:47 PM Emil: not too bad
01:48 PM Emil: basically one instruction is required to set the port as output and then two are required to configure TCCR0n if you want to configure them
01:48 PM Emil: that means you have 5 left to load constants and everything
01:48 PM Emil: so not too shabby at all
01:49 PM Emil: lets say there's no magic you can do with the constants so that's 2 to actually set the registers
01:49 PM Emil: so that's 3 left
01:49 PM Emil: and then you also configure OCR0B
01:49 PM Emil: so yeah that's perfectish
01:49 PM Emil: if you are doing it that way
02:16 PM Emil: Hmm
02:16 PM Emil: what
02:18 PM Emil: polprog: is there a word in music for mixing classical and electronic, like battlefield 3 music or certain songs on the seven deadly sins (https://www.youtube.com/watch?v=ipW0nHkqdcQ) ost
03:14 PM aarcane: So I'm using atmel studio and some raw avr chips on a custom board. I'd like to add optiboot support so that I can flash my chips over serial/usb. However, I can't find any documentation on how to create my production files that include both optiboot and my custom code, nor can I find any documentation on how to subsequently flash just the application portion without the boot loader while doing development
03:14 PM aarcane: does anybody have a good tutorial for doing the above?
03:15 PM Emil: ...
03:15 PM Emil: mate
03:15 PM Emil: the bootloader is just a bootloader
03:15 PM aarcane: yeah
03:15 PM Emil: you don't include or use it with your custom code
03:15 PM Emil: it's 100% separate
03:16 PM aarcane: but I still need to make a production file, and that production file needs to include both the bootloader and the release version of the code
03:16 PM aarcane: and even then, with the boot loader loaded, I need to be able to flash the chips in development
03:16 PM Emil: just include two files then
03:18 PM Emil: or you can also merge dem hexfiles
03:19 PM Emil: http://avr.2057.n7.nabble.com/linking-bootloader-and-main-application-at-once-td5830.html
03:19 PM Emil: in your production you need to do testing anyways
03:19 PM Emil: so just first flash the bootloader and then use the bootloader to flash the application logic
03:20 PM Emil: "connect usbasp, connect serial converter / whatever you use with the bootloader, press go"
03:23 PM Emil: and then in your makefile you first flash the bootloader with usbasp and then use the serial converter to upload the software
03:23 PM Emil: "avrdude -c usbasp ... && avrdude -c arduino ..."
03:24 PM aarcane: Emil, even if we do that, we still need to get the various chips flashed in the flashing facility before we ship them out. AFAIK, they still want a single production file and burn it similar to I(C)SP
03:25 PM aarcane: Emil, so I need to develop and test *both* the process of building and flashing the production file, as well as the USB/Serial update.
03:25 PM Tom_L: won't an elf file hold all that information?
03:25 PM Tom_L: i've never tried it mind you..
03:26 PM Emil: https://www.avrfreaks.net/forum/how-program-application-and-bootloader-same-time
03:26 PM twnqx: if you construct one with extra segments and a linker script that oots bootloader and main prog in its places..
03:26 PM aarcane: Tom_L, atmel studio doesn't have an option to choose both an application binary and a boot loader binary
03:26 PM twnqx: so? use real tools not convenient toys
03:26 PM Emil: aarcane: then skip the retarded IDE and use avr-gcc and avr-objcopy directly :D
03:26 PM Tom_L: you'd think with all that bloat it would do something...
03:26 PM Emil: Tom_L: heh, true
03:26 PM Rez: you should be able to burn the whole thing at once. Also, for mass production, wtf would you use atmel studio to program chips?
03:27 PM twnqx: his problem is creating the whole thing
03:27 PM Emil: yeah
03:27 PM Rez: can't you just concatenate the hex files or something similar?
03:27 PM Emil: Rez: already mentioned above
03:28 PM aarcane: Rez, afaik, the point of atmel studio & elf files is to be able to ship a single ELF file off to a chip manufacturing facility and get a tray full of chips with your firmware on them ready to solder. That's why I'm using atmel studio, because I'm writing for atmel chips to be flashed by an atmel affiliate before shipping to a factory...
03:29 PM Emil: aarcane: no
03:29 PM Emil: aarcane: you
03:29 PM Emil: don't
03:29 PM Emil: need
03:29 PM Emil: atmel studio for this
03:29 PM Emil: atmel studio is just bloat over the (real) tools it uses underneath
03:29 PM twnqx: atmelstudio is a way to hide an obsolete toolchain from the end user, at the cost of flexibility
03:29 PM Emil: namely avr-gcc, avr-objcopy and binutils-avr
03:30 PM Rez is now known as LoRez
03:30 PM Emil: twnqx: now now, you can have an up to date toolchain with atmel studio also, surely
03:30 PM aarcane: okay
03:30 PM Emil: aarcane: https://emil.fi/avr
03:30 PM aarcane: Emil, I get that. I'm explaining my rationale for being in atmel studio
03:31 PM Emil: aarcane: you have no rationale
03:31 PM Emil: atmel studio is just bloat over the tools mentioned above
03:31 PM Emil: this problem has _nothing_ to do with atmel studio
03:31 PM twnqx: where your image comes from doesn't matter
03:31 PM twnqx: they'll want an image, not a bunch of project bloat
03:32 PM Emil: aarcane: not to mention, if you are paying atmel to flash your chips, just send them an email with "hey were are doing an order from you for chips, what's the way to correctly merge the bootloader and application code?"
03:32 PM Emil: and then they'll either tell you what the way to achieve that is or tell you to just send both and they'll do it for you
03:34 PM aarcane: Emil, good idea. I'm in software development, not PR or purchasing, so I don't usually think of such things
03:34 PM Emil: aarcane: if you don't believe me you can believe the documentation they have on their site
03:34 PM Emil: http://www.microchip.com/avr-support/avr-and-arm-toolchains-(c-compilers)
03:35 PM Emil: aarcane: if you do send that email and get a response, do share it here also
03:36 PM Emil: so next time we can just say "these steps"
03:36 PM Emil: aarcane: anycase your elf-file needs to contain correct fuses and the rest of the code, which is the merged bootloader and application code
03:37 PM Emil: don't forget them
03:37 PM Emil: ohshit
03:37 PM Emil: http://ww1.microchip.com/downloads/en/DeviceDoc/Frequently-Asked-Questions-4.9.3.26.txt
03:37 PM Emil: god tier format
03:37 PM Emil: _nice_
03:38 PM aarcane: Emil, fuses was easy. I had no issues burning fuses. though avrdude doesn't yet (As of last time I read the docs), know how to read fuses from elves.
03:39 PM Emil: aarcane: no, I meant when you build your elf-file, don't forget to include the fuses
03:39 PM Emil: (if they really just take a single file)
03:40 PM Emil: also fuses works with hexfiles
03:41 PM Emil: also god damn it why can't we have the same libc-greatness on arms as we have with avrs
03:42 PM Emil: anycase
03:42 PM Emil: good night
03:42 PM aarcane: Emil, I was thinking somewhat the opposite, I wish I had the hardware and feature support in avr that ARM seems to have. I had to write an async serial transceiver to work with the serial async code since there are like... 0 examples of it anywhere.
03:42 PM Emil: hope you get it done
03:42 PM Emil: aarcane: lol
03:43 PM Emil: aarcane: you cant use google if you say that
03:43 PM aarcane: Emil, I found some bad examples, but nothing with the ability to receive an entire message, then pass it off to the application to process while anothe rmessage may or may not be coming in or going out
03:44 PM Emil: aarcane: sounds like you shouldn't be developing low level applications then
03:44 PM Emil: aarcane: avrs are extremely simple
03:44 PM Emil: and the examples and instructions online go over exactly what you need
03:44 PM aarcane: Emil, I can't control when the user will click a button... but with some study of the state machine, I was able to write a proper async driver for the serial chips.
03:44 PM Emil: if you want to run an rtos then goto freertos.org
03:44 PM Emil: aarcane: good
03:46 PM aarcane: Emil, literally stores a long string, then calls a function to store the string, unlink it from the string array, and set a flag for main to process the string at its leisure, so that the relevant interrupt can return quickly. It's a nightmare that nobody's bothered writing it before.
03:46 PM Emil: ...
03:46 PM antto: le wut
03:46 PM antto: strings?
03:47 PM Emil: aarcane: inb4 he's using c++ and the String type
03:47 PM Emil: heeeeellloooo perf death
03:47 PM Emil: haven't seen you in a long time
03:47 PM aarcane: lol, char* and a 1 pass json parser >,.,<
03:47 PM Emil: >json
03:47 PM Emil: >on avr
03:47 PM Emil: is this how-to-kys-101?
03:48 PM antto: json, sounds like "u going to Jail, SON."
03:48 PM aarcane: lol
03:48 PM aarcane: it was a bad solution
03:48 PM aarcane: but it was a fast solution under a time crunch
03:48 PM aarcane: anyway, avr at 8mhz can handle json well enough
03:48 PM antto: i use C++ on avr ;P~
03:48 PM Emil: ^daily reminded not to let people who don't know things make low level decision
03:48 PM Emil: s
03:49 PM Emil: aarcane: the speed is not the issue
03:49 PM Emil: it's your memory usage
03:49 PM antto: aarcane you're not processing anything inside the actual interrupt, are you?
03:49 PM aarcane: Emil, yeah, that was a consideration
03:49 PM aarcane: antto, nope. just the string length and checking to see if it's end of buffer or termination character
03:50 PM antto: uhm
03:50 PM antto: do you have another buffer?
03:50 PM Emil: aarcane: here's a helpful tip: you are in a resource constrained environment but you control the device entirely
03:51 PM Emil: to avoid buffer overruns/corrupted data/whatever you define a solution
03:51 PM Emil: either you parse fast enough (usually you copy the data to another buffer for processing if you get data all the time)
03:51 PM Emil: or you message back when you can accept moar dta
03:52 PM antto: aka software flow control (afaik)
03:52 PM aarcane: antto, multiple buffers, and the driver gracefully does nothing discarding input if they're all full. I figure out the maximum stack depth, maximum application RAM usage, and then max message size, add a small padding, then figure out how many buffers and of what size I need
03:52 PM Emil: also describing what you said above as "nightmare"
03:52 PM Emil: sounds like 100% trouble
03:52 PM Emil: since it's not
03:52 PM Emil: not even remotely
03:53 PM Emil: inb4 serial data is also handled as 9600
03:53 PM Emil: baud
03:54 PM antto: i tried 500kbps on the xmega yesterday
03:54 PM Emil: at 9600 baud serial you have some 8333 cycles per byte
03:54 PM Emil: on 8MHz
03:54 PM aarcane: Emil, started at 9600, but an 8mhz atmega can do a lot faster :P
03:55 PM Emil: aarcane: 250k or 500k and remember to set the double speed bit
03:55 PM antto: noooooooo
03:55 PM antto: why double speed >:(
03:55 PM Emil: in these speeds it's still more efficient to use async data but you are losing quite many cycles
03:56 PM Emil: antto: because it has a lower error rate than full sampling .D
03:56 PM Emil: antto: instead of 16 samples it's 8 samples
03:56 PM antto: lower error rate?!
03:56 PM Emil: pert bit
03:56 PM Emil: (baud)
03:56 PM antto: it lets more errors IN undetected!
03:56 PM antto: imma slap u!
03:56 PM Emil: mate
03:56 PM antto: wash yer dirty liar mouf
03:57 PM Emil: the hardware serial peripheral only detects errors on start and stop bits
03:57 PM aarcane: Emil, the reason it was a nightmare was because I had to develop it without jtag or proper debug options, because I had no say in the board design phase. I've convinced the board designers to add jtag instead of i(c)sp headers next time.
03:57 PM Emil: aarcane: you don't need jtag
03:57 PM Emil: isp is better faster easier
03:58 PM antto: use xmega
03:58 PM Emil: if your application code approaches such complexity that you can't debug the system without jtag it's time to refactor
03:58 PM Emil: on avr
03:58 PM antto: iirc, PDI includes debugging features
03:58 PM Emil: antto: PDI is only for newfag-systems :D
03:58 PM Emil: antto: you can just drop that (c)
03:58 PM antto: and is only 2 pins
03:59 PM antto: wut?
03:59 PM Emil: in-system-programming vs in-circuit serial programming
03:59 PM Emil: isp is the correct term
03:59 PM Emil: oh
03:59 PM Emil: also
03:59 PM Emil: yeah
03:59 PM Emil: aarcane: *
03:59 PM Emil: instead of antto
04:00 PM Emil: anycase
04:00 PM Emil: like I said
04:00 PM Emil: good night
04:01 PM antto: no
04:01 PM antto: get back here Emil
04:01 PM aarcane: lol
11:29 PM day__ is now known as day