#avr Logs

Sep 29 2021

03:44 AM jancoow: Ugh, currently working on a atsaml mcu; seems that my uart is sometimes missing a character..
03:52 AM jancoow: i'm using the ASF layer and interrupts on usart; I'm afraid my interrupt routine is to slow
03:52 AM jancoow: using freertos, this is mainly happening when some other heavy piece of code is claiming a lot of resources.. any ideas how I could I improve this? Will using DMA help?
03:53 AM jancoow: I didn't write this code myself, but the way it works now, every driver implementation using uart has to first process the incoming byte (in the onItemReceiveCompleted() function) before it listens to new bytes.. I guess this is not ideal:
03:54 AM jancoow: https://es.jancokock.me/1fe2a/
03:58 AM exp: yeah I would think you should split that up, hard to know how long jobs take, but ideally as soon as there's an interrupt you should prefix any job queue with a read job that moves it into some more permanent memory
03:58 AM exp: but, i am not an expert, i don't write much C++ or use SAM devices, lol
03:59 AM jancoow: jobs \should\ not take long ye
04:00 AM exp: the alternate answer i could give is: missing characters is an intrinsic risk of processor that can do multiple jobs at once, redesign your signalling so you send back ACKs or otherwise acknowledge each character
04:00 AM exp: ie reimplement TCP, not a fun prospect
04:01 AM jancoow: just checking and we are using the same principle with i2c/spi . However, those write to a buffer (because you know exactly how many bytes to expect when reading) and as soon as the number of bytes are available, the onItemReceiveCompleted() function will be called
04:01 AM exp: you could redesign your uart protocol to start with a number of bytes
04:01 AM jancoow: exp ye the driver should always check checksum etc but missing a character should simply not happen I think
04:01 AM exp: or include the byte count as a nibble etc
04:02 AM exp: jancoow: it's intrinsic in this style of software development
04:02 AM exp: unless you have a thread that can listen in more or less realtime
04:02 AM exp: then you're going to dance around this issue one way or another
04:02 AM exp: a robust protocol would mean you could drop as many characters as you like
04:02 AM exp: just two answers to the same problem ;)
04:03 AM jancoow: i'm just tackling the base of the problem; not the protocols on top of it which are using this uart "driver"
04:03 AM exp: sure, i don't know which are feasible, just saying those are the two options as i see it
04:04 AM exp: if you can't reengineer the protocol, make sure you're using sort of preemptible event queue
04:04 AM exp: if not, implement what parts of TCP you care about
04:04 AM jancoow: I was thinking of putting characters in a FIFO buffer
04:05 AM jancoow: and let a freertos task handle this queue and sending the jobs
04:05 AM exp: i've not had chance to move on to freertos yet but i know it has some support for this
04:05 AM exp: ie kernel preemption
04:05 AM jancoow: what is that?
04:06 AM exp: the ability to park an executing routine and its stack, and switch to a new routine, think how ISRs work
04:06 AM exp: except that ISRs have a compiler added preamble etc for handling this
04:06 AM jancoow: ohh ye
04:06 AM exp: your biggest problem will be locking or similar, you could consider a bip buffer i think the term is
04:07 AM jancoow: what if, I move the usart_read_job above my character handler function? What if I'm still handling an old char, but a new char already comes in?
04:07 AM jancoow: will in queue this interrupt?
04:07 AM exp: i'd have to read up on rtos to know how that's handled
04:08 AM exp: but bear in mind reading from the same memory you write to is going to lead to corruption
04:08 AM exp: (although i don't know if SAM writes tear, so a single byte might actually be ok, be careful)
04:08 AM jancoow: that's not freertos; that's just atsaml interrupts :)
04:09 AM exp: the interrupt and usart_read_job are likely to be separate, but i am losing confidence cause i'm only looking at a paragraph of your code
04:10 AM exp: give me a few mins to go to a meeting
04:10 AM exp: and i'll discuss further, but please remember i'm just an amateur, not a pro
04:11 AM jancoow: the usart_read_job enables a SERCOM_USART_INTFLAG_RXC which will fire when a new byte is available, calling my interrupt function
04:11 AM jancoow: so I was curious what will happen if I'm still in that function when another character appears
04:13 AM exp: well, interrupts are just setting an internal flag
04:13 AM exp: so if your interrupt function clears that, the flag won't be set
04:14 AM exp: what does the function actually look like, if you can share that?
04:14 AM exp: and which processor are you using?
04:14 AM jancoow: usart_read_job is an ASF function
04:14 AM jancoow: uhm, atsamlj18b
04:14 AM jancoow: saml21j18b
04:15 AM exp: oh of course, bloody asf
04:15 AM jancoow: ;p
04:15 AM exp: i've been fighting it on my avrs
04:16 AM jancoow: https://asf.microchip.com/docs/latest/common.services.usb.class.cdc.host.example.saml21_xplained_pro_b/html/group__asfdoc__sam0__sercom__usart__group.html#ga095085e94cc009c31243df62395896fd
04:19 AM exp: right, so it's installing an ISR that will copy the received character to that buffer, but you've no way to check when it's completed it looks like
04:19 AM exp: i assumed it was the equivalent of usart_read_wait you were using there
04:19 AM exp: i'll read the source in a min and check how the ISR works
04:25 AM jancoow: the whole ASF uart interrupt routine is pretty over complex
04:26 AM jancoow: I don't really understand why they didn't implement a normal 'interrupt on new byte" routine
04:26 AM jancoow: you have to enable it and specify to listen for 1 byte; then if an interrupt occures it's going to add that to a buffer of... 1 . Increase pointer, check size, clear interrupt, then call our callback function
04:27 AM jancoow: and then you have to enable it again lol
04:27 AM jancoow: pretty lame not
04:27 AM exp: yes, ASF is hardly well optimised, i think they do that on purpose
04:28 AM exp: but, i didn't see where it would call a callback for you
04:28 AM jancoow: it does that in _usart_interrupt_handler
04:30 AM jancoow: if I receive a byte, I always know that the state is not busy so don't have to go to "system_interrupt_enter_critical_section"
04:30 AM jancoow: I think I'm just gonna set the buffer ptr, rx status and interrupt
04:39 AM jancoow: just like this ;p https://es.jancokock.me/7841c/
04:51 AM exp: well the result of the meeting is: i need to program a dozen PICs lol
04:51 AM exp: you got things working jancoow? i'm sorry i don't have much time at the second
05:01 AM jancoow: exp well it's hard to test because it does not happen often
05:02 AM jancoow: i'm not sure how much an enter critical can slow things down
05:02 AM jancoow: so by rewriting this that is not needed
05:01 PM catphish: my AVR board arrived today, everything works, i can make my LEDs blink, my stepper motor spin, and output serial data :)
05:04 PM nohit: nice
05:05 PM catphish: i'm programming / debugging with mplab snap, seems to work nicely, but will try to find some time to play with open source toolchain soon
05:06 PM qu1j0t3: catphish: awesome
05:08 PM catphish: https://i.imgur.com/i5mPwOz.jpg
05:10 PM catphish: mildly annoying that the mplab snap has a 4.7k pulldown on the UPDI line which acually needs to be pulled up
05:10 PM catphish: http://ww1.microchip.com/downloads/en/DeviceDoc/ETN36_MPLAB%20Snap%20AVR%20Interface%20Modification.pdf
05:11 PM catphish: the 10k pull-up on my application prototype is not enough to overcome it, but jamming another 10k resistor in the programming cable fixed it :)
06:04 PM exp: catphish: congrats
06:05 PM exp: catphish: did the fab house complain about the low amount of copper on the board?
06:05 PM exp: i don't recognise where it's from but i've only ordered from a few places
06:07 PM catphish: exp: jlcpcb, i went a litte overboard on the layers, most of the copper is in the middle
06:08 PM exp: i see, why no outer ground plane? 4 layer?
06:08 PM catphish: yes, it's 4 layer, ground plane is in the middle
06:09 PM exp: i have had complaints before when running more or less bare traces that it makes it more difficult for them to manufacture, having to remove so much copper
06:10 PM exp: i tend to have poured grounds everywhere i can and especially inbetween any signal lines like i²c
06:10 PM exp: i'm guessing the two vias at c12 / c13 are for power? are they inside the pad of c12?
06:11 PM exp: ah yes i see you have the same with U7, you should be careful with that too
06:12 PM exp: guessing this was all hand soldered?
06:12 PM catphish: yes c12 and c13 are decoupling caps for U5, the power comes up from the 2 inner layers to C12
06:13 PM catphish: yes, this is just an initial prototype with everything i might need for a future product, hand soldered
06:13 PM exp: the traces there are a little too long for those caps to be truly effective but via-in-pad will affect manufacturability if you want to automate it
06:13 PM exp: a poured ground would at least decrease the inductance there, these steppers very low current?
06:13 PM catphish: i always do via-in-pad, i'm surprised they haven't tented them here
06:13 PM exp: plugged vias cost extra
06:14 PM exp: they don't care unless you're assembling with them too i'm sure
06:14 PM catphish: jlcpcb costs nothing either way
06:14 PM catphish: i've used their assembly with filled vias i think, don't recall it being an issue
06:14 PM exp: i'd be surprised if they did filled vias for free but now i'm googling as i have a bunch of boards where i need a bunch of vias for power
06:14 PM catphish: let me check the last one i had assembled
06:15 PM catphish: ah, no, last board i had assembled by them, i did not put vias under pads
06:15 PM catphish: so maybe it's not possible
06:16 PM exp: they might accept it, but they might not guarantee quality
06:16 PM exp: that's how eurocircuits does it
06:16 PM exp: and they are right to, in the extreme it does cause problems
06:16 PM catphish: if not filled, they'll definitely fuck up automated assembly
06:17 PM exp: anyway it sounds like you know what you're doing, so i won't push any more unsolicited advice ;)
06:17 PM catphish: it's okay, i tend to work on projects with months in between, so i forget
06:17 PM catphish: this pcb really is a very rough prototype though
06:18 PM exp: it's also not likely you're particularly sensitive to high frequency noise or making a straight to commercial product :)
06:18 PM catphish: it's a 3-dial car gauge cluster with numerous inputs (analog, can, pulse counter, serial)
06:18 PM exp: what are you using for your can transciever / controller?
06:19 PM catphish: CAN controller isn't populated because i ordered the wrong size chip :(
06:19 PM exp: i'm about to break out some boards with an MCP25625 but in general i've found everything in short supply (not a shock)
06:19 PM exp: just interested if you have a preferred part i can look into
06:19 PM catphish: can conteoller is MCP2510, this is a very basic / standard part
06:20 PM exp: ah ok, i went for one with integrated transceiver
06:20 PM catphish: the line driver is ATA6560
06:21 PM catphish: i've not seen ones with integrated PHY
06:21 PM exp: was using tcan4550 but that went out of stock, haven't checked it recently
06:21 PM catphish: normally i'd use an stm32, and an external PHY, but stm32 stock is non existent right now, so i'm learning some AVR8
06:21 PM catphish: many STM32 have integrated can controller which is cool
06:22 PM exp: yeah there are some AVRs with them, i'm looking forward to moving up to stms, basically when they come back in stock
06:23 PM exp: at the moment i'm stuck with what stock i have, and i grabbed 50 or so 25625s, so that should do me for a few months
06:24 PM exp: lead time currently... may ☹
06:28 PM catphish: i'm looking at the new atmega 0 series
06:28 PM catphish: they seem like an upgrade from the classic avr8
06:29 PM catphish: how does one do a simple branchless repeated countdown from a value to zero
06:30 PM catphish: counting up is easy: value = (value + 1) % n
06:30 PM catphish: but counting down seems less trivial
06:30 PM exp: n- ;)
06:31 PM exp: an interesting question, but not for midnight
06:31 PM exp: goodnight
06:31 PM catphish: night :)
06:31 PM catphish: i'll use a branch for right now
06:42 PM catphish: well everything works nicely, i'll have a play with my prototype and hopefully also have a better look at pyupdi soon
06:46 PM exp: catphish: i couldn't stop thinking about it
06:46 PM exp: the same function works
06:46 PM exp: just swap + for -, and use a uint
06:48 PM catphish: i actually tried that first, but (0-1)%6 did not return 5 as i hoped
06:50 PM catphish: with an unsigned char, i got 3 (255%6) == 3, that makes sense, but with signed char, i got a nagative value i think
06:51 PM catphish: right, -10 % 10 == -2
06:52 PM catphish: it's absolutely correct, but not the value i wanted
06:53 PM catphish: TIL manufacturers prefer removing less copper from boards
06:54 PM catphish: some people create grids of insulated copper circles
06:56 PM catphish: well i'm happy my stepper motors, LEDs and serial ports work, looking forward to testing CAN when the correct IC arrives
06:57 PM catphish: you're right, it's midnight, i also shall sleep now, thanks
08:51 PM specing_ is now known as specing
10:41 PM jmiehe1 is now known as jmiehe