#avr | Logs for 2016-08-17

Back
[04:35:44] <polishprogrammer> hi
[04:36:09] <polishprogrammer> my i2c implementation keeps the line low when it receives SLA+W byte
[04:42:32] <polishprogrammer> the SCL line
[04:42:45] <polishprogrammer> what could go wrong?
[05:21:35] <twnqx> shouldn't the I2C master always run the clock?
[05:21:42] <twnqx> even when readin
[05:22:03] <polishprogrammer> yes it did but the slave pullled it low
[05:22:06] <twnqx> also, since I2C runs an open collector, the clock line will be stuck low either way
[05:22:10] <polishprogrammer> i sorted it out, forgot to reset twi
[05:22:15] <polishprogrammer> when no IF executed
[05:22:47] <twnqx> i think the slave is allowed to do that, it's calles clock stretching
[05:23:03] <twnqx> if it needs to delay the transaction until it is ready
[05:24:19] <polishprogrammer> yes
[05:24:40] <polishprogrammer> and because i forgot to reset the twi after transaction slave was pulling low forever
[05:25:25] <polishprogrammer> now i am happy because i made a coprocessor
[05:25:47] <polishprogrammer> buspirate send a byte to avr, avr sends back byte*2
[05:25:52] <polishprogrammer> ;)
[05:28:52] <carabia> what's this for?
[05:29:04] <polishprogrammer> bus pirate or avr?
[05:29:15] <carabia> well... from the looks of it, both
[05:30:37] <polishprogrammer> The avr construction is an excersise i did to learn i2c
[05:30:52] <polishprogrammer> bus irarte is a handy little device that speaks lots of protocols
[05:31:13] <polishprogrammer> i use buspirate to communicate between the PC and electronics
[05:31:21] <carabia> yeah i know
[05:34:27] <polishprogrammer> ok, now i have a usable device
[05:34:33] <polishprogrammer> an i2c beeper
[05:34:41] <polishprogrammer> i can tell it how many times to beep
[05:34:43] <polishprogrammer> xD
[06:19:59] <inflex> Oooooh, FFS.. that was a good waste of an hour
[06:20:41] <inflex> I accidentally soldered on an ATTiny48 rather than MEGA48... and everything actually built and flashed okay, but as soon as I did some i2c stuff, it crashed out hard
[06:20:58] <inflex> that said, it should have worked, but I think my compile was for a mega48 and so the instructions would have been wonky
[06:26:13] <Lambda_Aurigae> yeah...that will cause problems.
[06:26:24] <Lambda_Aurigae> theyhave different peripherls.
[06:27:03] <Lambda_Aurigae> and different number of pins.
[06:27:34] <Lambda_Aurigae> or, maybe not..guess I've never seen an attiny48 before.
[06:30:14] <Lambda_Aurigae> lower speed and no multiplier.
[06:30:33] <Lambda_Aurigae> one fewer 8-bit timer
[06:32:22] <Lambda_Aurigae> difference of 37 cents at digikey
[06:33:33] <LeoNerd> Generally the ATtinyX will bear no relation to the ATmegaX
[06:33:36] <LeoNerd> for most X
[06:33:42] <Lambda_Aurigae> for most, yeah.
[06:33:54] <Lambda_Aurigae> the attiny48 seems to be just a slightly cut down atmega48
[06:33:59] <LeoNerd> Yeah; that makes sense
[06:35:00] <Lambda_Aurigae> for an additional 50 cents over the atmega48 one can get a pic32mx250f128b
[06:35:53] <Lambda_Aurigae> but that does require considerable more investment in time and developer tools to use properly.
[06:36:48] <twnqx> or for just 50ct some ARM...
[06:36:55] <twnqx> not more, final price.
[06:36:56] <Lambda_Aurigae> yeah.
[06:37:09] <twnqx> kind of depressing.
[06:37:19] <Lambda_Aurigae> but a cheap arm like that doesn't have the memory that the pic32 does.
[06:37:30] <Lambda_Aurigae> at least, not the ones I've found.
[06:37:37] <Lambda_Aurigae> nor the dip package and usb built in.
[06:37:52] <twnqx> i don't see the point in dip packages
[06:38:01] <twnqx> for breadboarding there's breakouts
[06:38:09] <twnqx> for everything else SMD is better anyway
[06:38:14] <Lambda_Aurigae> I find them easier to work with and, with free samples from manufacturers, cheaper.
[06:38:21] <dgriffi> breakouts get annoying
[06:41:02] <dgriffi> oh joy of joys... I seem to have static-zapped a dtmf generator chip
[06:42:18] <carabia> dip's useful for ultra-fast prototyping. To me, that's about it
[06:44:05] <LeoNerd> I just ordered a bunch of (small)-PDIP adapter boards, for breadboarding
[06:44:10] <carabia> and yeah, cheap arms don't really have a whole lot of memory, but comparing to any avrs of the same price-range, they have loads
[06:44:14] <LeoNerd> Got me some MSOP8, MSOP10, QFN32
[06:44:34] <carabia> i'd imagine qfn32 adapters are quite pricey
[06:44:35] <LeoNerd> Stupid 10pin
[06:44:42] <LeoNerd> It's not a test socket, just a PCB
[06:44:48] <carabia> even then
[06:45:00] <carabia> or i guess alibaba/ebay delivers... :)
[06:45:01] <LeoNerd> I want to make a strictly one-off project using a QFN.. wait; QFN64, not 32
[06:45:12] <LeoNerd> I need a mega128A, with its 53 GPIO pins
[06:45:16] <carabia> Reeaallly? :D
[06:45:19] <dgriffi> use a schmartboard?
[06:45:21] <LeoNerd> But it's only a oneoff project so I can't be bothered with a PCB
[06:45:40] <LeoNerd> I'm driving an 8x8 red/green bicolour LED matrix. So that's 8 rows, 16 columns. 24 pins.
[06:46:03] <LeoNerd> My input signal comes in a *further* two lots of 8.. or maybe 10 pins. So another 16 to 20 pins. So ... 44 IO pins on just the LED matrix and signal
[06:46:15] <LeoNerd> Then I want some buttons and miscellaneous indicator LEDs.. and a serial port.
[06:46:32] <LeoNerd> Even with 53 GPIOs, I'm beginning to feel like I -might- have to put the LEDs and/or buttons on some sort of GPIO expander
[06:46:33] <carabia> how about some-200+ tfbga-to-.1"-matrix adapters
[06:47:07] <dgriffi> try some MAX7219 chips
[06:47:21] <LeoNerd> I have a bunch
[06:47:34] <LeoNerd> The MAX7219 is great for driving a *single* colour 8x8 LED matrix
[06:47:46] <LeoNerd> It's no good for driving a bicolour one; this matrix is in effect a 16x8
[06:48:06] <LeoNerd> The MAX7219 has no sync output, so you can't cascade multiple of them together with common rows
[06:48:18] <MarkX> abcminiuser, adding the interface worked :) got comms working now. i didn't add an EP to it but i can send control transfers straight to ep0 :)
[06:48:33] * twnqx looks at a qfp52 breakout board in front of him
[06:48:42] <LeoNerd> This LED matrix has 8 rows, 8 *red* column and 8 *green* column lines
[06:48:47] <twnqx> lucky, a holtek ht1632 on it!
[06:49:03] <twnqx> LeoNerd: you should take a look at that chip :P
[06:49:31] <LeoNerd> Ooh.. 32x8
[06:50:03] <LeoNerd> Thing is I can do it just fine with a mega128A. It's simple enough. And only a oneoff
[06:51:12] <LeoNerd> And I see they're cascadeable. Nice. If I ever need a reeeallly big matrix I'll keep that in mind
[06:53:14] <LeoNerd> Ohman and PWM as well?
[06:53:53] <LeoNerd> But really, 52 pins? That's... an odd choice
[07:00:02] <inflex> awww
[07:00:07] <inflex> I missed the debate about DIPs
[07:00:19] * inflex is happy about the death of DIP as a general rule.
[07:04:10] <inflex> PITA flipping PCBs over, bending metal legs, clipping
[07:07:14] <LeoNerd> Yah, they're annoying
[07:07:30] <LeoNerd> I have a good stock of adapter PCBs now anyway, for breadboarding
[07:16:27] <vpcd> i made an ISP connector for my board but now everytime i connect the programmer the chip powers down. i have found that the supply voltage drops 1.2 V when the programmer (usbtiny) is connected. i have triple checked the connections and am quite sure they are okay, the programmer works fine on other stuff. what could cause this voltage drop?
[07:26:17] <vpcd> it was the connections... i was looking at the wrong connector diagram and got the whole thing backwards...
[07:27:23] <LeoNerd> Oops :)
[07:27:26] <LeoNerd> Always something simple ;)
[07:28:50] <inflex> almost always is, yes
[07:31:36] <vpcd> yeah, i checked the simple stuff but didn't check the simplest of them all :)
[12:03:51] <carabia> http://hackaday.com/2016/08/17/introducing-the-teensy-3-5-and-3-6/ this looks quite cool for a barebone-cm4
[12:04:02] <carabia> fuck the arduino-stack, w/e
[12:09:09] <rain1> I have a teensy 2++ and it's cool
[12:11:35] <carabia> yeah well this is a cm4, it's quite a beast in a whole different realm than 8bs
[12:12:03] <carabia> cm4s even have builtin dsp, or well that's kind of the point of them really
[12:12:29] <rain1> ok
[12:13:28] <carabia> could have a few of these around, $28 isn't all _that_ bad.
[12:16:23] <carabia> hopefully it'll be sold without the headers. Should look into elsewhere though, $28 probably has some air... eh I meant to say "arduino stack R&D costs" in it.
[20:58:04] <PoppaVic> OK, folks - maybe I am just confused.. I could use a little advice. I've a section of flash with lo[functionptr,functionptr,...]hi AND, I want to execute each in order.
[20:58:54] <PoppaVic> From what I see, the ONLY way to do this is by loading Z with the address of the list, and repeatedly doing an LPM, mov, increment, etc
[21:01:46] <PoppaVic> Am I missing an instruction, or misread something? Because the ijmp/icall would (it seems) leap to the Z pointer, not contents-of.
[21:45:57] <CORDIC> PoppaVic: `ijmp' will copy `Z' to `PC'. `icall' will first, so to speak, copy `PC' to `SP' stack, then (same as `jmp') copy `Z' to `PC'.
[21:46:25] <CORDIC> You need one more indirection than `icall'.
[22:00:23] <CORDIC> PoppaVic: `ret' will copy from `SP' Stack (not `SP' itself) to `PC'. `SP' points to RAM, and AFAIK the closest way to do that with a pointer to FLASH is with a few subroutines.
[22:03:29] <PoppaVic> well, LPM is the only answer. However, I discovered that the 328/1284p support 3 ways to use LPM - apparently, I either misread the AVR pages or a tutorial/example. So, now I can at least combine several operations at once for the same price
[22:04:18] <PoppaVic> I had been under impression "LPM\n" was it - and it's not, as I can do LPM <reg>,Z[+] - and that mostly saved the world
[22:07:32] <CORDIC> PoppaVic: I see what are You trying to say.
[22:08:11] <PoppaVic> yup. Well, back to DTC hell ;-)