Back
[00:42:45] <inflex> anyone used USB3 sockets/plugs on their PCBs yet?
[00:43:02] * inflex has a very useful USB current meter that he uses every day multiple times, but I only have USB 2 ports
[00:43:52] <inflex> was thinking of upgrading to USB3 ports
[00:57:53] <inflex> ugh.. fun, 1mm pitch 9 pin underside SMD for the type-A, almost makes me think of going to PT :(
[01:03:41] <twnqx> 1mm
[01:03:43] <twnqx> is HUGE
[01:04:54] <twnqx> underneacth is s aproblem though
[06:48:52] <Ebola-C> hello
[06:49:02] <Ebola-C> anybody was playing with sound from DAC?
[06:57:21] <Juris4cm> anyone can help me with sound from dac?
[07:08:53] <Lambda_Auriga_> Ebola-C, they might if you ask a question they can answer.
[07:09:09] <Lambda_Auriga_> might be slow this morning though as it is sunday and people are sleeping in.
[07:51:02] <RikusW> megal0maniac: hi
[08:14:06] <DO9XE> Does anyone have an Idea, how I can force the SPI Clock high, befor pulling the /SS low at the beginning of a transmission? the way I tryed it doesn't work. Link to the code on github after request :)
[08:14:37] <Lambda_Auriga_> DO9XE, what mode are you running the SPI in?
[08:15:03] <DO9XE> master mode, with personal changed SPI Lib from LUFA.
[08:15:29] <Lambda_Auriga_> what SPI mode?
[08:15:33] <Lambda_Auriga_> not master/slave
[08:15:42] <DO9XE> https://github.com/LabConnect/Signalgenerator/blob/master/firmware/LUFA/Drivers/Peripheral/AVR8/SPI_AVR8.h#L247
[08:15:51] <DO9XE> this ist the part of the lib i use.
[08:16:14] <DO9XE> SPI_Init(SPI_SPEED_FCPU_DIV_16 | SPI_SCK_LEAD_RISING | SPI_SAMPLE_TRAILING | SPI_ORDER_MSB_FIRST | SPI_MODE_MASTER);
[08:16:20] <DO9XE> and this is my init :)
[08:16:50] <Lambda_Auriga_> what are CPIL and CPHA set to?
[08:17:02] <Lambda_Auriga_> CPOL
[08:17:20] <Lambda_Auriga_> spi control register.. SPCR.. bits 3 and 4
[08:19:11] <DO9XE> CPOL = 0, CPHA = 1
[08:19:13] <Lambda_Auriga_> if I am reading your code right then you are set to 0 and 0...SPI mode 0...
[08:19:20] <Lambda_Auriga_> ok..spi mode 1 then.
[08:20:13] <Lambda_Auriga_> that should have your SCK set idle high.
[08:20:24] <Lambda_Auriga_> wait..
[08:20:25] <DO9XE> i am interfacing a ad9833. this chip samples data on the falling edge und wants clock to be high, when /ss goes low
[08:20:32] <Lambda_Auriga_> nope..reading that backwards.
[08:20:47] <Lambda_Auriga_> for SCK idle high you need CPOL=1...so mode 2 or 3.
[08:21:14] <Lambda_Auriga_> so you want CPOL=1 and CPHA=0 for clock high sample leading edge falling.
[08:21:21] <Lambda_Auriga_> http://avrbeginners.net/architecture/spi/spi.html
[08:22:23] <Lambda_Auriga_> if you want sample data on falling edge, why do you have SPI_SCK_LEAD_RISING set?
[08:23:06] <Lambda_Auriga_> which, looks like it should be equal to CPHA = 0...
[08:23:13] <DO9XE> i observed the SPI on my Oszi and it made it look right :p
[08:23:25] <Lambda_Auriga_> I would say CPOL=1, CPHA=0 for what you are saying the chip wants.
[08:25:05] <DO9XE> http://labor19.net/Hendrik/AvhfRWzjxeI2qyfEiNSKYxPcrh3lnHkIpi8kR7qInrcz.jpg
[08:25:45] <DO9XE> this is what it looks right now. I'll try your suggestions at work in monday.
[08:26:02] <Lambda_Auriga_> that page explains the clock settings rather well I think.
[08:26:10] <Lambda_Auriga_> the one I posted from avrbeginners
[08:27:58] <DO9XE> I allready took a short look at it :)
[08:28:09] <DO9XE> ill read it properly :)
[10:12:48] <Ebola-C> hello!
[10:13:01] <Ebola-C> I got this DAC IC:
http://www.ti.com/lit/ds/symlink/tlc5615.pdf
[10:13:04] <Ebola-C> http://www.ti.com/lit/ds/symlink/tlc5615.pdf
[10:13:24] <Ebola-C> how do he knwo I am sending 12 bit data or 16 bit data?
[10:13:47] <Lambda_Aurigae> how much data are you reading?
[10:13:58] <Ebola-C> 8 bits
[10:14:16] <Lambda_Aurigae> then you are only seeing 8 bits of data.
[10:14:35] <Ebola-C> I just add 2 zeros in end
[10:14:41] <Ebola-C> so I get 10 bit data
[10:14:45] <Lambda_Aurigae> no
[10:14:53] <Lambda_Aurigae> you get 8 bits of data if you only read 8 bits.
[10:15:06] <Ebola-C> sorry where I read?
[10:15:15] <Lambda_Aurigae> where you read what?
[10:15:31] <Ebola-C> I need to send 8 bits to that DAC converter
[10:15:47] <Ebola-C> I add 2 bits in end so it can accept it as 10 bits
[10:15:49] <Lambda_Aurigae> oh,,it's a dac..
[10:15:57] <Lambda_Aurigae> sorry..I read ADC.
[10:16:21] <Ebola-C> But it accept only 12 bit data or 16 bit data
[10:16:47] <Lambda_Aurigae> so you need to send it 12 or 16 bits..however you have it set.
[10:16:48] <Ebola-C> I think I am unable to send 12 bit data with atmega8 SPI
[10:17:01] <Ebola-C> so I send 16bit data
[10:17:07] <Ebola-C> BUT!
[10:17:07] <Thrashbarg> correct. The SPI bus on the ATMega8 only sends in 8-bit words
[10:17:25] <Lambda_Aurigae> read the datasheet..
[10:17:25] <Ebola-C> how can DAC know I am sending 12 bit or 16 bit data?
[10:17:36] <Ebola-C> I readed it and don't get
[10:18:17] <Ebola-C> also there is written that one extra clock needs to be send after 16 clock cycles
[10:18:26] <Thrashbarg> Ebola-C: the section called Serial Interface explains it. Page 9
[10:19:02] <Ebola-C> do SPI interface of AVR send that one extra clock in end?
[10:19:25] <Thrashbarg> it also says the DOUT pin needs the extra falling edge. If you're not reading from the device you don't need it
[10:19:45] <Ebola-C> Thrashbarg I readed that section but don't get
[10:19:57] <Ebola-C> can you explain please how he know difference?
[10:20:08] <Ebola-C> he counts clk cycles or what?
[10:21:12] <Thrashbarg> Ebola-C: the DOUT pin is used so you can connect a few devices toghether and program them more easily. It seems you're only using one device so you don't need to worry about connecting DOUT... The "16 falling edges" bit refers to DOUT only
[10:21:18] <Thrashbarg> DOUT means Data OUT
[10:21:38] <Ebola-C> I understand
[10:21:46] <davor> is it possible to do a non-blocking LED fadeout with a 328?
[10:21:46] <Ebola-C> but how he know I send 12 bits or 16 bits?
[10:22:28] <Thrashbarg> Ebola-C: if you send 12 bits and /CS goes from low to high, it knows you've sent 12 bits. Send 16 bits and raise /CS from low to high tells it you've sent 16 bits
[10:22:52] <Thrashbarg> because it can count how many bits are sent, starting from when /CS goes from high to low
[10:23:08] <Ebola-C> so it just counts clk Thrashbarg?
[10:23:12] <Thrashbarg> yes
[10:23:58] <Ebola-C> Thrashbarg do AVR SPI interface by default send one extra CLK or I must manage it by myself?
[10:24:18] <Thrashbarg> they don't send an extra clock cycle. I don't think you need to...
[10:24:40] <Ebola-C> so it is needed only for dout yes?
[10:24:54] <Thrashbarg> it says "requires an extra clock width" not a clock pulse
[10:25:24] <Ebola-C> ok thx alot!
[10:25:32] <Thrashbarg> no problem
[10:33:17] * LeoNerd continues to battle the USI in I²C mode
[10:33:34] <LeoNerd> I had it working, except that my reads manage to lose the 8th bit of the input
[10:33:52] <LeoNerd> Attempting to fix that and now I'm losing all the ACK replies, so I never think anything is listening
[10:35:38] <Thrashbarg> you just *know* I2C is a European invention :P
[10:35:45] <Thrashbarg> overengineered...
[10:37:07] <Thrashbarg> if it were an Australian invention it'd have corrugated iron in it somewhere ....
[10:37:49] <LeoNerd> Philips (now NXP) originally...
[10:37:54] <Thrashbarg> yup
[10:37:57] <Thrashbarg> Dutch
[10:38:00] <LeoNerd> I have a vague recollection they're.. yah.
[10:38:42] <Thrashbarg> I repaired a West German open-reel tape recorder once. My god, that thing was complicated
[10:39:04] <Thrashbarg> tubes, but about half a dozen relays to set the operating modes
[11:12:33] <bitd> Hmmm my ATTINY85 seems to be running half speed.
[11:12:58] <bitd> I use a 16mhz crystal, set the fuses to use that, set the F_CPU as well.
[11:13:20] <bitd> And when i set it to internal RC, with 8mhz as FCPU, I have the same problem, half speed.
[11:13:58] <LeoNerd> clcok divider birts?
[11:14:06] * LeoNerd adjusts keyboard
[11:15:06] <bitd> No CKDIV8 is not set.
[11:15:11] <bitd> using this:
http://www.engbedded.com/fusecalc/
[11:15:44] <LeoNerd> But what about the other divider bits?
[11:16:00] <LeoNerd> The CKDIV8 fuse really just sets a powerup default for the main clock divider. That's under CPU control
[11:16:26] <LeoNerd> See the CLKPR register
[11:38:11] <aandrew> hm, my old avr-usb-jtag (olimex) is finally starting to fail me
[11:38:26] <aandrew> could not get a device (at90can32) to program correctly. dragon took care of it
[11:38:57] <aandrew> although I also discovered an error on my schematic. the RESET# line is being driven by a TCM809 supervisor IC; JTAG can't force reset because I did not include a series resistor on the TCM809 output
[11:39:18] <aandrew> mind you the olimex jtag adapter was always flaky
[11:41:58] <LeoNerd> Lambda_Aurigae: WRT our discussion yesterday on SPI; the Freescale document on it (
http://www.ee.nmt.edu/~teare/ee308l/datasheets/S12SPIV3.pdf) is quite illustrative. The primary thing is about data coming from the slave back into the master - the difference is whether the data is immediately available on its DO pin (into MISO) the moment the slave is selected, or whether you need to give it a clock pulse edge >>
[11:41:58] <LeoNerd> << first for that to happen.
[11:42:22] <LeoNerd> Lambda_Aurigae: Which is why it doesn't matter on a 74'595, because that is only ever written to, not read from by the MCU
[11:42:47] <Lambda_Aurigae> as I said yesterday, simple shift registers don't care.
[11:42:56] <Lambda_Aurigae> but, that makes more sense now.
[11:43:48] <LeoNerd> But yes in summary: outputting-only, there's only two SPI modes that matter. The reason there's four, is because there's a second difference that applies to input
[11:43:51] <Lambda_Aurigae> and a couple of things I saw yesterday kinda hinted at that, talking about delay before data is available or not.
[11:44:20] <LeoNerd> In (almost) total unrelated news: today I'm fighting with the USI
[11:44:34] <Lambda_Aurigae> that seems to be a common thing to do with USI.
[11:44:41] <LeoNerd> To do I2C. I managed to get it working... almost. I can output values fine, but when I read I manage to lose the MSB of the input.
[11:44:45] <Lambda_Aurigae> must be the US..everybody wants to fight anything with US in it.
[11:44:59] <LeoNerd> I can read values 0x00 to 0x7f correctly, but when the slave outputs 0x80 to 0xff, I read it as 0x00 to 0x7f a second time.
[11:45:45] <LeoNerd> I -think- this is because I'm shifting the SR at the wrong moment, and effectively only doing 7 shifts in the loop instead of 8. but I can't seem to find a place to just move the shift code to which doesn't then break output :(
[11:57:11] <Lambda_Aurigae> is the USI that much better than just bitbanging the whole thing?
[11:59:21] <LeoNerd> For SPI, yes.. it works a lot faster
[11:59:32] <LeoNerd> I'm not too sure about I2C though; at least for I2C master...
[11:59:48] <LeoNerd> Using USI for I2C slave does allow fancier things like interrupt-driven stuff
[11:59:50] <Lambda_Aurigae> I figured i2c would be faster with the USI but SPI would be about even.
[12:00:05] <Lambda_Aurigae> guess it does have a hardware i/o buffer.
[12:00:06] <LeoNerd> I2C is fairly slow on the wire
[12:00:27] <LeoNerd> The CPU has ample time to catch up to the wire, whereas I can output SPI faster with the USI than I think I could implement in software
[12:00:55] <LeoNerd> Fastest you can output in USI is fCPU/2, whereas I don't think you'd get even close to that in software bitbanging
[12:01:36] <LeoNerd> 8 times { clock low, leftshift data out, copy carry bit to output pin, clock high, read input pin to carry bit, leftshift data in }
[12:02:10] <LeoNerd> Whereas using the USI is 8 times { clock low, clock high }
[12:02:17] <Lambda_Aurigae> I'll stick with the larger chips with real SPI and i2c hardware.
[12:32:52] <LeoNerd> AHA!
[12:33:11] <LeoNerd> Got it - the trick is that in external clock mode, the USI module has a delay latch on one end of the shift register, whereas it doesn't in software clock mode
[12:33:55] <LeoNerd> Allllll the example code I can find online, is for external clock mode. In that mode it doesn't matter too much *when* you perform the shift operation; because the latch ensures data is correct. When you're doing software clock you have to perform shift at different times for read vs. write
[14:34:31] <rue_more> hmm
[14:34:54] <rue_more> you making a library for using usi for i2c?
[14:35:38] <rue_more> LeoNerd,
[14:38:39] <LeoNerd> Er... in a sense
[14:38:54] <LeoNerd> Only in the sense that I keep common .c/.h files sitting around so I can reuse them in other projects
[18:00:22] <LeoNerd> How expensive should I consider a call to a function pointer stored in a variable, on an ATtiny?
[18:00:45] <LeoNerd> It would make code structure somewhat neater if in the per-application startup, code could register callbacks with the base event loop
[18:04:58] <Tom_itx> probably $6 worth
[18:05:30] <vsync> Tom_itx: how are things in the promised land of rednecks
[18:05:46] <Tom_itx> i don't live that far south
[18:05:58] <LeoNerd> OK.. better question: choice a) register with callbacks in function pointers stored in variables. choice b) hacky preprocessor or build-time arrangements between library and application code.
[18:06:04] <LeoNerd> Pick one
[18:06:13] <vsync> c) do some real engineering
[18:06:25] <LeoNerd> Alright. Then explain that one more :)
[18:06:26] <Tom_itx> and yourself?
[18:06:39] <vsync> Tom_itx: i don't live that far... west
[18:07:45] <Tom_itx> i don't remember where you are..
[18:08:07] <vsync> under your bed
[18:08:15] <vsync> scary, huh
[18:08:29] <vsync> annnyway
[18:08:32] <Tom_itx> naw you should see what else lives there
[18:08:46] <vsync> there's bound to be monsters, always
