#avr Logs

Apr 14 2021

05:26 AM Miyu is now known as hackkitten
05:26 PM Kabriel: Is there a way to alias the usart data register using libavr? I would like a way to reference the register (say UDR0 or UDR1) via another variable taht is set at runtime.
05:27 PM exp: a pointer?
05:28 PM Kabriel: UDR0 (e.g. for atmega2560) is a macro defined as _SFR_MEM8(0xC8), where _SFR_MEM8 is defined as _SFR_MEM8(mem_addr) (mem_addr)
05:28 PM exp: iirc that macro just adds an offset to that address
05:28 PM Kabriel: I don't actually know what that means -- that is "(mem_addr)", which I assume might be assembly?
05:29 PM exp: it's just a macro with a parameter, i assume on atmega2560 there's no offset? best to check the datasheet
05:29 PM exp: but either way, they're just addresses in memory AFAIK
05:29 PM exp: you shouldn't require anything particularly special to point to it
05:30 PM Kabriel: so &UDR0 or I have to actually define myvar = 0xC8 ?
05:30 PM exp: I don't have code using the USART on my chip but I can tell you i use &PORTA, &DDRA etc to refer to pin registers
05:30 PM exp: and all is good
05:30 PM cehteh: why do you want to do that?
05:31 PM exp: ^ it's a good question to ask
05:31 PM cehteh: just use the macros unless you understand what you trying to do
05:31 PM exp: cehteh: well I assume they're making a generic 'receive from usart' function
05:31 PM cehteh: i once considered to remove code duplicaiton by making drivers for uart/timers more generic .. that would be a point
05:32 PM exp: and so they'll need to take a parameter for the data register
05:32 PM exp: good to ask though, XY problems are real.
05:33 PM Kabriel: Correct. I would like to separate my serial command logic from the actual device code.
05:33 PM cehteh: but well you can as well just wrap that in small function uint8_t get_uart_data(uint8_t uart_nr) { switch uart_nr { case 0: return UDR0; case 1: returen UDR1; ...
05:33 PM exp: you should think carefully about the semantics of your design when doing that
05:34 PM exp: it's often much too easy to design an abstraction that doesn't match the underlying behaviour
05:34 PM cehteh: the compiler can inline and optimize that pretty well
05:34 PM cehteh: most likely better than anything you come up with
05:34 PM exp: better? that seems unlikely
05:35 PM exp: the alternative is a literal after all
05:35 PM Kabriel: At the moment, the data coming into the USART is written to a buffer via an interrupt (e.g. ISR(USART0_RX_vect)).
05:35 PM cehteh: at last with LTO i am pretty sure it can do that better
05:35 PM cehteh: yes
05:36 PM exp: Kabriel: if you're planning on making complex function calls from an ISR you may wish to reconsider or at least, explore the consequences, it's impossible to know whether that's appropriate
05:36 PM exp: but it's generally discouraged
05:36 PM Kabriel: Really, this has to do with the transmit, which is also buffered and also utilizing an interrupt. However, to trigger the write on the buffer, the first character is written to UDR0, and this is embedded in the serial command code.
05:37 PM cehteh: light/inline function calls are ok ... but dont nest/not loop, dont pass more than a few parameters
05:37 PM exp: Kabriel: that sounds like it might be a reasonable candidate use case, but the 'buffered using an interrupt' part makes my hair raise somewhat
05:39 PM cehteh: i have small circular buffers that get fed from interrupts (as small as only a few bytes) and then the main loop handles these and copies data over into 'real' buffers like linebuffer for inputs and so on
05:39 PM Kabriel: There are two nested if statements each with a couple of assignments to a global variable.
05:39 PM exp: as a complete aside, boy this shortage is starting to bite
05:39 PM exp: I bought out the end of the UK supply of AT90USB646s for the next 8 months or something stupid
05:39 PM cehteh: that has a little performance overhead but makes its far less timing contrained
05:39 PM exp: (a few dozen, lol)
05:39 PM Kabriel: Just fyi; I am modifying existing code (trying to clean it up). The existing code "works" so to speak.
05:40 PM exp: cehteh: that's not far off how i do it, currently i don't have a functional event loop that can be safely interrupted, so I just set flags and then use the main loop to do that copying
05:40 PM cehteh: assignments to global variables from ISR's can be fishy
05:40 PM exp: you need to mark them as volatile to prevent compiler magic, but that should be fine
05:40 PM Kabriel: Hmm. What is the correct way to get input / send output over USART then?
05:40 PM cehteh: exp: for TX i have something nicer .. binary tagged queue
05:41 PM cehteh: bascially compression
05:41 PM exp: Kabriel: ISRs should set flags in memory or add events to a queue, an event loop or pseudothread or similar should then send
05:41 PM exp: cehteh: i'm just using LUFA's simple ringbuffer for now, there's not enough time in my day to write the code I need
05:41 PM cehteh: volatile comes with some perfomance penality and volatile does not gurantee atomic access
05:41 PM exp: i don't know if i'd call it a penalty as such, it just disables some optimisations
05:42 PM exp: and i think on AVR there's no 1 byte tearing
05:42 PM exp: so you're probably grand
05:42 PM cehteh: you have to make them volatile yes .. but that might be not enough
05:42 PM exp: but yes it's not as simple as just referring to it
05:42 PM exp: i am surprised avr-gcc hasn't been augmented to recognise the ISR use case, but I've read GCC code before and I cried
05:43 PM cehteh: anyway back to the original problem try as i saied to make a get_udr(uartnumber) function ... see how that coptimizes and performs
05:43 PM cehteh: maybe look at the generated asm, when that doesnt do the trick you can start over and try some more complex stunt
05:44 PM cehteh: but i'd bet it will be good
05:44 PM Kabriel: So, if I understand what you are saying, it would be better to set a flag in the ISR(RX) that says need to read a byte and then actually read the byte somewhere else in the code, rather than in the interrupt.
05:44 PM exp: for this case I typically just have an enum and an array and define each as `[VALX] = &REGX`
05:44 PM exp: Kabriel: correct, as ISRs by default disable interrupts on entry
05:46 PM Kabriel: Are there any good examples or books about best practices in laying out code?
05:46 PM exp: many, but it's much like joining a cult
05:46 PM exp: there are lots of paths out there, and everyone insists theirs is the right one
05:46 PM exp: I don't feel confident in recommending anything as I'm a newcomer to writing C for MCUs
05:47 PM Kabriel: New to MCUs as well, or did you use a different programming language?
05:52 PM exp: Kabriel: sorry I was AFK, somewhat new to MCUs but I've been around the industry for a while
05:52 PM exp: just new to being the guy in charge
05:53 PM exp: I don't recommend it :-)
05:54 PM Kabriel: Ha! MCU programming or being in charge!
05:54 PM nohit: both
05:54 PM exp: :D
05:54 PM exp: the worst thing about MCU programming is probably C tbqh
05:55 PM exp: the codebase I'm working on is not particularly large or complex but there are already a multitude of macro hacks and horrible things
05:56 PM cehteh: enum/array/xmacro may work too .. but simple switch function would be optimally inlines with weigthing of the register useage and code size around/calling it
06:01 PM Kabriel: Why would it be fishy to have a global variable assignment in an ISR? Even a flag will have to be somehow external to the ISR macro itself.
06:01 PM exp: Kabriel: compilers will optimise memory to register copies and because an ISR may occur at any point, the compiler optimisation may not re-copy the memory upon a second access, even though an ISR may have run
06:02 PM exp: so you must tell the compiler the variable is `volatile`, ie it may change between subsequent reads, and must always be re-copied
06:02 PM exp: it's actually even more complex i think as modern compilers even do it in register colouring? but i am not a compiler engineer.
06:05 PM cehteh: Kabriel: i meant extensive use of it, aks 'know what you are doing'
06:05 PM cehteh: see above ... needs to be volatile when it is shared with non isr code and may need some more protection when its more than a single byte to make access atomic
06:06 PM exp: oh yes that's another good point, that ISRs may occur inbetween multi byte reads
06:06 PM exp: even inside another ISR if it's NOBLOCK or whatever
06:07 PM cehteh: then when accessing it copying to a non volatile variable is sometimes/often a good idea, possibly by blocking it form modification, as in turning the ISR off for the copy
06:07 PM cehteh: volatile uint32_t isr_shared; // gets written in a isr
06:08 PM cehteh: myfunc(){ cli(); uint32_t copy=isr_shared; sei(); work on copy here; }
06:08 PM cehteh: ans possibly not cli/sei but only the interrupt in question
06:09 PM exp: cehteh: forgive me if i'm wrong, but the atomic block stuff in avr-libc does that also doesn't it?
06:09 PM cehteh: yes
06:09 PM cehteh: but atomic bloc does cli/sei .. while you possibly need only to disable one single interrupt, not all
06:10 PM exp: I've not considered doing that to be honest, but there are circumstances in which it's appropriate
06:10 PM cehteh: i meant contrast to the antipattern:
06:10 PM navnavnavnavnav: Hi all!
06:11 PM cehteh: myfunc() { ATOMIC_BLOCK{ do all the work here } }
06:11 PM nohit: hello
06:11 PM exp: hi (?:nav)+
06:12 PM navnavnavnavnav: May I ask, how many of you use Linux for embedded development with AVRs?
06:12 PM cehteh: so 3 important parts: 1. access need to make atomic, 2. better do a copy unless your 'work' is really minimal and you access the shared var only once, 3. dont block more interrupts than needed and not longer than required
06:12 PM exp: ←
06:12 PM cehteh: o/
06:13 PM exp: cehteh: and the larger point: understand the state machine you are operating on, and ensure you cannot skip a step by accident
06:13 PM exp: a bunch of ISRs that bounce back and forth writing to globals becomes impossible to reason about
06:13 PM cehteh: unrelated but that doo
06:13 PM cehteh: too
06:13 PM exp: but ISRs that change flags which are serviced by a main loop, pseudothreads, or an event queue
06:13 PM exp: those are tractable
06:14 PM navnavnavnavnav: I only ask because I've been working on something for the last two years, and I've just released the first beta version (like, 20 mins ago). I'd really like to get some feedback on it
06:14 PM LeoNerd: Prettymuch the only thing my ISRs ever do is set a "runnable" flag on an associated task in my scheduler array, which then gets to wake up from sleep, run it, and clear the flag again
06:14 PM exp: (would you call them coroutines? I haven't tried one of the mini RTOSs on my chips yet)
06:16 PM exp: navnavnavnavnav: what is it you've released?
06:16 PM cehteh: my mµos schedules functioncalls, something inbetween, no coroutines, only one stack, no threads
06:16 PM exp: cehteh: task timeouts? preemption?
06:16 PM cehteh: nope
06:16 PM Kabriel: LeoNerd: even on an usart rx interrupt?
06:16 PM cehteh: cooperative
06:16 PM exp: cehteh: that's what I'm aiming at achieving next, then adding the timeouts
06:16 PM cehteh: i dont want
06:16 PM cehteh: i could add watchdogs for that
06:16 PM LeoNerd: Kabriel: Ah sometimes i'll fetch the pending byte or somesuch.. or things like pinchange interrupts I might analyse the input pins and work out which pin and dispatch some task or other..
06:17 PM LeoNerd: But usually that's about all
06:17 PM exp: I have a complex I²C bus which as you can imagine is prone to locking up
06:17 PM navnavnavnavnav: I don't want to just spam the link, so let me know if you'd be interested in testing a debug interface for Linux. It currently supports most EDBG based debug tools, including the MPLAB snap. And I'm going to start working on support for the PICkit 4 soon.
06:17 PM cehteh: but ideally the functions scheduled are small do their job, by perhaps schedule continutations and are done
06:17 PM exp: the current library code I don't believe has any timeout protection on reads
06:17 PM cehteh: the scheduler can be called recursively it can yield and wait doing other jobs, but its pretty strict ordered
06:18 PM exp: cehteh: recursive main loops: *chef's kiss*
06:18 PM nohit: navnavnavnavnav: sounds good
06:18 PM exp: the sign of good engineering IMO
06:18 PM Kabriel: navnavnavnavnav: for what is worth, I use Linux.
06:18 PM cehteh: it comes with some limit so oyu cant fill up the stack
06:18 PM Kabriel: Thanks for the help; I'm off for a break.
06:18 PM exp: navnavnavnavnav: not on the chips I use AFAIK, but I will bookmark :)
06:19 PM exp: cehteh: smrt, I'm not even sure how to reasonably guard against that
06:19 PM navnavnavnavnav: I'm very new to this IRC thing, sorry, I have no idea to reply to people individually
06:19 PM navnavnavnavnav: I'm just going to dump the link, I hope you don't mind
06:19 PM exp: do you just set a low, static limit, or do you sample the remaining RAM after building?
06:19 PM navnavnavnavnav: https://bloom.oscillate.io/
06:19 PM cehteh: exp: its just a counter, when yielding too deep yield does nothing, waiting raises an error
06:19 PM exp: navnavnavnavnav: there's no protocol for it, irc is just text, usually people prefix their lines with the user's name to trigger highlighting
06:20 PM navnavnavnavnav: exp ah, cool! Thanks!
06:20 PM exp: cehteh: seems reasonable, i can't even imagine how you'd begin to do that dynamically
06:20 PM cehteh: exp: but i also added a stack checker, which helps in debugging
06:20 PM exp: the most annoying thing for me is that I never have a chance to spin a dev board
06:20 PM exp: everything is always final with JTAG disabled
06:21 PM exp: the next big project I'm doing I have enough external ADCs that I can finally keep JTAG
06:21 PM exp: so I'm looking forward to that
06:21 PM cehteh: well i havent worked in that for quite some time now, currently rather working on some 'normal' programming and learning rust :)
06:22 PM exp: I'm trying to move our team to Go, slowly, Rust is nice but overkill for our needs
06:22 PM exp: we currently have an eclectic mix of C/Perl/Python/JS, none of it particularly well made
06:22 PM cehteh: depends on what you are doing but go has a lot shortcomings
06:23 PM exp: it does and it doesn't, restrictive languages are a blessing when you have an international team with differnet skillsets
06:23 PM exp: I do not want people writing extremely fancy register manipulation code in our core stack ;-)
06:23 PM exp: the beauty of Go is its absurd simplicity, to me it is everything Python claims to be
06:23 PM cehteh: not that, its more about where it fails to be simple and just beeing blatantly wrong :D
06:24 PM exp: I can't think of any area that it's blatently wrong, just blatently restricted
06:24 PM exp: passing a Go struct to C for example
06:25 PM cehteh: moment .. searching for the link
06:25 PM exp: np, I just finished work, it is 00:13 for me, lol
06:26 PM exp: navnavnavnavnav: Bloom looks quite useful, and quite attractive
06:27 PM exp: your use of standard interfaces on both sides is really nice, proper plug and play :-)
06:27 PM cehteh: 1:13 here :D
06:28 PM exp: I am playing the current game of 'out of stock bingo'
06:28 PM navnavnavnavnav: exp Thanks! I'm really glad you think so!
06:28 PM exp: navnavnavnavnav: PHP though? ;-)
06:29 PM cehteh: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride
06:29 PM cehteh: before moving to go read that, maybe its not relevant to you *cough* ... but you should know it at least
06:29 PM navnavnavnavnav: exp ha, that's only for some build scripts. PHP can be nice, sometimes :D
06:31 PM exp: cehteh: yes I remember reading this article, but it's a bad take, it's not possible to have that complexity with that simplicit
06:31 PM exp: as Rust has found by still having major releases to go, while Go has barely changed since release
06:32 PM cehteh: i know people wo use go sucessfully .. but in a very limited scope, server backends on linux, thats where it shines
06:33 PM exp: cehteh: the argument being made here is ultimately that languages should embrace the complexity of the environments they run in
06:33 PM cehteh: you just need to be aware of its pitfalls and limitations before its to late and discover that
06:34 PM cehteh: well for myself i can say that i have enough struggles with rust as well, firguring things out correctly isnt always easy
06:34 PM exp: but this is not trivial, see the current state of everything from Rust to Swift to .NET to C++
06:34 PM exp: exactly, Go's approach is a different philosophy
06:34 PM cehteh: for scripting i like lua a lot because of its simplicity
06:34 PM exp: heh, arrays start at 0 thank you ;-)
06:34 PM cehteh: but its ecosystem is unfortunally not so good
06:35 PM exp: but seriously, Go has lots of friction at its edges, but the result is that when you read code it's almost always extremely simple, straightforward and understandable
06:35 PM cehteh: there are certainly things that could be better done in lua
06:35 PM exp: that carries so much more value to me than platform independence or 'proper' typing, etc
06:35 PM cehteh: heh
06:36 PM cehteh: funnily after a lot headdache i end up with some simple and pretty rust code as well
06:36 PM cehteh: but the way there is hard for a beginner :)
06:36 PM exp: it is, and AFAIK there are still major Rust changes to come
06:36 PM exp: since MIR I think it was, I haven't had time to dive in
06:36 PM exp: so many years out of date now I am
06:37 PM cehteh: nah its rather incremental improvements no breaking changes to my knowlege
06:37 PM cehteh: i ithnk it lacks some things/egonomics still but it improves
06:38 PM exp: I hope so, it's unfortunate it has become a bit of a meme
06:42 PM exp: as a complete aside, the LM5170-Q1 seems pretty damn neat
06:43 PM exp: I need to handle ~70v at one side of a device, and class 8 POE at the other
06:43 PM exp: ideally bidirectionally
06:43 PM exp: if anyone else has used a candidate, please let me know
06:44 PM nohit: navnavnavnavnav: i shared it on #avrs
06:45 PM navnavnavnavnav: Thanks nohit!
06:46 PM nohit: np
06:51 PM navnavnavnavnav: I was going to share it on avrfreaks but I felt it would be better to have just a few people use it first, in case I've missed anything super obvious
07:20 PM vmt: so wait what's the problem that this bloom thing solves
09:19 PM specing_ is now known as specing
09:36 PM joebobjoe: hi