Back
[00:04:18] <rue_more> yea
[00:06:38] <Casper> yeah, I told you... sad isn't it?
[00:53:31] <Jartza> morning
[00:55:27] <ChrisSN> 'morning Jartza!
[05:13:37] <jaggzt> #DO NOT BURN FUSES ON THIS THING - IT DOES NOT HAVE ANY CRYSTAL
[05:13:39] <jaggzt> what's that mean?
[05:13:44] <jaggzt> for an attiny I think
[05:14:52] <DO9XE> it means: dont burn the fuses :D
[05:46:39] <Lambda_Auriga_> it means that if you set the fuses wrong it will no longer work.
[05:53:01] <jaggz> what does it mean that you cant vurn a fuse without a crystal?
[05:53:19] <jaggz> what avrdude programmer option do,we use for tom's?
[05:59:14] <Lambda_Auriga_> some of the fuses are used for setting clock options...like, the clock source for the processor.
[05:59:36] <Lambda_Auriga_> if you set those fuses incorrectly then it will require an external crystal or external clock source to run...and to be programmed
[05:59:44] <Lambda_Auriga_> avrisp2
[06:01:43] <LeoNerd> ISP needs a running CPU clock
[06:02:14] <Lambda_Auriga_> http://tom-itx.no-ip.biz:81/~webpage/boards/USBTiny_Mkii/USBTiny_Mkii_User_manual_index.php
[06:02:23] <LeoNerd> It's one of the reasons for wanting HVSP/PP sometimes
[06:03:06] <Lambda_Auriga_> tom's programmer does have a clock source pin but you will have to do a little thinking and work to use it.
[07:11:51] <vsync> Anyone played around with the nrf8001?
[07:12:39] <Lambda_Auriga_> not I.
[07:25:08] <vsync> meh
[07:25:35] <vsync> should read datasheets better I imagine. Turns out it uses lsb for spi
[07:25:54] <vsync> was throwing msb at it, for some weird conincidence i was getting replies that actually made sense
[07:26:02] <vsync> for, due to
[10:23:37] <vsync> guess it's time to start playing around with the nrfgo studio
[10:31:39] <jaggz> Lambda_Auriga_: LeoNerd: I don't understand about cpu clock and tom's programmer.. I use avrisp2 to flash? and what else do I need to do?
[10:31:55] <jaggz> I'm completely new to avr
[11:09:52] <vsync> jaggz: it's said to "emulate" the atmel one so i guess it ought to work out of the box
[11:10:01] <vsync> i.e. with atmel studio
[11:13:14] <LeoNerd> jaggz: I don't know "tom's programmer".. But I can tell you that ISP just talks to a running CPU, so you still need the real CPU clock running in whatever state it is in the real board.
[11:13:40] <LeoNerd> I.e. if the fuses say "crystal" then you need a real crystal; if the fuses say "external clock" then you need a real external clock signal, etc etc...
[11:29:11] <jaggz> I got an atmega32u4 .. it's on the leonardo micro, but it's convenient on its breakout board for me.
[11:29:31] <jaggz> In this case I won't be using tom's programmer. But if I go with a tiny85...
[11:29:56] <LeoNerd> I've forgotten the questoin
[11:34:19] <vsync> if you go with any avr they are preset to use the internal oscillators
[11:35:15] <vsync> i wonder if he was referring to generating a clock from the mcu in the programmer but that starts to get awfully fiddly
[11:37:01] <LeoNerd> Well.. *generally* you don't want to fiddle with the clock fuses because that might make it impossible to ISP the chip any more *while still in the board*
[11:37:35] <LeoNerd> E.g. if the board already has a crystal over the pins, then changing the fuses to use external clock would cause the clock to no longer work, and without a clock you can't ISP to fix it
[11:38:52] <vsync> get a function generator
[11:39:21] <vsync> and a pair of brains while you're at it
[11:40:46] <LeoNerd> Well sure you could apply some kind of clock signal to the chip, but you might e.g. have to desolder the crystal that's in the way of it
[11:41:10] <LeoNerd> The point of ISP is that it's incircuit - sometimes if you screw up the clock fuses you have to take the chip *out* of the circuit to fix it
[11:42:41] <vsync> use sockets
[11:42:52] <vsync> goes along with the whole use your brain -idea too
[11:43:03] <LeoNerd> Heh.. well, I usually work on SOIC14
[11:43:05] <LeoNerd> can't really socket those ;)
[11:43:13] <twnqx> ofc you can
[11:43:23] <vsync> you actually can but it's hella expensive
[11:43:28] <twnqx> not really
[11:43:32] <twnqx> about 1€
[11:43:37] <vsync> or well, sure for 14 pins
[11:43:40] <vsync> in any case
[11:44:02] <LeoNerd> SOIC14 sockets are physically larger than DIP14s
[11:44:03] <LeoNerd> :)
[11:44:08] <vsync> if you're prototyping, you're expected to screw up. prototyping best done with through hole, to be honest
[11:44:13] <LeoNerd> Yah.
[11:44:21] <vsync> for production, you are done with prototyping
[11:44:31] <LeoNerd> Well, unless you're working on a tiny841, which does'nt *have* a DIP14 package :(
[11:44:33] <vsync> and something like fucking the fuses up is, amazing
[11:44:52] <vsync> well, you can prototype it with a socket if you're dead scared of the clock fuse
[11:44:57] <twnqx> or chips that only exist as tqfp
[11:45:06] <LeoNerd> Oh.. personally I'm not scared in the slightest.. I have an HVSP burner :)
[11:45:09] <LeoNerd> (That I made)
[11:45:18] <vsync> twnqx: that's true
[11:45:24] <LeoNerd> I zeroed out all the fuses just to test it would work.
[11:45:29] <twnqx> even that only helps for the "fused away reset" case
[11:45:35] <LeoNerd> 0x00 0x00 0x00, then 0x01 0xfe 0xff
[11:45:38] <LeoNerd> All fine :)
[11:45:49] <twnqx> tied 0xff 0xff 0xff?
[11:45:54] <LeoNerd> (or whatever it was. I'm sure there's *a* bit that doesn't exist)
[11:46:02] <LeoNerd> Not all the bits are physically present
[11:46:22] <twnqx> i thought even hvsp required a clock
[11:47:00] <LeoNerd> Not a CPU clock, no
[11:47:11] <LeoNerd> HVSP is clocked entirely by the programmer clock line, the SCI
[11:48:28] <LeoNerd> Hardwarewise I *suspect* HVSP is implemented as two 11-bit shift registers in front of the "HVPP" IO lines on the AVR core, just to bring them out for low-pin devices.
[11:49:04] <LeoNerd> HVPP itself works entirely independently of the CPU core, poking directly at the flash/eeprom using its own logic
[11:50:02] <LeoNerd> Hopefully in the next few days, my HVSP controller boards will arrive, so I'll be able to finish my burner. A proper stk500 clone
[11:50:08] <LeoNerd> for doign HVSP on 8/14-pin ATtiny
[12:24:25] <vsync> twnqx: was it you who had been playing around with nrf chips?
[12:27:15] <twnqx> no
[12:27:33] <twnqx> well, i might have wanted to, but never did yet .p
[12:28:39] <vsync> hmh. annoying
[12:35:21] <NicoHood> assembler: may anyone explain me, why they used that trick for the operands here instead of using "+" for read and write? i simply dont get whats all about in/output operands and cobblers. may someone explain me this?
http://www.atmel.com/webdoc/AVRLibcReferenceManual/inline_asm_1io_ops.html
[12:46:22] <vsync> twnqx: the chip i'm using, 8001, uses lsb for spi bus. now, you need to create this setup file for it using the nrfgo studio, which is basically a bunch of bytes you need to throw at it through spi
[12:46:43] <vsync> i'm unsure are those bytes LSB already or do i need to swap them over... 8(
[12:55:05] <LeoNerd> vsync: I've been playing with nRF24
[13:08:58] <vsync> LeoNerd: yeah?
[13:09:28] <vsync> did you use a library or your own code?
[13:10:25] <LeoNerd> My own.. they're not hard
[13:14:31] <LeoNerd> It's just SPI really
[13:28:22] <vsync> LeoNerd: I know
[13:28:56] <vsync> 24 doesn't require to generate a config for service pipes?
[13:29:17] <vsync> and there are other options too, such as the oscillators
[13:31:28] <LeoNerd> er.. I don't recall having to do any of that :)
[13:31:55] <LeoNerd> Just set radio channel, address, bit rate. Optionally a few other bits but they're not necessary
[13:33:58] <LeoNerd> The only real gotcha is that the default config of autoretry/timeout makes no sense for long packets
[14:13:55] <vsync> LeoNerd: oh, the 24 isn't BLE
[14:14:13] <vsync> BLE stuff is a bit more complicated than straight up bt
[14:26:28] <vsync> 539 bytes of configuration data to send to the ble chip, hahah
[14:26:44] <vsync> with a single service pipe configured, lol
[14:36:31] <LeoNerd> vsync: Yeah; the 24 is its own custom but fairly simple packet-based transmission
[14:38:38] <vsync> yeah, checked it out
[14:38:45] <vsync> i'm moreso interested in ble
[14:39:38] <LeoNerd> Ah.. yeah; I want more range
[14:39:45] <LeoNerd> And I'm all powered, so I don't care about LE
[16:32:50] <bitd> Running my attiny at 8MHz on the internal RC. I see that a read (PB2) and a write (PA1) will take about 12uS.
[16:32:58] <bitd> Is that correct or is something going wrong?
[16:33:24] <LeoNerd> What do you mean a write takes 12uS?
[16:33:48] <bitd> I read a pin, depending on the state I set a pin to HIGH or LOW.
[16:34:38] <bitd> http://pastebin.com/JczEbUrA
[16:35:19] <bitd> So from input, to output that takes 12uS.
[16:35:39] <bitd> Verified by scope.
[16:35:54] <bitd> Is that normal response time for a 8MHz attiny?
[16:37:09] <malinus> bitd: you could optimze that with some bit magic
[16:37:23] <malinus> might be faster than branching
[16:38:51] <malinus> but you can easliy calcuate how many cycles that should take
[16:39:33] <bitd> Or I could just stick a 20MHz external on the board and be done with it >.>
[16:39:45] <malinus> or use interrupts
[16:40:00] <bitd> Even then the response time sucks..
[16:41:05] <LeoNerd> If you wanted something faster, maybe you want an FPGA?
[16:41:58] <bitd> No I'm obviously doing something wrong.
[16:43:00] <LeoNerd> Maybe you left the CKDIV8 bit set?
[16:43:23] <bitd> Checked that, but thanks for suggesting.
[16:43:32] <LeoNerd> 12µS at 8MHz suggests 96 cycles, but if it was 1MHz that becomes a somewhat more realistic-sounding 12 cycles
[16:44:14] <bitd> Lets try interrupts one more time with direct port manipulation.
[16:45:08] <malinus> well there is some logical delay, no matter the clock speed.
[16:45:30] <LeoNerd> Wellsure; but 96 cycles to copy a digital value from one pin to another sounds a little off
[16:45:45] <malinus> The datsheet will probably say how big, but it must be sub 1usec anyway
[16:59:55] <bitd> LeoNerd, malinus found it, apparently the IGBT I'm driving is causing the delay.
[17:00:41] <LeoNerd> Ah
[17:00:47] <malinus> IGBT?
[17:00:57] <LeoNerd> Insulated Gate Bijunction Transistor
[17:01:03] <malinus> ah
[17:01:03] <LeoNerd> Or.. something
[17:01:12] <bitd> Seeing 3uS when reading from a port directly.
[17:01:21] <bitd> I mean with the scope :)
[17:51:21] <Torx> Hi guys
[17:51:34] <Torx> Anyone work with Atmel Studio ?
[17:54:09] <Fleck> just ask your q.
[17:55:18] <Torx> I just get avr-g++ error
[17:55:23] <Torx> Fresh instalation
[17:55:32] <Torx> test.cpp: No such file or directory
[17:57:52] <Torx> http://prntscr.com/61yzsk
[18:02:12] <Torx> Atmel studio 6.2
[18:06:34] <Fleck> so, where is your test.cpp ?
[18:07:08] <Torx> in project folder
[18:07:14] <Fleck> full path please
[18:07:29] <Torx> D:\Projekty_Atmel\test
[18:08:13] <Fleck> but looks lin .././, should be ../../ no?
[18:08:37] <Fleck> or ../
[18:12:55] <Torx> Hmmm
[21:23:57] <anonnumberanon> I have been looking for a way yo use two uart terminals so i can receive sensor data and send it modified. How do you fo that on the 328p?
[21:26:49] <Casper> read, store, modify, write
[21:30:00] <anonnumberanon> its like saying turn the wrench to someone who asks how to weld on a turbocharger on his car