Back
[01:18:57] <rue_bed> but what can I do with my tiny13?
[07:14:43] <uramhoaH> bootjacker.. can't it be stopped if you make your bootloader check for the presence of that evil SPM instruction while it flashes a FW?
[07:15:14] <uramhoaH> and reject any FW which includes that instruction
[07:15:29] <LeoNerd> That's a traditional solution, yup
[07:16:03] <LeoNerd> Though a sufficiently sneaky piece of firmware *might* be able to steal use of the particular SPM instruction used by your bootloader if it was suitably cunning
[07:17:01] <uramhoaH> hm
[07:17:50] <Jartza> hello
[07:26:11] <twnqx> LeoNerd: isn't that stealing exactly what boojacker does, from the blog post?
[07:26:37] <LeoNerd> Ah. no idea.... didn't look :P
[07:28:38] <LeoNerd> I don't see a link in scrollback
[07:28:52] <twnqx> http://oneweekwonder.blogspot.de/2014/07/bootjacker-amazing-avr-bootloader-hack.html
[07:28:58] <twnqx> i googled it because he mentioned it :P
[07:29:02] <uramhoaH> surely bootjacker includes the SPM instruction in itself.. so this can be captured, right?
[07:29:06] <twnqx> no
[07:29:11] <twnqx> it exactly doesn't
[07:29:17] <twnqx> that what bootjacker is all about
[07:29:26] <uramhoaH> eh
[07:29:31] <uramhoaH> how does it find it then>
[07:29:45] <twnqx> in his case, he knows the bootloader
[07:29:51] <twnqx> and uses the bootloader's instruction
[07:29:55] <uramhoaH> i know that it doesn't actually have it as an instruction.. because it's not allowed to call that instruction
[07:30:04] <twnqx> with a timer interrupt to return to his code just after execution of the instruction
[07:30:13] <uramhoaH> hm
[07:30:38] <twnqx> so he jumps into the bootloader, and after just one instruction the timer fires and he gets back to his code
[07:30:45] <uramhoaH> i had the impression that bootjacker has a function which searches the bootloader section to find the SPM instruction location
[07:30:45] <twnqx> hijacking the bootloader's spm
[07:30:50] <twnqx> maybe
[07:30:58] <twnqx> but blacklisting code becuase of ONE BYTE
[07:31:03] <twnqx> which might be purely data
[07:31:12] <twnqx> doesn't sound resonable :P
[07:31:54] <LeoNerd> Ahh yes.. that's lovely :)
[07:34:33] <LeoNerd> The use of the timer interrupt - pure genius I think :)
[07:50:58] <uramhoaH> well.. the protection is just dumb.. it should not let you jump into the bootloader section from the firmware..
[07:51:45] <uramhoaH> or at least not let you jump to a location other than the beginning of the bootloader
[08:31:30] <kdehl> So, I have an external parallel 16 KB UV EROM connected to an ATmega1284P running at 20 MHz. Data bus on port B, low address on port A, high address on port C. After I put the address on the address pins, I need to wait 6 NOPs before I have reliable data on the data bus. That, in my world, corresponds to 300 ns (assuming each NOP takes 50 ns to execute). What am I doing wrong?
[08:32:06] <rue_bed> hmm
[08:32:30] <rue_bed> 2716?
[08:32:42] <rue_bed> funny, I made a library for all that
[08:34:07] <kdehl> M27C128A.
[08:34:22] <kdehl> kbyte, not kbit. :)
[08:34:38] <kdehl> How long do you wait?
[08:35:34] <kdehl> Are my calculations correct, at least?
[08:37:26] <kdehl> I did the same thing with an SRAM the other day. It was specified at 55 ns, I tried to wait only one NOP (50 ns), didn't work. Waited two NOPs, (100 ns), worked perfectly. So that made sense.
[08:37:36] <kdehl> But having to wait 300 ns for this doesn't feel right.
[08:37:44] <kdehl> *this EPROM
[08:37:55] <kdehl> When it's only supposed to be 120.
[08:41:24] <kdehl> Doesn't seem to be a power issue either, the voltage is a stable 4.90 V even if I run the reading continuously.
[08:44:30] <uramhoaH> where is this "XMEGA application notes" document? i can't seem to find it on le atmel site
[08:47:24] <kdehl> Aha! If I keep /E low at all times, it works with only three NOPs.
[09:11:04] <kdehl> This does not make any sense. If I keep /E low at all times, it's supposed to work at 60 ns, according to the datasheet.
[09:13:49] <kdehl> Hm. I suspect it has to do with long wires.
[09:20:44] <avrguest> I have set the clock fuse to the wrong setting. Now my atmega does not seem to start. Is there a way to reset the fuses?
[09:23:27] <kdehl> avrguest: High-voltage programming is always an option.
[09:27:15] <avrguest> Can I do high voltage programming with my jtagice3?
[09:28:51] <kdehl> Check its manual.
[09:37:28] <bss36504> Nope, you cant with the JTAGICE3
[09:37:39] <bss36504> Only the Dragon can do the HVPP, if i recall correctly
[09:37:49] <bss36504> well and the STK500, I think
[09:38:59] <avrguest> That sucks
[09:47:24] <kdehl> Yeah. But do you know what fuses you programmed wrong? If it's just the wrong clock source, you could just temporarily replace it to be able to fix the fuses.
[09:47:39] <kdehl> If you have disabled the RESET pin or SPI, on the other hand, you're out of luck.
[09:48:13] <kdehl> replace the clock source, that is
[10:10:34] <bss36504> avrguest: can you elaborate more on what you need the HVPP for?
[10:12:55] <avrguest> I think I have selected the wrong startup time for the clock. I used a fast startup that is wrong
[10:16:38] <bss36504> Oh. What are you using to clock the chip? You should be able to apply a ttl clock on one of the clock pins to recover it. Do you have a function generator or another AVR with which you can make the clock signal?
[10:45:07] <avrguest> bss36504: thanks. I used a fixed clock and was able to set the setting back to something that works
[12:17:32] <grey> What's the best way to use TWI/I2C from an AVR? I see some examples shifting directly into the TWI registers, and some references to C code libraries floating around but lots of broken links there, and various hobby "look what I made!" libraries that don't really inspire confidence
[12:36:00] <LeoNerd> What sort of chip? If it has a hardware I²C module, almost certainly easiest just to use that directly
[13:07:58] <grey> hmm, I just realized my attiny's might not support it, so lets say an atmega328?
[13:08:23] <LeoNerd> Wellsure; on a mega328 you'd just use the I2C controller
[13:08:50] <grey> okay so, I only just now realized the attiny doesn't have an i2c controller, that's probably what was making my googling around so confusing
[13:08:53] <grey> derp
[13:09:19] <Strangework> Pardon, grey, what do you mean by the attiny doesn't have an i2c controller?
[13:09:23] <LeoNerd> Most of the tinies do have a USI, which can be used as an I2C master to good effect at least
[13:09:46] <LeoNerd> Some of the newer ones (e.g. tiny1623) also have a real I2C slave, though on the same pins as USI
[13:10:00] <grey> ah, I had opened up the data sheet and searched for twi and didn't see it
[13:10:12] <Strangework> I have a few attiny24a's. I'm implementing an i2c master on it, and from what I gather it can work as a slave just as well
[13:10:26] <LeoNerd> I2C slave on USI does work, but it's quite a lot of software effort
[13:10:31] <LeoNerd> I2C master or SPI are easy enough
[13:10:56] <Strangework> LeoNerd, what about being an i2c slave makes it software intensive for the attinys?
[13:10:56] <grey> just looking for i2c master right now, eventually I'm sure I'll want slave but I can wait
[13:11:53] <LeoNerd> Strangework: Just needs a bit more hackery in terms of things like address checking
[13:12:14] <LeoNerd> Real I2C hardware modules check the slave address in the first byte of the transaction and don't wake up software if it doesn't match. USI is much simpler so can't do that
[13:14:28] <Strangework> Ah, so the USI equipped chips are interrupted by any and all messages instead of just messages addressed to them?
[13:14:55] <LeoNerd> USI just fires an interrupt for every byte transferred
[13:15:02] <grey> neat
[13:15:14] <LeoNerd> USI is really just a hardware-assisted 8bit shift register. You can use it to implement the shifting parts of SPI or I2C
[13:17:07] <Strangework> That makes sense.. Thanks, I wouldn't have considered any of that!
[13:17:27] <Strangework> Luckily for my use case, i2c would not be used very often at all :)
[13:18:19] <LeoNerd> I've done SPI and I2C master with it.. works fine
[13:18:26] <LeoNerd> Acutally I've done both at the *same time* ;)
[13:18:41] <LeoNerd> The trick is to put SCL on a different GPIO pin
[13:19:57] <Strangework> Huh :O I am not familiar with how SPI works yet. So you had in total, SDA, SCL, MOSI, MISO and SCLK?
[13:20:37] <LeoNerd> Not quite.. the entire point was that if you're talking I2C from the USI module, the data line SDA is still the same as the MISO line
[13:20:37] <Strangework> No relation between what you were driving on the datalines, just happen to be driving the two clocks from the same clock source?
[13:21:30] <LeoNerd> SPI was (GPIO for SS) + MOSI/MISO/SCK on the USI module, then I2C was SDA on the USI module but another GPIO pin for SCL
[13:21:48] <LeoNerd> When talking to an I2C device, none of the SPI SS lines are asserted, so the SPI devices all ignore it
[13:22:05] <LeoNerd> When talking to an SPI device, the SCL line stays high, so I2C devices never see a START condition
[13:22:39] <LeoNerd> It's slightly nicer than bitbanging one of SPI or I2C, and saves an IO pin
[13:22:52] <Strangework> Ahhhhh! That's pretty cool, actually
[13:23:26] <Strangework> I assume you had to do this since some devices had only SPI or only I2C interfaces?
[13:23:55] <LeoNerd> Yeah.. nRF24 radio on SPI and MPL... somenumber. I forget.. temperature/pressure sensor
[13:25:43] <LeoNerd> It's not a problem on the ATmegas because they have distinct hardware for SPI vs. I2C
[13:26:18] <LeoNerd> I *could* have bitbanged one or the other, but that would use more code and GPIO pins.. though it would give me the advantage of being able to talk both concurrently. Not that I need it this time
[13:27:29] <Strangework> I wouldn't want to be using more pins - the doubling up of the USI hardware is clever!
[13:28:02] <Strangework> I'm mainly toying around with the attiny's for now, so I likely won't be touching a true i2c/spi interface in a while
[13:29:01] <LeoNerd> The real SPI hardware on an ATmega is fairly similar to USI on a tiny, to be fair
[13:29:26] <LeoNerd> Slightly different register names, a little easier to manage. THe only real difference is mega's SPI is self-clocking, whereas USI needs a bit of software assistance
[13:31:55] <Strangework> What does self-clocking imply? I've been working with clock selection on the USI and have been a bit confused as to what can be done. From what I gather, I can either flip the edge manually by writing to a bit in USICR, or I can hook up an external clock.
[13:32:49] <LeoNerd> Right; so the SPI on ATmega, you just write the byte you want to output into a register, and the module drives the output SCK line all by itself, at whatever clock rate you configured it to, and it tells you when it's finished (either by a status bit or an interrupt)
[13:33:22] <LeoNerd> But on USI, the module won't clock itself. You have to toggle it by driving the SCK pin yourself. So you drive the actual output pin, and it just watches you, updating its shift register and counter when the pin itself changes state
[13:33:32] <LeoNerd> The datasheet isn't awfully clear on that note
[13:34:36] <Strangework> Ahh! :O So I would only really need to flip the SCK pin in PORTX, and the hardware reads from the SCK pin in PINX?
[13:35:00] <LeoNerd> Indeedyt
[13:35:21] <Strangework> I've been reading through the datasheet - it's pleasant enough, though I don't know what information IT'S missing and what information I'M missing.. ;)
[13:35:45] <Strangework> Thanks for letting me bounce questions off ya, LeoNerd!
[13:35:46] <LeoNerd> Yeah.. the DS is a little terse on this
[13:36:33] <LeoNerd> http://pastie.org/10284963 <== my code I use for SPI and I2C master on USI
[13:36:50] <LeoNerd> in case that's useful to you. Yet another library ;) Just one I have written myself, so I know how it works
[13:37:35] <LeoNerd> You'll notice how much code it takes to actually *do* I2C over USI ;)
[13:37:40] <LeoNerd> As compared to the SPI which is quite tiny
[13:37:55] <Strangework> Eyy, good looks. :D I'll likely use it as a reference when I can't make any more progress on my own.
[13:37:58] <Strangework> hmmm
[13:39:08] <LeoNerd> The core distinction between mega's SPI and tiny's USI by the way, can be seen in the SPI code lines 35 to 41. Here I literally toggle the clock line 8 times
[13:41:01] <Strangework> Gosh. LOL
[13:42:32] <Strangework> I'll likely end up sticking with implementing i2c, since I don't want to stringing along more wires
[13:42:45] <LeoNerd> I2C is "OK" for slow rate things
[13:42:54] <LeoNerd> I just dislike it, avoid it if possible
[13:43:15] <Strangework> Why do you prefer SPI over I2C?
[13:43:33] <Strangework> I'd imagine with a dedicated hardware interface, writing I2C *should* be as simple as writing SPI
[13:43:55] <LeoNerd> Oh ignoring how easy or hard it is to implement on the MCU, I prefer SPI electrically
[13:44:04] <LeoNerd> E.g. it's a lot nicer on level shifters and isolators. Especially isolators
[13:44:12] <LeoNerd> All hardware lines are unidirectional
[13:44:38] <LeoNerd> Plus I much prefer running a real SS line to each slave, than trying to juggle the addresses
[13:44:54] <LeoNerd> You can also drive SPI at much faster bitrates
[13:44:58] <Strangework> What would isolators be used for in these protocols?
[13:45:19] <LeoNerd> If for whatever reason I need to entirely galvanic-isolate something
[13:47:34] <Strangework> Where does the increased ease in isolating SPI come from?
[14:28:01] <LeoNerd> The fact that each line is unidirectional
[14:28:10] <LeoNerd> So you can put easy things like optoisolators on it
[14:55:35] <bss36504> LeoNerd: Strangework: I agree about SPI being superior to I2C in terms of implementation ease, but when you have an AVR that uses SPI lines and a level shifter, you need to be careful that the MISO output can be tri-stated on the level shifter during programming, otherwise you wont be able to program.
[14:57:07] <Strangework> bss36504, would you explain why the MISO output would need to be tri-stated?
[14:59:10] <bss36504> Well, when the AVR is communicating to a slave as the master via AVR -> Level shifter -> Slave, the MISO line on the LS is an output, ie, low impedence and likely forcing a voltage one way or the other. When programming an AVR, the AVR is now the slave, and thus the same MISO line that was once an input on the AVR is now an output. When the AVR tries to send data back to your programmer on this
[14:59:50] <bss36504> line, the data will be "sucked into" the output of that level shifter. Really though, the level shifter is going to just hold the data line at either gnd or vcc, which will muck everything up.
[15:00:55] <bss36504> Best way to avoid this is to find a level shifter with an enable that will affect all pins, then use a resistor pull -up/-down to set it appropriately. Tie the line back to an AVR pin for software control, that way, even when the AVR isnt running, the level shifter will be controlled.
[15:03:10] <Strangework> Hm, that makes sense to me superficially.. I'll bear this in mind while I am studying over the weekend.
[15:04:17] <bss36504> Yeah, it's just a tip that has caused some issues for me in the past. Place AVR on board, programs fine. Place level shifter, can't program anymore. Gets a bit annoying when both chips are surface mount and you've gotta constantly heat them, clean the pads, resolder, etc.
[15:05:49] <Strangework> Dang, sounds pretty bitchy. I haven't yet progressed beyond breadboarding and will need to eventually look into more permanent solutions.
[15:41:07] <bss36504> Strangework: Yeah it can be a bit of a pain once you get on a PCB. Things are harder to debug, harder to fix. But usually its more rewarding to have something more permanent.
[15:42:28] <LeoNerd> It's nice to keep ISP available
[15:42:47] <LeoNerd> Late field upgrades, bugfixes,...
[15:51:00] <bss36504> I do most of my development on PCB. Many things dont have a through hole variant to be breadboarded.
[15:53:57] * LeoNerd nod
[15:54:00] <LeoNerd> Ohsure
[15:54:52] <Strangework> At the moment, I feel a bit limited needing to get DIP chips. Surface mount chips look hellish to solder
[16:00:24] <aandrew> surface mount (SOIC in particular) is VERY easy to solder. I would argue it's easier to solder than through hole
[16:00:59] <aandrew> now having said that there are lots of packages (leadless, ones with a pad UNDER the chip, stupidly fine pitch chips with leads, BGAs) which are definitely more challenging
[16:03:03] <LeoNerd> My next board will be my first QFN
[16:03:15] <LeoNerd> In fact it should arrive any day now
[16:10:14] <Strangework> SOIC, eh? I'll bear that in mind when I'm thinking of finally finalizing something. :)
[16:10:26] <Strangework> Do people say QFNs are easy to work with?
[16:12:07] <LeoNerd> QFN needs paste and a heatgun or oven really
[16:13:05] <aandrew> yeah they're difficult to do with an iron
[19:33:18] <apo_> you can make a basic oven pretty easily
[19:36:02] <Hexum064> Did you light your living room on fire again?