Back
[03:50:27] <skz81> <Jan-> actually with lithium ion the answer is... actually quite linear. >> Sure ? LiPos are not !!
[03:54:23] <skz81> http://www.powerstream.com/z/charge.jpg >> between 10% and 90%
[03:54:24] <superware> I'm trying to use the TWI on an ATmega328P, first without connecting anything to SCL/SDA, but after setting TWCR = TW_STOP; then while(TWCR & _BV(TWSTO)); is endless, any ideas?
[04:01:54] <superware> anyone?
[04:04:52] <Jartza> what's TW_STOP defined to?
[04:05:04] <Jartza> and you should connect something to SCL/SDA, at least pull-up resistors
[04:05:15] <Jartza> stop condition happens when both lines are pulled up
[04:05:41] <Jartza> so, when chip releases them. chip might assume some other device is still keeping them down because they're not pulled up?
[04:06:53] <superware> so 1k from SDA to VCC?
[04:07:25] <superware> (#define TW_STOP 0x94)
[04:15:46] <Jartza> 1k sounds a lot, but in theory yes
[04:16:06] <Jartza> 4.7k is quite good for fast i2c
[04:16:10] <Jartza> or 3.6k
[04:16:20] <Jartza> 10k for 100k speeds
[04:16:28] <Jartza> 100kHz
[04:18:04] <superware> "1k sound a lot"? but you suggest 10k for 100kHz speeds...
[04:20:26] <Jartza> yes, "lot", meaning, lot of pull
[04:20:32] <Jartza> low resistance = stronger pull
[04:21:33] <Jartza> I've used 3.6k for 400kHz speeds, it's working nicely
[04:21:51] <Jartza> depends of the overall capacitance of your i2c traces
[04:22:40] <superware> I see
[05:56:22] <superware> Jartza: I'm successfully detecting the device by using
http://pastebin.com/WiwPBBeB (addr 0xC4 returns "detected"), problem is I'm getting zero for any register read, any idea?
[05:58:23] <superware> Jartza:
http://pastebin.com/nYqyDise is the complete TWI code
[06:00:19] <superware> so any TWI_ReadRegister(0xC4, reg); returns zero...
[06:03:58] <Jartza> superware: the address of i2c device must be in the upper 7 bits and the lowest bit is read/write
[06:04:07] <Jartza> http://www.robot-electronics.co.uk/i2c-tutorial
[06:04:19] <Jartza> that's a pretty good tutorial
[06:05:11] <Jartza> but you need to set the lowest bit to 1 for reading.
[06:05:58] <Jartza> so, if your device i2c ID is 0x62, you shift that to left to get the 0xC4, right?
[06:06:09] <Jartza> for reading, the LSB must be 1
[06:06:12] <Jartza> so it becomes 0xC5
[06:10:14] <superware> TWI_ReadRegister(0x62, 0x41) is stuck on TWI_ReadNACK, TWI_ReadRegister(0xc4, 0x41) returns zero
[06:12:11] <superware> yes, the device 7-bit address is 0x62
[06:14:01] <superware> TWI_Start(busAddr + READBIT) makes the LSB 1
[06:25:54] <Jartza> logic analyzer would be great, so you could see what's going on in the bus itself
[06:27:02] <superware> I think there're problems in the code
[06:27:09] <superware> (the lib I've sent here)
[06:27:38] <superware> no logic analyzer here, unfortunately :)
[07:10:10] <dunz0r> Yep there is.
[07:10:24] <dunz0r> Oh wow. I was scrolled back. Never mind.
[07:10:31] <Lambda_Aurigae> oops.
[07:26:29] <Jartza> superware: sorry, don't have time currently to look too deep into that :(
[07:26:44] <Jartza> would help tremendously if we knew what the device is :)
[07:27:34] <superware> Jartza: you're right, it's a LIDARLite v2 (see
https://github.com/PulsedLight3D/LIDARLite_v2_Arduino_Library)
[08:10:14] <superware> Jartza: do you know it?
[08:12:54] <Jartza> nope
[09:00:05] <superware> Jartza: can you please check
http://www.robotshop.com/media/files/pdf2/pli-03_detailed_register_definitions.pdf I write 0x04 to register 0x00 to "take acquisition", but I can't find where the acquisition value is stored. here
https://github.com/PulsedLight3D/LIDARLite_v2_Arduino_Library is says "Read two bytes from register 0x8f and save" but when I do that I'm getting quite random results. any idea?
[09:33:15] <superware> Jartza: thank you for your help.
[09:37:31] <Jartza> hmmh
[09:37:55] <Jartza> random results might indicate some trouble, but unfortunately I'm currently busy with other code, I don't want to mess my mind with two codes simultaneously :)
[09:38:00] <Jartza> maybe I'll look at that later
[12:27:47] <lowin> Am I not allowed to use cbi on GIFR?
[12:29:23] <lowin> guess not
[13:01:27] <PoppaVic> ok, so.. Silly question time... Reading the 328p datasheet. (assuming much I read applies to the 1284p as well).. Section 27.8.2 Filling the Temporary Buffer (Page Loading)
[13:01:58] <PoppaVic> " Note that it is not possible to write more than one time to each address without erasing the temporary buffer" - Umm.. Parsing that hurts.
[13:03:16] <PoppaVic> are they saying stuffing a new value to word <x> can only occur once? Or, are they saying writing to X, X+1, X+2, ... isn't possible?
[13:05:33] <twnqx> i'd say the "to each address" is pretty clear to mean "same address"
[13:06:33] <PoppaVic> twnqx: so, the hw is designed such that *x=1; *x=2; fails? (like a hidden bit is flicked to say 'set, ignore changes' ?)
[13:06:58] <twnqx> as retarded as that sounds, that's how i read it, yes
[13:07:27] <PoppaVic> OK, so you can address each word in that buffer once for a store, but not twice. I think.
[13:07:48] <twnqx> is there also a requirement on writes being sequential and not random?
[13:07:56] <twnqx> in which case it "kind of" makes sense...
[13:08:58] <PoppaVic> not that I saw, which is why I was curious how to translate that.. Seeing as, you'd work up what you want to write in that page. (well, ok - in RAM to throw at that page) - and I hoped I could just spew to it - and not fool around for every word.
[15:59:39] <Jan-> hihi avr people
[16:00:17] <Jan-> I have a cunning solution to a problem but it seems a bit crazy so I thought I'd run it past you guys to see what you thought.
[16:00:46] <Jan-> We want to use an AVR to supervise a battery pack. This means the device will need to be permanently connected to the pack, which would normally run the batteries down over (a lot of) time.
[16:01:56] <Jan-> So, to avoid that, we were going to have one of those high-value memory backup capacitors which would store just enough energy for the AVR to wake itself up and turn on main power via a transistor, which would power the AVR conventionally and recharge the capacitor. Then, we can completely disconnect our electronics from the battery when they don't need to be running.
[16:01:58] <Jan-> Whaddayathink?
[16:04:57] <Emil> Jan-: why?
[16:05:20] <Emil> And are you transmitting information from the avr somewhere
[16:05:25] <WormFood> supervise a battery pack? Why not babysit it instead? :P
[16:05:29] <Emil> or is it purely to monitor the device
[16:05:38] <Emil> WormFood: no, why do it in such a convoluted way
[16:06:15] <Fleck> charging cap also takes energy :D
[16:06:17] <WormFood> Maybe he likes Rube Goldberg
[16:07:04] <WormFood> Why not use a flux capacitor?
[16:07:37] <Fleck> why not use solar panel :D ?
[16:07:57] <Emil> Jan-: do you need to transmit that data somewhere
[16:08:33] <Emil> or do you simply go "hey, is the voltage under this much over a long term period?"
[16:08:43] <Emil> and then don't allow power through the mosfet
[16:11:00] <Jan-> It has several functions.
[16:11:07] <Jan-> One of them is tracking the voltage to give an approximate state of charge.
[16:11:18] <Jan-> This means waking up once every - well - depends on the load, but once every few tens of seconds
[16:14:58] <Emil> Jan-: if you want a proper battery protection circuit go with a chip / ready module. They are good and already exist. They (usually) handle charging for you which is convenient
[16:15:21] <Emil> but
[16:15:26] <Emil> if you want to go with an avr
[16:15:44] <Emil> what other things must the battery supervisor do?
[16:23:50] <JoeLlama> SpaceX Launch Live in 40 Minutes!
http://tinyurl.com/zmkuwho
[16:24:21] <Emil> Uuuh
[16:24:29] <Emil> JoeLlama: thanks for the notification!
[16:25:27] <JoeLlama> oh sure (:
[16:36:25] <Casper> Jan-: what voltage on the batt pack?
[16:37:13] <Casper> if it is between 1 cell lipo? if so I have a solution that you may like...
[16:38:48] <Jan-> it's four cell lithium ion.
[16:39:00] <Jan-> there are chips which will do it, but we don't think we can easily implement any of them
[16:40:56] <Jan-> essentially the idea was to prevent over-discharge.
[16:41:06] <Jan-> but while we're at it, some sort of rough approximated countdown timer would be nice.
[16:43:03] <Jan-> since lithium ion has quite a big voltage swing as it discharges, that's probably doable.
[17:00:39] <WormFood> Jan-, there are ic monitoring/charging IC, that already exist. There is no need to reinvent the wheel.
[17:01:00] <Emil> Yeah
[17:03:26] <WormFood> And, most likely these ICs will do a better job than you can with an AVR
[17:03:52] <WormFood> Those ICs are really cool. I've checked out their datasheets.
[17:03:53] <Jan-> sure, we looked at two of them
[17:04:06] <Jan-> one of them is only available in a 14 pin package 3mm square, which isn't very practical
[17:04:12] <Jan-> the other one, the TI one, is just insanely complicated
[17:04:14] <Jan-> it'd take months
[17:04:25] <Jan-> if you can find one that doesn't have either of those problems I'll look at it.
[17:04:45] <WormFood> and you think you can do the same job, in less time?
[17:04:58] <Jan-> No, I think I can do a good-enough job in less time.
[17:05:05] <Jan-> Or at least, I have better chances.
[17:06:06] <Jan-> the TI one is complicated to the point where I'm not sure that we could actually make it work.
[17:12:40] <Casper> shouln't be that complicated
[17:13:04] <WormFood> "We" who? You have a mouse in your pocket? :P
[17:13:12] <Jan-> I dunno. There's a lot of sophistication in a lot of them.
[17:14:17] <Jan-> it's quite hard to work out exactly how much power there is left in a battery, there are a million variables.
[17:16:55] <Emil> Jan-: ...
[17:17:32] <WormFood> You've investigated how many different ICs? 2?
[17:18:05] <WormFood> There are like 50 of them, and you've decided it's too hard to use the chip, or the chip is the wrong physical size, based on a sample size of 2?
[17:18:27] <aandrew> 1 cell lipo is trivial to charge. there are SOT23-5 devices to do it cheaply and safely
[17:18:35] <WormFood> It sounds to me, like you really want to attempt this on your own.
[17:18:39] <aandrew> 4 cell yeah things start getting tricky
[17:18:43] <Emil> Jan-: anycase, if just low voltage detection is enough, use some attiny with voltage dividers and sleep for most of the time
[17:19:59] <Emil> also turn most of the stuff in the avr off
[17:20:12] <aandrew> what's tricky about over-discharge detection on a multi-cell pack?
[17:20:49] <aandrew> resistor divider ladder, measure each cell and if any falls below your threshold (~3.4 if you're conservative, maybe down to 2.5 if you're aggressive or have specific cell datasheets) you shut down
[17:21:33] <Emil> I'd shut down at 3.2V/cell
[17:21:37] <Emil> or 3.1
[17:21:49] <Emil> if it is a continuous low passed voltage
[17:21:54] <aandrew> like I said, it depends on the specific tech and how hard you want to drive the cells
[17:22:38] <Jan-> these will probably be decent panasonic cells
[17:22:44] <Jan-> hence our keen-ness not to kill them :D
[17:23:03] <aandrew> well, you could probably contact panasonic with your application and get a really good answer
[17:23:05] <Emil> they probably have their own integrated protection circuits
[17:23:11] <aandrew> they'll likely want to know discharge rate and ambient temp
[17:23:13] <Jan-> the issue really is not so much the code, I can do that, it's how we power the AVR without having an LDO permanently hung across the battery.
[17:23:38] <Jan-> the discharge rate and temperature are not known; it's a general purpose battery. that's one reason it's complicated.
[17:23:39] <Emil> Jan-: mate, if you don't draw current from your ldo, it won't use power almost at all
[17:24:04] <Jan-> I'm not sure.
[17:24:08] <Jan-> Is there a specific type I should look for?
[17:24:24] <aandrew> 555 timer circuit that runs off the "bare" cell voltage and periodicailly enables a fet that supplies the LDO/switcher; CPU comes up and latches the fet so it stays on and then "lets go" when it wants to be disconnected
[17:24:44] <aandrew> Jan-: then you have to do characterization or be conservative
[17:24:45] <Jan-> are 555s low current?
[17:24:49] <aandrew> they can be
[17:24:59] <Emil> Jan-: do you understand how an ldo works?
[17:25:00] <Jan-> aandrew: my plan was to do a characterisation and record a decreasing voltage curve
[17:25:01] <aandrew> one shots
[17:25:02] <WormFood> depends on the 555
[17:25:13] <aandrew> time to get the boys
[17:25:14] <aandrew> later
[17:25:15] <Jan-> with lithium cells apparently that's "reasonably good"
[17:25:25] <WormFood> aandrew, is that code for something?
[17:25:40] <Emil> Jan-: really, do you understand how an ldo works?
[17:25:58] <Jan-> Broadly.
[17:25:59] <Emil> or, actually, have you looked at any ldo wirings
[17:26:53] <Emil> The point is that they really don't draw much current if you don't draw any
[17:27:01] <Jan-> Okay.
[17:27:51] <Jan-> I wonder if aandrew's 555 idea is any better.
[17:27:58] <Jan-> Or at least, significantly better, for its complexity.
[17:28:13] <aandrew> WormFood: hah, no, boy is paying hockey and his practice is over
[17:28:49] <Emil> Jan-: the 555 solution is super easy but probably draws more current than the ldo with a mostly sleeping avr
[17:29:15] <Emil> The 555 solution is also not strictly speaking predictable
[18:34:45] <superware> I'm trying for hours to get an ATmega328P talk DMX512 through a MAX485, but "no blink" (literally) nothing works. The DMX512 device definitely works, here is the code:
http://pastebin.com/BsPHRdXb
[18:41:36] <liwakura> superware: PORTB0 is the same as PB5 ?
[18:43:00] * WormFood doesn't look, because superware used pastebin.com
[18:43:17] <superware> liwakura: I'm not sure what you mean, I can't find any PB5 for this chip...
[18:43:28] <Emil> superware: wat
[18:43:44] <liwakura> ??
[18:43:48] <WormFood> not even a little PB5?
[18:43:56] <liwakura> superware: the io.h for the atmega328p has an PBn for me
[18:43:57] <WormFood> by the way, what is PeanutButter 5 mean?
[18:45:03] <learath> it's protection from the demons alergic to peanuts.
[18:45:13] <WormFood> good answer
[18:45:53] <WormFood> I made a peanutbutter and kentucky jelly sandwich once. It was terrible.
[18:46:28] <liwakura> okay, now im interested
[18:46:47] <superware> liwakura: I swear, Atmel Studio 7 with #include <avr/io.h> doesn't know any PB5
[18:46:54] <liwakura> superware: i grepped over my include file, and i could not find the PBn consts for that device, but the PORTBn
[18:47:10] <liwakura> i have literally no idea where the PBn constants that i use everyday are defined
[18:47:30] <Emil> superware: you don't need uint16_t if you use do { ... } while (n--);
[18:47:35] <Emil> wait
[18:47:48] <Emil> nevermind, can't reason while tired
[18:47:49] <Emil> :D
[18:48:12] <liwakura> superware: also, your code looks fine otherwise
[18:48:34] <superware> really? I understand DMX512 is very time-strict
[18:48:39] <liwakura> oh
[18:48:53] <Emil> superware: bytheway, if you are using interruopts
[18:49:01] <liwakura> you have a 16 MHz quartz on board?
[18:49:02] <Emil> you need to call sei() after init
[18:49:02] <superware> I'm not
[18:49:11] <superware> (yet)
[18:49:11] <Emil> superware: then why are calling cli? :D
[18:49:15] <Emil> or sei
[18:49:18] <superware> I'm running at 20MHz
[18:49:26] <superware> prepare for the worst
[18:49:31] <Emil> have you spesified F_CPU?
[18:49:45] <liwakura> superware: the for & PORTB code could take up 1 or 2 us
[18:50:09] <liwakura> maybe you should try using raw assembler instructions to have more control over the timing
[18:50:17] <superware> yes, in "AVR/GNU C Compiler" -> Symbols -> F_CPU=20000000
[18:50:35] <liwakura> or maybe find a trick using some hardware peripherals like SPI or USART of writing that byte out
[18:50:49] <superware> I need the USART for something else...
[18:50:52] <Emil> Yeah, I'd definitely use spi if the clocks match
[18:51:02] <Emil> but anycase, if you are sending bytes out and timing is important
[18:51:12] <Emil> I'd break the byte out to 8 temporary values
[18:51:20] <Emil> and then unroll the for loop
[18:51:54] <WormFood> Can't you instruct the compiler to do that? (I'm 99% sure, you can)
[18:52:02] <Emil> WormFood: yeah, OS3
[18:52:06] <Emil> Os3*
[18:52:12] <Emil> but you might not want that everywhere
[18:52:14] <superware> tried all optimizations
[18:52:31] <superware> the weird is nothing even blinks
[18:52:31] <liwakura> uhm. the dmx protocol is 8N2 UART with 250000 baud
[18:52:44] <WormFood> no, not a command line option. I mean to instruct the compile to unroll a specific loop
[18:52:51] <WormFood> 2 stop bits?
[18:52:57] <liwakura> WormFood: says the wiki page
[18:53:28] <Emil> WormFood: :o
[18:53:31] <Emil> teach me master
[18:53:55] <superware> WormFood: I'm looking for my code's "2 stop bits"
[18:53:58] <WormFood> I'd have to look at the gcc docs again. I could be wrong. Hold on, and I'll check.
[18:54:23] <WormFood> I actually have a printer, that needs 1.5 stop bits. Fuckin' weird, eh?
[18:55:09] <liwakura> superware: its just the thing, the UART protocols are very timing sensitive. At 250000 baud, you should use the USART device of your atmega328p
[18:55:32] <superware> but I need the USART for later
[18:55:34] <WormFood> absolutely. No point in doing that shit in software, unless you absolutely need to.
[18:55:47] <WormFood> get an AVR with 2 UARTs
[18:55:54] <liwakura> hm.
[18:56:02] <liwakura> WormFood: you did VGA on an attiny
[18:56:09] <superware> 250kHz with 20MHz shouldn't be that difficult
[18:56:10] <WormFood> I did not
[18:56:11] <Emil> WormFood: pls
[18:56:16] <liwakura> WormFood: oh, sorry
[18:56:18] <Emil> you can easily bitbang that 250kHz
[18:56:22] <liwakura> mixed you up
[18:56:37] <liwakura> superware: please consider using assembler instructions for that
[18:56:43] <Emil> liwakura: no need :D
[18:56:59] <Emil> just unroll the loop and separate the bits into eight variables before sending
[18:57:16] <liwakura> Emil: you have <2% timing tolerance
[18:57:22] <Emil> liwakura: so?
[18:57:30] <liwakura> you don't know what compiler optimisations will be made
[18:57:40] <liwakura> every single instruction would count
[18:57:42] <WormFood> The higher the speed, the tighter the tolerance
[18:58:00] <liwakura> so, there is no way around assembler instructions
[18:58:25] <Emil> liwakura: check the assembly and I'm pretty sure that the avr-gcc is stupid enough not to optimise everything
[18:58:31] <WormFood> hhhmmm...ARM supports 1/2 precision, floating point (16-bits). That's rather cool. I wished the AVR did that too.
[18:58:44] <WormFood> Atmel has a software UART, in both C and ASM
[18:59:07] <liwakura> Emil: inserting random "nop"'s until the timing fits?
[18:59:22] <Emil> liwakura: no.
[18:59:27] <WormFood> And, if you want to use that, in assembly, I have some optimizations for it. Smaller code, and less cycles. Not a huge difference, but when you're low on cycles (which you're not), every bit counts.
[18:59:36] <Emil> Simply by using the _delay_... functions
[18:59:39] <Emil> with volatile variables
[18:59:58] <Emil> The avr gcc is smart enough not to optimise those away
[19:00:03] <Emil> since it is apparent it is not wanted
[19:00:37] <liwakura> Emil: you wont know how many cycles the code around those those delays will take
[19:00:42] <Emil> liwakura: I do
[19:01:14] <liwakura> by counting them from the compiled code?
[19:01:25] <Emil> liwakura: from avr-gcc documentation
[19:01:28] <superware> found this
http://www.erwinrol.com/dmx512/
[19:02:17] <liwakura> Emil: proove you are not trolling.
[19:03:19] <Emil> Wat. Prove yourself that you can't do it.
[19:04:45] <superware> am I the proof?
[19:04:49] <liwakura> superware: the reset code at the beginning worries me a bit
[19:05:22] <WormFood> Emil, I think I'm 1/2 wrong. There is no attribute to tell it to unroll a loop directly, however there is a nifty "optimize" option, that can set the optimization differently for one specific function. That could be set, to force the loop to unroll, I believe.
[19:05:28] <superware> although I know for a fact that 8 years ago I did manage to do this with a 16MHz AVR, bit-banging
[19:05:42] <liwakura> superware: its definitely possible, yes
[19:05:49] <WormFood> Emil, check out this. You'll probably learn lots of new things on this page.
https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/Common-Function-Attributes.html
[19:05:51] <liwakura> but it will be a hassle to get the timing right
[19:06:28] <Emil> WormFood: Interesting
[19:06:30] <Emil> I'll take a look
[19:06:33] <superware> liwakura: I guess the receiver can make SOME adjustmenets
[19:06:44] <WormFood> actually, they specifically say, "This can be used for instance to have frequently-executed functions compiled with more aggressive optimization options that produce faster and larger code, while other functions can be compiled with less aggressive options. "
[19:06:51] <liwakura> <2% is common for UART, superware
[19:07:27] <WormFood> liwakura, why don't you look at the Atmel datasheets, or my AVR baud (bit) rate calculator
[19:07:43] <WormFood> 2 stop bits, makes it have a tighter tolerance.
[19:07:58] <liwakura> yeah, i just knew it was around 2%
[19:08:07] <WormFood> That's totally wrong
[19:08:15] <liwakura> no
[19:08:41] <WormFood> You have anything to backup your claim?
[19:08:52] <liwakura> you said "totally"
[19:09:08] <WormFood> well, it'd be right for one specific setting.
[19:09:16] <liwakura> so, you were wrong
[19:09:17] <WormFood> just like a clock that doesn't work, is right twice a day
[19:09:18] <liwakura> gotcha
[19:10:10] <liwakura> 1 thing, if you just tell ppl "you are wrong", you will get weird behavior, if not dislike.
[19:10:30] <liwakura> whatever, what i actually wanted to say
[19:10:39] <superware> BTW, I might be wrong with wiring the MAX485 (
http://ecee.colorado.edu/~mcclurel/max485ds.pdf), mainly RO/RE/DE...
[19:10:51] <liwakura> 20Mhz and 250k baud means 80 cycles per bit
[19:11:44] <superware> right, 4us*20
[19:11:47] <liwakura> and if you are 2 or 3 cycles off
[19:12:00] <WormFood> 8N1 has a recommended max error rate, of 1.0 to 1.5%
[19:12:06] <WormFood> er, I mean, 8N2
[19:12:08] <liwakura> you get like, 3.5 % error rate or so
[19:12:35] <WormFood> actually, if you're using the uart, the error rates may be different.
[19:12:37] <liwakura> maybe being one cycle off would still work
[19:12:41] <WormFood> I mean, software uart
[19:12:53] <WormFood> one cycle off would still work.
[19:13:10] <liwakura> its 1%
[19:13:16] <WormFood> absolute max error rate is about 3.4%
[19:13:29] <liwakura> it always depends on the transmitter and receiver
[19:13:42] <WormFood> it depends on how it's sampling the bits
[19:13:53] <liwakura> and the accuracy of the quartz.
[19:13:59] <WormFood> which is why the error rates vary, depending on if you're using U2X mode, or not
[19:15:08] <WormFood> Anyways, the datasheets have it, under a table titled "Recommended maximum receiver baud rate error for normal speed mode" (and double speed mode)
[19:15:08] <liwakura> mh.
[19:15:49] <WormFood> I actually understand the uart very well, and how it works and everything. It's actually quite simple.
[19:16:09] <liwakura> the device or just the protocol?
[19:16:15] <WormFood> since the clock is internal, and has to be reproduced on the other end, the amount of error depends on the number of bits you have.
[19:16:18] <liwakura> *the AVR device
[19:16:35] <liwakura> hm, i know. no need to discuss that now
[19:16:52] <WormFood> the protocol, but also the technical details of how the hardware works.
[19:17:29] <WormFood> if you're sending 7 bit data, without parity, you'll have more tolerance, than if you're sending 9 bits, with parity.
[19:17:55] <liwakura> hm, i know. no need to discuss that now
[19:18:11] <WormFood> and, I was wrong. 8N2 would be about 1.5 to 2.0% max recommended error rate
[19:18:28] <liwakura> oh no!
[19:18:35] <liwakura> there my 2% appear!
[19:18:42] <liwakura> what a coincidence!
[19:19:04] <WormFood> max error rate is about 4.25%
[19:19:41] <theBear> but involving theBear can drive it up at least a few % for zero change in coding <grin>
[19:21:15] <liwakura> WormFood: could he use the SPI on 16 Mhz with /64 prescaler to generate his output?
[19:21:29] <liwakura> would match the bitrate exactly
[19:21:46] <WormFood> I don't know the hardware that he's driving.
[19:21:49] <liwakura> but im not sure about how well the peripheral bits will match
[19:22:08] <liwakura> i just want to know if you can emulate outgoing uart with spi
[19:22:16] <liwakura> and just not connecting the clock
[19:22:48] <WormFood> I don't know what protocol SPI uses?
[19:22:56] <Emil> WormFood: wat
[19:22:58] <WormFood> is it the normal 8N1 serial protocol?
[19:23:09] <Emil> wat :D
[19:23:17] <liwakura> nah, its SPI
[19:23:17] <WormFood> I don't know the technical details of SPI, just a general overview
[19:23:22] <liwakura> mh.
[19:23:26] <Emil> Hooooow :D
[19:23:54] <Emil> anycase, I think SPI would work just fine
[19:24:16] <liwakura> the start bit...
[19:24:29] <liwakura> mh.
[19:24:33] <liwakura> maybe there is a way
[19:24:37] <Emil> liwakura: you could bitbang it
[19:24:48] <Emil> manually do it*
[19:24:59] <liwakura> mh.
[19:25:06] <WormFood> doesn't SPI use the USART hardware?
[19:25:15] <liwakura> not on the atmega328p
[19:25:24] <superware> if I could just make it blink, I could at least start tweaking toward a more precise timeing
[19:25:51] <liwakura> superware: would you post your code again?
[19:25:52] <WormFood> Alright. I'm looking at my mega48/88/168 datasheet.
[19:25:55] <Emil> m328p has separate systems for u(s)art, spi and i2c <3
[19:26:01] <Emil> WormFood: not m328p?
[19:26:13] <liwakura> Emil: they are the same
[19:26:17] <superware> http://pastebin.com/BsPHRdXb
[19:26:19] <liwakura> beside from the memory sizes
[19:26:22] <WormFood> well, the uart can do an spi mode, on the mega'8 models
[19:26:52] * WormFood can't see, because superware used pastbin.com.
[19:26:57] <Emil> liwakura: wat
[19:27:10] <Emil> USART SPI and TWI have their own blocks
[19:27:23] <liwakura> yeah, cool chip
[19:27:31] <liwakura> superware: where should the blinking happen?
[19:28:32] <liwakura> PB0 is the only pin you drive, and it gets driven faster than 30Hz, so it will appear dim
[19:28:36] <superware> I'm setting all 512 slots/channels to 255, something should catch up
[19:28:39] <liwakura> if you attach a led
[19:29:08] <liwakura> ah
[19:29:19] <superware> I measure about 4V between PB0 and GND
[19:29:27] <liwakura> superware: since your timing is broken, the dmx devices will most likely not accept your data
[19:30:25] <liwakura> you should delay 4 us minus the time the other instructions in the loop tsake
[19:30:27] <liwakura> *take
[19:31:34] <liwakura> so, if those instructions take 0.5 us, which they most likely exceed, each bit takes 4.5 us
[19:32:00] <superware> "most likely exceed"??
[19:32:38] <liwakura> i havent checked yet
[19:33:04] <liwakura> i would compile it here and just count the cycles
[19:33:26] <superware> 20MHz is cycle per 0.05us
[19:34:03] <liwakura> Every bit takes 4 us, right?
[19:34:07] <superware> right
[19:34:20] <liwakura> so if you wait 4us AND do some calculations within each byte
[19:34:28] <liwakura> *bit
[19:34:34] <liwakura> each bit will take definitely MORE than 4us
[19:36:20] <superware> will for (uint8_t mask = 0x01; mask; mask <<= 1) be better than for (uint8_t i = 0; i < 8; i++)? because then b & mask
[19:37:05] <liwakura> thats not the point
[19:37:14] <superware> why not? I saved a few cycles there
[19:37:33] <liwakura> you have 80 cycles for each bit
[19:37:57] <liwakura> and you waste 80 cycles for each bit in your delay functions, PLUS doing calculations like incrementing the counter
[19:39:07] <liwakura> you just have to delay less
[19:39:10] <superware> what do you suggest?
[19:40:34] <liwakura> also, since you have to be within a window of 0.3 us to hit, the delay_us is just to inaccurate
[19:41:02] <superware> you mean too?
[19:41:27] <WormFood> too be, and too hit? :P
[19:41:52] <liwakura> hm, im not sure if english works that way
[19:42:24] <WormFood> obvious typo is obvious.
[19:42:26] <liwakura> superware: would you upload your code again? it got expired before i could view it again
[19:43:10] <liwakura> i wanted to compile it myself
[19:43:38] <liwakura> i usually view the generated assembly to see how it turned out to be
[19:43:41] <superware> http://pastebin.com/Cds2be40
[19:43:59] <liwakura> thx
[19:44:17] <WormFood> I can't see the code, so I won't comment on it.
[19:45:05] <superware> no, thank you
[19:45:35] <liwakura> WormFood:
https://w1r3.net/UqkVTawk.txt
[19:45:41] <liwakura> ready to curl?
[19:49:18] <liwakura> superware: yeah, your loop is actually ~4.7 us long
[19:49:38] <liwakura> the loop code takes ~0.7 us, approximately 15 cycles
[19:50:51] <superware> and _delay_us(1) actually takes 1us? :)
[19:51:53] <liwakura> i assume, yes. by the cycle
[19:53:03] <superware> so how can the loop be improved?
[19:53:43] <superware> maybe do _delay_us(4); and add some NOOP?
[19:53:47] <superware> I mean (3)
[19:55:30] <liwakura> yes. but you'd have to count the exact cycles your C code takes with your compiler
[19:55:57] <liwakura> the calculations and the delay must add to 80 +/- 2 cycles
[19:56:19] <liwakura> thats the only condition.
[20:00:48] <liwakura> im currently working on an assembler version of that code snipped
[20:00:51] <liwakura> *snippet
[20:01:57] <superware> you mean the whole code??
[20:02:09] <liwakura> no
[20:02:29] <liwakura> only that function
[20:03:26] <superware> liwakura: please see
https://github.com/Cathedrow/DmxSimple/blob/master/DmxSimple.cpp
[20:03:57] <WormFood> actually, if you want to bitbang a serial port, in C, then you probably want to use interrupts to get your timing right.
[20:04:09] <superware> dmxSendByte
[20:04:28] <superware> you might have a point there
[20:04:35] <liwakura> superware: thats exactly what im trying to create right now.
[20:04:40] <liwakura> just use that function instead.
[20:04:49] <superware> interrupts isn't exactly bitbanging
[20:05:26] <liwakura> superware: he was referring to the timer interrupts to get the right moments for writing the pins
[20:05:27] <WormFood> yeah it is
[20:05:47] <superware> right, sorry
[20:06:24] <WormFood> d'oh. Yeah, timer interrupts.
[20:08:19] <superware> liwakura: checking that function
[20:09:39] <superware> liwakura: do you happen to know what's dmxPort = portOutputRegister(digitalPinToPort(dmxPin)); and dmxBit = digitalPinToBitMask(dmxPin); ?
[20:10:24] <liwakura> its specific to that cpp program
[20:11:25] <liwakura> https://w1r3.net/KFthGMEn.txt
[20:12:08] <liwakura> i hardcoded the 2 bitmasks and the PORTB definition
[20:12:24] <superware> :)
[20:12:43] <superware> so now it's faster :)
[20:12:56] <superware> (not in the good sense)
[20:13:06] <liwakura> not not about being faster, its about being timely
[20:13:20] <liwakura> *its not
[20:13:31] <liwakura> i also havent tested the code
[20:13:37] <liwakura> but it compiles
[20:14:46] <liwakura> i should seek an employment for doing such things
[20:15:56] <liwakura> also, i haven't counted cycles and im too tired to do it now
[20:15:57] <superware> no joy :(
[20:17:32] <superware> doesn't work, how do you count the cycles?
[20:18:02] <liwakura> uhm, the start bit is missing
[20:18:30] <liwakura> it still requires some tweaking
[20:18:42] <liwakura> but ill go to bed now, its late.
[20:19:06] <liwakura> also, try to use the UART to check if is not the other device's fault
[20:19:28] <superware> thank you VERY much for your help.
[20:19:57] <superware> the other device works, I have an old board that manage to get some lights working
[20:20:08] <superware> couldn't find the code though
[20:20:11] <superware> good night
[22:02:03] <Emil> Isn't the system clock output sysclock/2?
[22:34:40] <Casper> why /2 ?
[22:37:42] <Emil> Casper: because I though it it toggled it somehow
[22:37:55] <Emil> but alas, it was that my clone arduino doesn't even fucking have a crystal onboard
[22:38:17] <Casper> it's possible
[22:38:27] <Casper> crystal ain't required to make a board work
[22:38:38] <Casper> but it most likelly have holes for one
[22:38:39] <Emil> I know
[22:38:44] <Emil> It does
[22:38:47] <Casper> and it's 2 capacitors
[22:38:49] <Emil> just not populated :D
[22:42:21] <Casper> populate it :D
[22:42:57] <Emil> Eh, just dug out another one ":D"
