#avr Logs

Oct 01 2019

01:23 AM rue_bed: iirc there is an sprintf for avr out there
01:28 AM cehteh: beware that the avr-libc one is slightly limited
03:44 AM Miyu is now known as hackkitten
06:06 AM very_sneaky: hi all, i'm new to AVR programming; I'm trying to program a gesture sensor using TWI atm. The ATmega32A datasheet provides some sample assembly code that makes reference to the keyword `START`. Wondering if this has already been defined somewhere, or if it's a placeholder. Specifically, the code is `cpi r16, START`. Anybody able to shed some light for me?
06:07 AM LeoNerd: If you're new to AVR I'd suggest not starting right down at lowlevel assembly
06:07 AM LeoNerd: Work in C
06:07 AM very_sneaky: LeoNerd, cheers, it's for a university assignment so assembly is a requirement
06:08 AM LeoNerd: Ah... in at the deep end .. :/
06:08 AM LeoNerd: Good luck
06:09 AM LeoNerd: I've done lots of AVR for years and even then I've only ever done assembly code once, for doing a cycle-perfect timed custom WS2812 driver
06:10 AM very_sneaky: haha thanks. Yeah this is my first crack at assembly. Gotta say I'm finding it illuminating wrt code efficiency and the impact of compiler settings in c
06:12 AM LeoNerd: It can be a fun thing to try sometime, but usually best when you're familiar with the system and writing C code for it, etc...
06:13 AM very_sneaky: I think the lecturer has the opposite perspective. I think he's very familiar with the assembly side of things, and feels it provides a more accurate representation of what the hardware is doing
06:13 AM very_sneaky: I'm pretty comfortable with C outside of AVR programming though
06:14 AM LeoNerd: I find I have a good feel for the device by thinking about what settings I poke into what hardware registers
06:14 AM LeoNerd: I don't have to think about loading a constant into r17 and then the address into the r21/r22 pair to then STS it into the register concerned
06:15 AM LeoNerd: TWI0.CTRLA |= TWI_ENABLE_bm; will suffice for that
06:15 AM very_sneaky: yeah I'd imagine that there's good reason C/C++ are becoming more dominant in embedded systems, at least that's my understanding
06:16 AM very_sneaky: still, i can see the educational value in assembly :)
06:16 AM LeoNerd: Eh.. I have a very dim view of "educators" who start arbitrarily in the middle there
06:16 AM LeoNerd: Why do assembly when you could do hex-encoded machine code directly? Just type numbers
06:16 AM LeoNerd: Or why stop there when you can consider the actual logic gates, transistors, ... silicon doping patterns on the chip itself
06:17 AM very_sneaky: to be fair we're learning the C side in parallel
06:17 AM LeoNerd: Mmm
06:18 AM very_sneaky: regardless, i'm a CS major not EE. I took this course specifically to get more familiar with assembly as a springboard to reverse engineering haha
06:28 AM djph: LeoNerd: what's the "middle" now?
06:28 AM LeoNerd: assembly
06:28 AM djph: ah
06:29 AM LeoNerd: My thinking: start teaching at the highest. most abstracted level - i.e. maybe C code with some nice helper HAL around, .. and if people are curious about how things work inside they can inspect lower and lower as they go
06:29 AM djph: haven't even started looking at that enigma yet -- learning just enough of it right now to get a handle, but yeah; mostly C
06:30 AM djph: LeoNerd: so basically say a flow of "Arduino" -> C -> ASM ?
06:30 AM LeoNerd: Yah.. I like to think of Arduino like Lego
06:30 AM LeoNerd: It's great for teaching people basics of how to stick things together, as a good learning tool
06:33 AM djph: TBH, I kinda hate it. Mostly because "holy crap, this is a lot easier than I thought"
06:33 AM djph: "ugh, why'd I hold myself back so long"
06:33 AM LeoNerd: Ohsure feel free to look downwards when you want; just -start- from the top so you know what's there and what exists...
06:34 AM djph: LeoNerd: Oh, no - I mean I hate it in the sense of "This is easy, why'd I hold myself back until Arduino came around?"
06:35 AM LeoNerd: Mm.. yeah..
06:38 AM very_sneaky: i think i worked out my issue. looks like the data sheet is just abbreviating `(1<<TWINT) | (1<<TWSTA) | (1<<TWEN)` to `START`
06:39 AM LeoNerd: Ah, likely
06:39 AM LeoNerd: There might be a #define or similar somewhere because that's a fairly likely combination to use often
06:39 AM djph: what datasheet is that?
06:39 AM very_sneaky: ATmega32A
06:39 AM LeoNerd: Oooldchip
06:40 AM djph: ^^
06:40 AM very_sneaky: LeoNerd, one thing i'm confused about that perhaps you can shed light on - where are TWEN, TWSTA, TWINT defined? in the assembler itself?
06:40 AM LeoNerd: I don't think I'll be making anything new on any of those ones now; the new tiny 1-series, or mega 0-series, seem to be the way forward
06:40 AM djph: kinda surprised a current class isn't using a 328
06:40 AM djph: but meh
06:40 AM LeoNerd: Hoping we get a mega-1 sometime soon :)
06:40 AM LeoNerd: very_sneaky: no idea. I really just write C code, so those all come in from <avr/io.h>
06:40 AM djph: very_sneaky: they're "defined" in the avr-libc headers
06:41 AM LeoNerd: Possibly the assembler has some way to get those too
06:41 AM djph: avr/io.h has some chip-specific includes as well
06:41 AM very_sneaky: i can see their values in the data sheet and i know i can use them as the aliases they are, but yeah - assembler libraries are a bit of a grey area to me
06:41 AM very_sneaky: djph, yeah, i see the avr/io.h import in c, but how does htat work in assembly?
06:41 AM very_sneaky: avr-libc headers, is that used by the assembler?
06:41 AM LeoNerd: Yeah; no idea. The only assembly code I tend to have is little blobs of asm() inline in C, if it's really needed. But as I said, only time I've ever -actually- used that for real was my WS2812 driver
06:41 AM very_sneaky: presumably that's part of the toolchain
06:42 AM very_sneaky: LeoNerd, yep fair enough, thanks anyway
06:43 AM LeoNerd: Hrm.. there aren't any ATmega 0-series chips with multiple I²C or SPI ports. The -only- multi-port chip I know of is the 328PB
06:43 AM djph: very_sneaky: I think it's the same syntax -- #include <def.inc>
06:43 AM LeoNerd: Even the hugeness of the mega4809 still only has one of each
06:43 AM LeoNerd: yet 4 USARTs
06:43 AM djph: LeoNerd: yeah, that has multiple USARTs but ...
06:44 AM very_sneaky: djph, hmm, yeah i've imported other libraries that way, but never for the names of registers or io ports, i.e. PORTA, PORTB etc
06:45 AM LeoNerd: It'd odd; I don't see that the mega 0-series are really a whole lot bigger than the tiny 0- or 1-series. Other than having more IO pins and hence more PORTs, they're really basically the same
06:45 AM djph: might be some bit of the toolchain that you set elsewhere in the IDE then? Not 100% sure, haven't really delved that deeply into assembly.
06:50 AM very_sneaky: djph, yeah you could be right, the ide might be doing stuff for me
06:50 AM very_sneaky: especially come compile time
06:50 AM LeoNerd: Heh...
06:50 AM very_sneaky: i try to avoid them mostly for exactly this reason; processes are opaque. unfortunately i discovered early on, being able to simulate the hardware is pretty invaluable
06:51 AM LeoNerd: See, this is part of what I mean... you're diving into the middle of the difficult bit by writing assembly code, but have an IDE that just does stuff for compiling behind your baack
06:51 AM LeoNerd: It's a very pick-and-mix selection
06:51 AM very_sneaky: yeah, i'm sure there are a bunch of factors that lead to that contradiction lol
06:51 AM djph: yeah, simulation is nice ... now if there only was a good emulator
06:52 AM very_sneaky: question - is avr/embedded development generally, typically conducted from a windows environment?
06:52 AM very_sneaky: is linux popular for this kind of dev?
06:52 AM very_sneaky: slash are there the sufficient toolchains on linux
06:53 AM LeoNerd: I do all my work from Linux
06:53 AM very_sneaky: heh
06:53 AM LeoNerd: make + avr-gcc + avrdude/avr-updi-tools
06:53 AM very_sneaky: there's avr dude for linux?
06:53 AM very_sneaky: oof, what am i doing
06:53 AM LeoNerd: Hah
06:53 AM very_sneaky: that was the reason i was told i "had" to use windows
06:53 AM LeoNerd: avrdude /is/ a Linux program.. well, general POSIX really..
06:53 AM LeoNerd: Wha?
06:54 AM very_sneaky: yeah, i just think the staff weren't interested in supporting multiple environments now that you say that
06:54 AM LeoNerd: I mean, that's *a* reason sure
06:54 AM LeoNerd: But overall don't forget that eduacational establishments are very different places to The Real World
06:55 AM very_sneaky: yeah for sure
06:55 AM LeoNerd: For an educational task they might set restrictions like language/OS choice, in order that they can support and evaluate what you're doing
06:55 AM very_sneaky: i would have preferred to use a unix /like environment
06:55 AM LeoNerd: Out here in the real world nobody cares how I make a product, just what the product does by the end. So I use whatever I find easiest/fastest to get to that point
06:56 AM very_sneaky: but i was getting back to that's probably the reason why they use an IDE in this class - all the pre-req programming subjects teach it in the context of visual studio
06:56 AM very_sneaky: since the class isn't necessarily about how to program without an idea or learn how to build software, it's a contradiction that exists
06:56 AM very_sneaky: without an ide*
06:57 AM very_sneaky: anyway
06:59 AM djph: LeoNerd: speaking of your products, any news on those UPDI programmers?
07:23 AM vmt: how's atmel studio nowadays, are they still developing it after the merge?
07:25 AM djph: I think Microchip is in the process of moving everything into MPLAB-X
07:29 AM LeoNerd: djph: What sort of news?
07:29 AM djph: LeoNerd: as in "can I get my hands on one, or are they still sold out"?
07:30 AM LeoNerd: Oh I've three currently... more one the way
07:31 AM vmt: updi programmers? they are quite trivial to build, no?
07:31 AM LeoNerd: vmt: My fancier 12V ones
07:31 AM vmt: what's the catch?
07:31 AM vmt: hard reset?
07:31 AM LeoNerd: They do 12V enable pulse so you can set the pin in RESET or GPIO mode
07:32 AM vmt: yeah, figured
07:32 AM djph: LeoNerd: sweet, shutup and take my money :)
07:33 AM djph: oh, damn, I forgot you were in the UK :( bleh
07:34 AM LeoNerd: Hmm?
07:38 AM djph: exorbitant shipping charges. What else can I blow money on, hmmm ...
07:40 AM davor_ is now known as davor
07:42 AM LeoNerd: Ah; yeah it's not cheap to post things to other countries when you don't have gov't-subsidised shipping
07:44 AM djph: I mean, you should, it's not like I'm in France or something.
07:53 AM vmt: well, who wants to be in france anyway
08:16 AM nohit: if its EE, its best to start with assembly. we used C with avrs on the 3rd year
08:17 AM nohit: or 2nd, cant remember. definately not the first year
08:21 AM Steffanx: Did you use tarduino too?
08:22 AM LeoNerd: Legouino
08:23 AM nohit: of course not
08:23 AM nohit: i dont think it was even invented back then
08:34 AM djph: when was "back then" ?
08:45 AM nohit: 2006
09:04 AM djph: they were out by then, or very close to -- I remember hearing about them early on in college, but I don't thnk they really took off til '08 or '09
09:28 AM polprog: tarduino - an arduino library for .tar files
09:52 AM vmt: name it *uino buy a .io domain, write the firmware in rust and sprinkle in a healthy dose of buzzwords
09:52 AM vmt: next killer app
09:54 AM LeoNerd: Make sure to talk about IoT
09:55 AM vmt: and add a RESTful api and write an electron gui application
09:55 AM vmt: make sure to post it to github and hire a graphic designer to make you a slick logo
09:55 AM vmt: did i mean github? i meant gitlab. get with the times
09:56 AM vmt: did i say, rather.
09:57 AM vmt: + add in a bundled terminal emulator color scheme and some sick ricing to go with that
10:59 AM djph: polprog: I might just write that now.
10:59 AM djph: polprog: and then just ship everything off to devnull as a service for further processing.
11:03 AM polprog: write what
11:04 AM djph: polprog: tarduino - an arduino library for tarballs.
11:04 AM polprog: ah that
11:04 AM polprog: lol
12:41 PM vmt: i think we need a cryptoduino
12:42 PM cehteh: bloatduino
01:49 PM Kliment: Is it possible to transmit continuously with the 0-series SPI peripheral?
01:49 PM Kliment: I get large gaps between bytes
02:00 PM LeoNerd: Should be possible yes, if you queue up the next byte reader
02:00 PM LeoNerd: *ready
02:02 PM LeoNerd: I forget quite how the buffering works on the SPI master
02:08 PM Kliment: LeoNerd: Got it going, but the timing is still off - the last bit in each byte is a bit longer
02:09 PM Kliment: LeoNerd: I'm trying to cheat the SPI peripheral into driving a WS2812 LED strip
02:09 PM Kliment: LeoNerd: And it's ALMOST there
02:15 PM LeoNerd: Hah.. oh right... Yeah the bit-per-byte over SPI trick
02:52 PM Kliment: LeoNerd: it's not fast enough for that sadly
02:52 PM Kliment: LeoNerd: I was aiming for 4 bits per bit
02:52 PM Kliment: LeoNerd: It's JUST within the timing requirements
02:53 PM Kliment: LeoNerd: But sadly I can't seem to send bytes back to back - the last bit is always longer
02:53 PM Kliment: So I'll just have to do it in asm I guess
02:54 PM Kliment: and bitbang
02:57 PM Fuchikoma: Yay assembly
03:39 PM LeoNerd: I've never seen a /good/ WS2812 driver that wasn't hand-written assembly
05:10 PM joakimk: I'm trying to configure Timer1 of an ATMEGA16 to blink LEDs at PORTB at some frequency. I'm already using Timer0 for communicating with an ESP8266. I've tried to paste what I believe to be the relevant parts of the code here: https://pastebin.com/NjhEeG6B
05:11 PM joakimk: So, the "setupTimerISR()" method is causing the AVR to crash (reset)
05:13 PM joakimk: What I want to achieve, is for the interrupt handler (ISR (TIMER1_OVF_vect)) to toggle the LEDs at some user-controllable rate/frequency
05:14 PM joakimk: As I understand it, I should be able to set the max value of the compare, by changing (increasing or reducing) the compare value in OCR1A
05:20 PM joakimk29: sorry -- was disconnected
07:13 PM julius: i found puts in the avr libc - which does: Write the string pointed to by str, and a trailing newline character, to stdout. but how do you save a string that differs in value each time. do you just create a char bux[MAX] and hope they all fit? isnt there some dynamic way to create a str?
07:14 PM julius: basically i would like to read from adc0, which can be 0..1023 and write that via usart
07:15 PM julius: whats the default value in: char buf[MAX] right after inizialization, are the empty places 0?
07:20 PM julius: kinda later :( lets hope my bouncer catches the answer
07:40 PM davor_ is now known as davor
07:48 PM cehteh: julius: your responsibility to initialize the buffer correctly, and reserve it with the right (worst case) size
07:49 PM cehteh: you may as well look into printf
07:58 PM vmt: kids, dynamic allocation is a hell of a drug. stay away.
07:58 PM vmt: dynamic allocation is opium for the masses.
08:02 PM vmt: julius: and no, you don't "hope they all fit". you could just send the value directly as BE/LE through usart. or if you want to convert it to characters then you clearly see how big your buffer needs to be
08:04 PM vmt: rule #1 of avrs is you do not talk... i mean use *alloc
08:05 PM vmt: i saw some guy the other day in youtube making a donkey kong clone in c. his first priority was to make a dynamic allocation string library. that's about the time i had enough
08:07 PM cehteh: dynamoc memoy allocated on stack is reasonable. when you know how to and what not to do (recursion)
08:09 PM vmt: recursion itself is dubious
08:09 PM vmt: avoid is possible
08:10 PM vmt: wait, i read that wrong.
08:13 PM vmt: by "dynamic stack allocation" i assume you mean vlas/alloca, both of which i think are also on the no-go list
08:14 PM cehteh: i never use them, but alloca in should work if used wisely, it just increments the stackpointer, no fragmentation no change of ordering
08:14 PM vmt: yeah alright, i wasn't exactly aware of how either are implemented, i guess it's compiler specific
08:15 PM cehteh: no much reason for using it
08:16 PM vmt: i just think the need for either arises from the fact when you are trying to solve your problem for the most generic case -first
08:16 PM cehteh: a) you want your program to work in all cases, including worst case
08:16 PM cehteh: b) it should be deterministic and reliable
08:17 PM vmt: those contradict.
08:17 PM vmt: when you *need* to use alloca/VLAs determinism flies out the window
08:17 PM vmt: you should know your worst case rather than let a hack like alloca figure it out for you
08:17 PM cehteh: which results in -> just define buffers the worst case size, or of thats not doable then error out in and handle that error
08:18 PM vmt: amen to that
08:18 PM cehteh: yeah thats an argument against alloca
08:18 PM vmt: alloca is a fucking hack and i think only gcc implements it...?
08:18 PM cehteh: i could only imagione rather esoteric situations where alloca would have some benefit
08:19 PM vmt: i mean libc
08:19 PM cehteh: like function a calls function b ... each need some memory, and conincidentaly it is guranteed that if a needs little memory, then b needs more and vice versa
08:20 PM cehteh: well so far in theory, in practice i have no idea where it really matters
08:24 PM vmt: in any case. it's good practice for people to learn program things with rather strict limitations, can be thought of a learning experience.
08:24 PM vmt: though amongst people who write c, it seems to be some kind of a coming-of-age ritual to write a string library
08:25 PM vmt: p.s. all of them are horseshit.
08:27 PM djph: vmt: strings don't exist.
08:28 PM vmt: djph: this is highly dependent on which definition of string you're using
08:30 PM djph: vmt: any one that involves the non-existent "string" type.
08:30 PM vmt: and what's the context?
08:32 PM djph: vmt: youre the one who said something about "string libraries" (pfffft)
08:35 PM vmt: djph: if the context is that of c, then yes strings exist
08:39 PM djph: vmt: uh, not in c ... closest thing is an array of char
08:40 PM vmt: strings are very much a thing in c.
08:44 PM djph: you can certainly use arrays of char to told "strings" ... but there is no string type in the language.
08:45 PM vmt: string is not a type. it is a concept.
08:46 PM vmt: to paraphrase, in c a sequence of bytes terminated by 0 is considered a *string*
08:46 PM djph: ...
08:46 PM vmt: this is both reflected in string literals as well as in the standard library functions
08:47 PM djph: *sigh* ...
08:47 PM vmt: no sighs necessary
11:44 PM davor_ is now known as davor