#avr Logs

Sep 21 2019

02:20 AM jmorris: can anyone tell me why this (https://pastebin.com/QGjSfZBg) successfully negates PINA and outputs it to PINC? it seems like things are being pushed on the stack in the wrong order
05:05 AM EI24: hi, can a i2c slave ever initiate a transfer, or is it then autoamtically the master? I have a device which can only be accessed as a slave by the mcu, but i want the slave device to issue a transfer and then have the mcu get a irq
05:07 AM vmt: can't you send an interrupt by any other means?
05:08 AM EI24: vmt, yes the slave device has irq pin
05:08 AM EI24: but wondered if you could do it without it
05:08 AM EI24: im wondering*
05:08 AM vmt: not this way, no
05:09 AM EI24: ill use the pin then
05:11 AM vmt: ...which is probably why it is there
05:51 AM LeoNerd: If interrupts aren't too frequent, it's often common among I²C devices to use open-drain IRQ lines, so you can bus them all together the same as SCL and SDA
05:52 AM LeoNerd: When an interrupt happens you'll have to ask each device if it was them, but usually there's not too many and that's fairly quick
08:12 AM Smidge204: I2C doesn't have a way for slaves to initiate in and of itself but if you control both the master and slave(s) you can cheat
09:42 AM Strogg: 'lo 'lo
09:42 AM Smidge204: oi
09:46 AM Strogg: Is anyone here using pyupdi to program their new attiny's and atmegas with the UPDI interface? I'm getting a python syntax error when I run it "TypeError: 'list' does not support the buffer interface" and I just wanna check I'm not doing something stupid before I start trying to hack on the code
09:47 AM Strogg: the traceback seems to lead to a line "self.send([constants.UPDI_BREAK])", so that's probably the issue.. but it seems like such a breaking bug, it's weird it's in the tool
09:52 AM Smidge204: huh
09:52 AM Smidge204: Not familiar with any of that unfortunately
09:53 AM Strogg: it seems to be around python3 not liking list types for serial devices.. I"m changing it all to bytes() data types..
09:53 AM Smidge204: "pyupdi is a is a driver written in python that lets you turn a simple usb to serial adapter into a UPDI programmer using a single resistor"
09:53 AM Smidge204: Seems straightforward so yeah it's almost certainly a software issue
09:53 AM Strogg: yeah. it's pretty neat. the new attiny414 use the UPDI interface. 1 pin used for programming instead of 4 like the old SPI way
09:54 AM Smidge204: I've been using an arduino pro mini and USB-serial adapter for programming my attiny84
09:55 AM Smidge204: https://i.imgur.com/bZAxcHV.png A dongle only a hacker could love
09:56 AM Smidge204: Sadly I know nothing of python other than it was a major pain in the ass last time I tried to do anything with it :p
09:57 AM damjan: Strogg: which version of pyserial do you have?
09:57 AM Strogg: ii python3-serial 2.6-1.1 all pyserial - module encapsulating access for the serial port
09:57 AM Strogg: damjan: 2.6-1.1, I think
10:00 AM damjan: Strogg: wow, that one is from 2011
10:01 AM Strogg: hehe yeah.. my internal server runs an older debian stable. I've updated my sources, but I'm doing the upgrade piecemeal
10:01 AM Strogg: I keep meaning to apt dist-upgrade before going to sleep
10:01 AM * Strogg apt gets some stuff
10:03 AM damjan: Strogg: pyserial is up to 3.4, and had quite some api changes
10:04 AM damjan: not sure what pyupdi uses, it doesn't specify
10:06 AM damjan: Strogg: what version of python do you have?
10:06 AM Strogg: I've updated pyserial.. it's 3.4-4 now.. python is 3.7.4+
10:07 AM vmt: what about pyneapple, pyston, pynball, pycture or pyckaxe?
10:07 AM Strogg: looks like it's talking to the chip now.. now I just gotta figure out how to unlock the MCU
10:07 AM Strogg: INFO:app Timeout waiting for device to unlock
10:12 AM Strogg: slick. getting somewhere. resetting the part makes that go away.. now I just need a hex file of my elf
10:38 AM Strogg: when you get the gcc error of "avr/bin/ld: cannot find crtattiny414.o: No such file or directory"... that's a .o, so it has to be added to your list of objects, right? it's not a library
10:39 AM PoppaVic: sounds like the install paths are wrong
10:40 AM Strogg: well.. debian's avrlibc doesn't support the new attinys, so I had to install the support packs from atmel. I modified my LDFLAGS so it could find the path to the lib, but it's complaining about the crt file
10:40 AM PoppaVic: yeah, c-runtime.. I grok. Well, you need to find it and then list it first in the files-to-compile
10:50 AM Strogg: urgh. this is a pain. I should build my own avrlibc deb
10:52 AM PoppaVic: ld has been a pain forever.
11:57 AM rue_mohr: how do you people come up with these problems?
12:29 PM Thymo_ is now known as Thymo
12:29 PM vishwin60 is now known as vishwin
12:29 PM davor_ is now known as davor
03:06 PM Strogg: "Programming successful" yay!
03:06 PM Strogg: now I just gotta fix my C code and make my led blink
03:08 PM damjan: Strogg: nice. I wonder if I can modify the "ATtiny817 Xplained Mini" board to use the same programmer … since it didn't work on Linux with avrdude
03:08 PM Strogg: damjan: if it has the pin for UDPI, then it should work
03:09 PM Strogg: damjan: from the data sheet.. "Single Pin Unified Program Debug Interface (UPDI)" uses PA0 on the QFN24 package
03:11 PM damjan: it has some strange connection with the clocks though
03:11 PM Strogg: yay! das blinkenlights!
03:11 PM Strogg: helps if it toggle the right pin. hehe
03:12 PM damjan: great
03:14 PM Emil: Strogg: consider joining #avrs (and checking out avrs.fi for some quick tutorials and links)
03:15 PM Strogg: I noticed the topic, but I didn't wanna start any drama.. why the other channel?
03:16 PM vmt: consider not joining #avrs
03:17 PM vmt: Strogg: the other channel exists because the op here got tired of the channel mainly consisting of idlers, so he started to kick them. emil got annoyed and started his own channel. the kicking indicent happened a long time ago so i think emil should finally let go
03:17 PM vmt: the op being rue
03:18 PM * Strogg remembers rue_mohr from long time ago. no bad memories
03:18 PM vmt: if emil is around when new people join he basically tells them to "consider joining #avrs", i think it's his mantra or something
03:19 PM Strogg: weird. *shrug* I'm in too many channels already. hehe
03:19 PM vmt: i don't find this channel being in exactly good hands under the command of rue either, but still having two different channels is just counter-productive overall
03:20 PM vmt: in general it's considered a bad call to give schizophreniacs control over public things
03:20 PM vmt: *shrug*
03:21 PM vmt: schizophrenics* i guess
03:32 PM Smidge204: Splitters!
03:37 PM Strogg: hrmm at some point, I'm going to have to figure out how to connect a debugger to this thing
03:38 PM LeoNerd: "this thing"?
03:38 PM Strogg: LeoNerd: attiny414 with the new UPDI interface
03:38 PM LeoNerd: Ah... yeah; I'm still working on reverse-engineering those
03:38 PM LeoNerd: The OCD part is not documented :(
03:38 PM Strogg: LeoNerd: the IC or the protocol?
03:39 PM LeoNerd: Any of the OCD parts really
03:39 PM LeoNerd: But it's OK - I have the xplained board, that I can snoop on and decode how it all works
03:39 PM LeoNerd: Just not got around to it yet
03:39 PM Strogg: LeoNerd: have you seen pyupdi?
03:39 PM Strogg: python implementation of the UDPI interface
03:39 PM LeoNerd: Yes I used it to write Device::AVR::UPDI
03:39 PM LeoNerd: Yes
03:39 PM LeoNerd: That talks UPDI which lets you talk to the chip's IO address space, NVM controller, etc etc
03:40 PM LeoNerd: It lets you talk to OCD as well but Microchip don't explain in any of the datasheets how OCD works
03:40 PM Strogg: hrmm unfortunate.
03:40 PM LeoNerd: So I can talk all the /public/ parts of the API, just not the OCD part
03:40 PM LeoNerd: yet
03:40 PM LeoNerd: But I'll get there :)
03:41 PM damjan: LeoNerd: do you have a github repo, so I can star it and then check it from time to time? :)
03:42 PM LeoNerd: No
03:42 PM LeoNerd: But I imagine if I do finish decoding OCD I'll be sure to shout loudly about it here
03:43 PM Strogg: so what's you're saying is.. add lots of LEDs to my boards, because gdb isn't happening.. hehe
03:43 PM LeoNerd: I usually do debug-by-LED anyway. Or "LED" being a GPIO line on an LA, if it's too fast for humans to see LEDs
03:43 PM LeoNerd: Usually works fine for me
03:43 PM Strogg: I've been spoiled by STM32, I suppose.. hehe
03:44 PM LeoNerd: I work on many different sorts of systems; honestly debug-by-printf is about the only universal across everything
06:23 PM rue_mohr: I usually use io pins
06:23 PM rue_mohr: and scope or logger
06:24 PM rue_bed: tho, it usually works to just look at the code and find the stupid mistakes
06:24 PM rue_bed: I use my own libraries, so I know their tested
07:16 PM Smidge204: https://www.avrfreaks.net/forum/xplained-yourself-diy-updi-ispdw-tpi-swd-debugger-supported-atmel-studio
08:07 PM Strogg: Smidge204: I was about to buy one, and then I noticed it ships from Poland.. that might take a while to get here. hehe
08:07 PM * Strogg bookmarks for later
11:37 PM day__ is now known as day