#avr Logs

Nov 11 2019

03:10 AM hackkitten is now known as Miyu
06:13 AM guanche: hey guys, can you think of a reason for which an arduino clone I'm programming in c would receive just "\x0c\x01\x07\x04" when I do: echo -ne "\x0c\x01\x07\x03\x04"?
06:13 AM guanche: it seems like the fourth character received is always the last in the sequence. Three-bytes messages work always fine though
06:14 AM guanche: and I have frame and parity errors enabled, which I never seem to trigger
06:15 AM guanche: have also tried with different usart speeds, always the same results
06:18 AM djph: hex 0x03 is ETX ... so ...
06:18 AM djph: are you triggering something on an ETX?
06:19 AM guanche: uhm, on the host or on the atmega?
06:19 AM guanche: oh, let me see stty
06:19 AM djph: on the atmega
06:20 AM djph: you're sending FF, SOH, BEL, ETX, EOT
06:20 AM guanche: but how would the atmega know that? I'm just receiving characters and printing them back
06:21 AM guanche: I can see -iexten on stty I'm gonna have to read up on that
06:21 AM djph: I was asking if you were doing processing based on the characters (also, all of those are non-printing)
06:22 AM guanche: no, nothing, I've been just bootstrapping a usart protocol, and so I'm printing them back with sort of a usart_puthex function, no processing involved at all
06:23 AM djph: OK, as they're non-printing, your terminal may be throwing them away
06:23 AM guanche: but as soon as I send more than three bytes together, the atmega gets screwed and only received the first ones, and the very last one
06:23 AM djph: i.e. when you receive them back
06:23 AM djph: in that case, your code is potentially messed up
06:23 AM djph: how're you handling it?
06:23 AM djph: er, how're you handling the echo?
06:24 AM guanche: I just usart_puts or usart_putdecimal on each step of the state-machine, I don't see anything getting lost on the way back to the host though
06:25 AM guanche: if I send printing characters the result is the same
06:26 AM djph: OK, so your state machine is wrong
06:26 AM djph: or perhaps your handling of the incoming data
06:26 AM guanche: very strange, just four states correctly reporting back, just with the last character messed up
06:26 AM djph: how're you buffering the data?
06:27 AM djph: (or are you even buffering it at all?)
06:27 AM guanche: no buffering, on each iteration of the loop I'm just waiting for RCX0 to complete to read the incoming character
06:27 AM djph: that's your problem then.
06:28 AM guanche: why, should I get characters in the same order the host sends them?
06:28 AM guanche: *shouldn't
06:28 AM djph: your loop can only go so fast
06:29 AM guanche: I thougth the host would wait for the other end to be ready?
06:29 AM djph: so what's likely happening is that you're going (1) receive, (2) continue to send, (3) while sending, get more data that you can't do anything with, so throw it away ... (4) send the last byte
06:29 AM djph: not if you don't have any flow control :)
06:30 AM guanche: so what's my best option, implement buffering then?
06:30 AM djph: probably
06:31 AM guanche: thanks I'll read on that and on flow control, though I think I can't do that with the ch340 or at least how it's wired
06:32 AM djph: What I did (for now) was "when RX, store to an array of bytes" (return to loop), check array of bytes at counter-1, if it's EOT, then kick off the TX
06:33 AM djph: Actually, I think I'm using an interrupt to trigger storing to the buffer
06:33 AM guanche: yes, that would be about the most natural way to go if doing software buffering, I guess
06:38 AM djph: yeah, I THINK you can get the ch-whatever to follow some hardware flow control, but I'm not 100% sure if the sparkfun jobbies actually implemented it
07:28 AM guanche: sure, the chip supports it, but it's not wired on the clone: http://actrl.cz/blog/wp-content/uploads/nano_ch340_schematics-rev1.pdf
07:28 AM guanche: only dtr is wired to reset the atmega for programming
07:30 AM djph: yup, makes using hardware flow control hard (I was thinking you were using the sparkfun ch340 breakout, not the one on a board)
07:30 AM guanche: no, just ebay clones
07:36 AM djph: yeah, no idea what those have wired up then
07:46 AM cehteh: hardware flow control on avr is pretty ugly because the specs mandate quite some buffering space
07:47 AM djph: yup
07:49 AM LeoNerd: I've never bothered trying to do flow-control
07:49 AM twnqx: i did
07:49 AM twnqx: at 2mbit/s i overran an ft232
07:50 AM LeoNerd: Ah.. I've not tried running them so quick :)
07:50 AM LeoNerd: 115.2k is my top speed
07:50 AM twnqx: but i did rts/cts iin software
07:51 AM twnqx: apparently the ftdi is not double-buffering, but doesn't accept more serial data while it does USB transfers
07:51 AM twnqx: may have been an ft245 instead
07:51 AM djph: ... man, that makes my 38k4 look positively abysmal
07:52 AM LeoNerd: I've gone off FTDIs. I usually use CP2102 or 5 chips
07:53 AM LeoNerd: Though I've also used the rather cute PL2303SA. Tiny little 8pin SOIC. It doesn't do handshaking, but it is small and super-super simple
07:54 AM LeoNerd: No xtal, no regulator.. no.. anything really. Just put USB in one side and get 3V3/TX/RX out the other
07:54 AM djph: nice
07:54 AM djph: except the 3v3
07:54 AM LeoNerd: That's basically required when dealing with USB
07:54 AM LeoNerd: USB gives you 5V VBUS but the signalling happens at 3.3V
07:55 AM LeoNerd: The CP2012/5 run at 3.6V, which is -juuust- low enough to be fine at talking USB, while being -juuuust- high enough to trigger Vhi of 70% of VCC on a 5V chip (i.e. 3.5V)
07:55 AM djph: yeah, but a 328 won't run at 16 MHz on 3v3
07:56 AM LeoNerd: No but that's fine. VBUS gives you 5V, so run at 5V
07:56 AM djph: AH
07:57 AM djph: I read it as you "only get" 3v3 and TX/RX out of the PL2303
07:57 AM djph: or rather, that it's only 3v3-tolerable
07:57 AM LeoNerd: Oh.. no, I mean it has an onboard regulator so it can supply 3V3 if you want it
07:58 AM djph: oh, nice
07:58 AM LeoNerd: Prettymuch any USB-UART bridge turns out to be 5V tolerant on its UART pins
07:58 AM djph: I mean, it could be super nice for that 128KHz tiny I'm playing with (servo controller -- so 128 KHz is stupid simple to scale the PWM to 50 Hz for)
07:59 AM LeoNerd: At worst just stick a moderate resistor (220R to 1k?) in series with the pin and let the clamp diode do its thing
07:59 AM djph: ... I just need to get less bad at asm first. :(
08:00 AM LeoNerd: Eh; I just do all my AVR stuff in straight C
08:00 AM djph: yeah, I'm more trying to learn
08:00 AM LeoNerd: Well, except the super-rare times I get lazy and use the Arduino USB wrapper bits on a 32U4
08:00 AM djph: I'm probably just about at "give up" and write it in C
08:00 AM LeoNerd: because that's still easier than trying to wrap my head around LUFA
08:01 AM twnqx: LeoNerd: LUFA takes a bit of getting used to, but it's acceptable in the end (i've seen way worse)
08:01 AM LeoNerd: Oh it's probably fine.. I know many people use it successfuly
08:01 AM LeoNerd: I just wanted a little IR receiver -> USB keyboard box. I found it easy enough just to use the Arduino keyboard library for that
08:02 AM LeoNerd: Couldn't be bothered to spend time working out how to drive LUFA, as comapred how quickly I got it to work on that instead
08:02 AM guanche: I've even managed to integrate lufa with autoconf/automake
08:02 AM LeoNerd: *gasp*
08:02 AM LeoNerd: autoconf on AVR??
08:02 AM twnqx: why... why would you use autoconf... on avr..
08:02 AM guanche: it's pretty simple if you start with one of the examples
08:02 AM LeoNerd: ... but why?
08:02 AM guanche: I always use, because it's not just firmware, it's software and schematics
08:03 AM LeoNerd: autoconf is for working out what various unix utilities your 1980s-era commercial unix box has...
08:03 AM LeoNerd: "Looking for sed... nope; it's an AVR". "Looking for bison... nope. It's an AVR"
08:03 AM twnqx: nah, it's more than that these days, if combined with pkgconfig tests etc
08:03 AM twnqx: but yeah, you can end up having weird things
08:04 AM twnqx: i think i have a PC program that uses an avr program to boot a tricore from
08:04 AM guanche: I have a set of macros that check for the avr chain and gschem/pcb that I use in autoconf so I end up with host's toolchain and avr chain defined
08:05 AM guanche: then it's all a matter of using it where it's needed
08:05 AM guanche: well, in configure.ac
09:40 AM polprog: i have to learn autoconf
05:17 PM rue_mohr: ouch
05:17 PM rue_mohr: well, I think its configured by a program
05:26 PM rue_mohr: djph, you can write something in C, compile it to asm, and copy/paste or tweek
07:43 PM djph: rue_mohr: yeah, but the C compiler is difficult to follow
08:04 PM rue_mohr: the assembler output?
08:04 PM rue_mohr: na
08:04 PM rue_mohr: turn on any optimization, you can even have it annotate the code
09:26 PM djph: hm ...
11:39 PM day__ is now known as day