Back
[01:12:36] <Haohmaru> dosn't the same things from avrdude.conf apply to when you use terminal mode? i mean.. -U lock:r:... works, but in -t mode "read lock" says it doesn't know such memory type
[02:23:41] <Xark> Haohmaru: Terminal mode vs?
[02:24:34] <Xark> Haohmaru: It is possible IDE is passing in path to non-default avrdude.conf?
[02:36:34] <Haohmaru> Xark i'm calling it from cmd prompt
[02:36:44] <Haohmaru> so it's not using any exotic conf
[02:37:50] <Haohmaru> > avrdude -c avrispmkii -P usb -p x32a4 -U prodsig:r:prodsig.hex:i
[02:38:02] <Haohmaru> gives error
[02:38:17] <Haohmaru> usersig works
[02:39:50] <cehteh> check the avrdude.conf it uses, maybe update it
[02:40:45] <Haohmaru> it loads avrdude.conf from the same directory where avrdude.exe is, right?
[02:43:37] <cehteh> dunno .. i guess it depends on how its build/configured/installed, i am on linux there it reads from /etc
[02:45:37] <Haohmaru> on windows, it gets installed with winavr, so it's in the /bin/ directory, both the exe and the conf
[02:48:18] <Haohmaru> there's memory "prodsig" and "usersig" as well as pretty much everything else in the conf for that chip.. fuses, "lock", "eeprom", ...
[08:33:53] <julius> hi
[08:34:04] <julius> anybody knows how that connector is called? the white one:
http://fs5.directupload.net/images/160113/w75ljoxb.jpg
[09:20:24] <cehteh> boah is that server slow
[09:22:41] <LeoNerd> Is it 0.1" pitch? It looks from the picture to be a little bit smaller even
[09:23:04] <cehteh> i think its one of the molex series, but dunno which
[09:23:18] <LeoNerd> Yah.. Molex make about a billion :)
[09:24:23] <cehteh> yes :)
[09:26:32] <cehteh> julius: whats its purpose?
[09:26:51] <cehteh> best google for that like 'mainboard fan connector' or so
[09:37:08] <nuxil> molex ? anyone still uses thouse molex/amp connectors. ?
[09:39:37] <LeoNerd> Molex are prettymuch the Biro / Hoover / Kleenex of PCB connectors
[09:41:02] <nuxil> these ??
https://upload.wikimedia.org/wikipedia/commons/4/4b/Amp_and_Molex_Connectors.jpg
[09:41:22] <nuxil> havent seen them in a long time.. only old hw uses them nowadays.
[09:41:30] <nuxil> i guess
[09:42:06] <nuxil> anyway.. i was looking at that kicad app you reccomended.
[09:42:12] <LeoNerd> I tend to use simple 0.1" header and crimp socket shells for all my offboard connectors
[09:42:15] <nuxil> gos i found it to be horoble :p
[09:42:24] <LeoNerd> Though that does have the annoying downside of being non-polarised
[09:43:27] <nuxil> LeoNerd, do you know of anyother free cuircit designer software that is free or doesnt cost to much.
[09:43:34] <nuxil> im on the look for something like this.
https://www.circuitlab.com/
[09:43:44] <nuxil> but that stuff is online only :(
[09:43:45] <LeoNerd> Not really. I'm quite happy with KiCad
[09:43:57] <LeoNerd> So I haven't really looked around at other
[09:43:58] <LeoNerd> s
[09:44:37] <nuxil> :\ does kicad do simulation ? i cant find it :p
[09:45:01] <LeoNerd> No; it's for schematic capture and PCB design
[09:45:12] <nuxil> yea.. thats what i though
[09:45:18] <LeoNerd> Though if you generate a netlist you can throw that at some sort of simulation tool
[09:45:47] <nuxil> hmm. such as ?
[09:46:59] <LeoNerd> No idea :)
[09:47:19] <nuxil> heh. ok, i'll google a bit more
[10:18:08] <nikomo> My 32u4 finally arrived, guess I should design a board for it now
[10:18:19] <gevorg> what package ?
[10:18:21] <LeoNerd> Which board?
[10:18:31] <LeoNerd> Oh.. a bare chip? I have the Adafruit breakout board for that
[10:18:44] <nikomo> bare chip, tqfp-44
[10:19:06] <gevorg> oh, those are relativly easy to solder with just iron
[10:19:12] <nikomo> Yup
[10:19:20] <LeoNerd> If you don't need /all/ the IO pins, you might just buy an Arduino Micro board
[10:19:22] <nikomo> It's absolutely massive
[10:19:25] <gevorg> great, now you have hardware usb control
[10:19:35] <LeoNerd> They're a cheap and easy way to get hold of a 32U4 on a breakout board, though it does omit several of the pins :/
[10:19:49] <LeoNerd> I've done that before when I didn't need many IOs
[10:20:17] <nikomo> I put one of those on order, today.
[10:20:46] <gevorg> i ordered stm32, still waiting on it :(
[10:20:47] <LeoNerd> You can also use avrdude with those over just USB :)
[10:20:53] <LeoNerd> No ISP6 header needed
[10:21:22] <gevorg> are those bootloaded with arduino ?
[10:21:26] <nikomo> need a programmer to change fuses, and some other things, so USB can't do everything
[10:21:30] <LeoNerd> avr109
[10:21:56] <gevorg> nah, it's just two assembly instructions
[10:22:14] <LeoNerd> Not for fuses
[10:22:29] <LeoNerd> The SPM instruction doesn't have as much control as the ISP hardware does
[10:22:31] <gevorg> well, you need a programmer for fuses now, don't you ?
[10:22:34] <LeoNerd> It's fine for normal flash upload
[10:22:44] <gevorg> yeah, once you got the fuses done
[10:22:48] <gevorg> and bootloader flashed
[10:23:07] <LeoNerd> Fortunately the Micro board comes with the right fuses for that hardware, though.. and the avr109 bootloader
[10:23:12] <LeoNerd> So that's sufficient
[10:25:30] <nikomo> Why do I get the feeling the internal oscillator isn't accurate enough for USB. Call it a hunch. I didn't have a look beforehand because I don't plan on using the internal osc
[10:26:10] <LeoNerd> Hah
[10:27:22] <nikomo> oh wow, it can do low-speed USB with the internal oscillator
[10:27:29] <nikomo> that's better than what I was expecting
[10:27:32] <gevorg> with 12mhz ?
[10:28:21] <nikomo> not sure what the actually settings up being, I just spotted section 21.4 Crystal-less operation, in the datasheet
[10:28:59] <cehteh> the digispark mirconucleus bootloader doing that with the tiny85, using osccal to calibrate the clock to 16.5mhz from the usb signal
[11:35:41] <MarkX> hi
[11:36:06] <MarkX> TCCR4A = (1 << COM4B1); << apparently this does nothing.
[11:36:20] <MarkX> i'm trying it on my atmega32u4 but my TCCR4A remains zero.
[11:36:29] <MarkX> any ideas where i can go from here to figure out why?
[11:38:08] <LeoNerd> I'd just printf the value immediatley after writing it
[11:38:24] <MarkX> k sec
[11:42:34] <MarkX> LeoNerd: it stayed 0
[11:42:58] <LeoNerd> Are you sure TCCR4A is the right register to be writing, then?
[11:43:00] <LeoNerd> What chip?
[11:43:09] <MarkX> atmega32u4
[11:43:12] <MarkX> yes it is, i'm sure of it
[11:43:36] <MarkX> http://www.atmel.com/images/atmel-7766-8-bit-avr-atmega16u4-32u4_datasheet.pdf
[11:43:38] <MarkX> page 164
[11:44:10] <MarkX> wait
[11:44:11] <MarkX> one sec
[11:44:58] <gevorg> page 153 ?
[11:45:41] <MarkX> gevorg: ?
[11:45:57] <MarkX> TCCR4A = (1 << COM4B1);
[11:46:02] <MarkX> TCCR4B = (1 << CS40);
[11:46:08] <MarkX> TCCR4C = (1 << COM4D1) | (1 << PWM4D)
[11:46:46] <MarkX> so after A, it's on. after B, it's still on. after C, it goes back to zero
[11:46:56] <MarkX> i think i know why
[11:47:08] <MarkX> because there are shadow bits there that get overwritten but C
[11:47:38] <LeoNerd> If you're intending just turn bits on, you want to use |=
[11:47:48] <LeoNerd> Don't forget that = also turns off all the bits you didn't supply
[11:48:16] <MarkX> LeoNerd: this was for the init, so i thought i would be okay with just =
[11:48:20] <MarkX> but those shadow bits screwed me over
[11:48:29] <MarkX> it all works now
[11:48:35] <LeoNerd> :)
[11:48:37] <LeoNerd> Mystery solved
[11:48:46] <MarkX> :)
[11:48:47] <gevorg> yeah, well |= takes more insturctions
[11:48:53] <MarkX> thanks for the help
[11:49:00] <LeoNerd> |= with a single bit is a single instruction
[11:49:09] <LeoNerd> if it's in the IO range anyway
[11:50:35] <gevorg> io, or only gpr ?
[12:16:03] <gevorg> nah, its 3 instructions, in, ori, out
[12:28:34] <Jartza> one or three, depends of the register
[12:29:14] <LeoNerd> 17:24 <LeoNerd> if it's in the IO range anyway
[12:38:23] <gevorg> well, only the first 32 io addresses
[12:38:28] <gevorg> SBI
[13:20:06] <nuxil> how would i go about creating a 8bit random number on a tiny85?
[13:20:19] <gevorg_> do you have a button connected ?
[13:20:26] <nuxil> nop.
[13:20:38] <gevorg> do you have a spare timer ?
[13:20:44] <nuxil> got a 3 pwm's running
[13:20:50] <nuxil> :\
[13:22:00] <gevorg> you can get pseudorandom, but there is the problem with the seed
[13:22:25] <nuxil> oh
[13:22:42] <gevorg> even if you change it every time you flash it, once it reboots it will repeat the pattern, unless you store the last value, and go on from there
[13:22:59] <nuxil> hmm..
[13:24:30] <gevorg> well you can implement one in assembly with shits and xors, pretty sure there are ones already made, and store the result in eeprom
[13:25:12] <gevorg> you'll be left with the corropted writes, and corrupted data from powerdowns and etc.
[13:25:20] <gevorg> *shifts
[13:27:37] <nuxil> oh oh-.. just found this on google
[13:27:39] <nuxil> https://sites.google.com/site/astudyofentropy/project-definition/timer-jitter-entropy-sources/entropy-library
[13:29:21] <nuxil> https://sites.google.com/site/astudyofentropy/project-definition/timer-jitter-entropy-sources/entropy-library/arduino-random-seed
[13:29:33] <nuxil> just need to rewrite it :D
[13:29:53] <nuxil> why is every example i find for arduino :p
[13:30:34] <gevorg> is there a watchdog in t85 ?
[13:30:39] <nuxil> yeah
[13:31:13] <gevorg> can't see how it's truly random O.o
[13:31:48] <LeoNerd> It's unpredictable
[13:31:55] <gevorg> which part of it is ?
[13:32:04] <LeoNerd> The WDT is based on a tiny simple RC oscillator that's totally independent of the main clocking system
[13:32:13] <LeoNerd> So it's clock period isn't going to be synchronised to the main timer
[13:32:38] <LeoNerd> The technique is that you run a timer at the fastest speed, then use a relatively slow (and uncorrelated) WDT interrupt to sample that timer value
[13:32:46] <Mikael_> Hey! Anyone know why this line of code compiles into a call to a function in assembler? "__tmp = ((F_CPU) / 4e3) * __ms;" (__tmp and __ms are doubles)
[13:32:50] <LeoNerd> It's unpredictable what values you'll observe each time
[13:33:14] <nuxil> LeoNerd, thanks for explining
[13:33:23] * LeoNerd has used it himself ;)
[13:33:31] <nuxil> :)
[13:33:34] <gevorg> sounds legit
[13:33:36] <LeoNerd> The WDT is also terribly bad for tempco... which makes it ideal in this case :)
[13:34:15] <gevorg> have you tried using different names ?
[13:34:33] <nuxil> hu?
[13:34:51] <gevorg> it's to Mikael_
[13:35:13] <LeoNerd> Mikael_: Are you on an ATtiny?
[13:35:19] <LeoNerd> ATtiny instruction set doesn't have a multiply
[13:35:30] <Mikael_> No, I'm on an Mega324
[13:35:33] <LeoNerd> Oh... they're doubles. Yes; so that'll definitely be a function call
[13:35:40] <LeoNerd> The AVR core doesn't have an FPU
[13:35:53] <LeoNerd> "floating point numbers" are entirely the invention of the user code
[13:35:54] <Mikael_> Ok, that figures.
[13:36:24] <Mikael_> I was trying to use this in an bootloader but that ... eh ... didn't work that well.
[13:36:36] <LeoNerd> uhhmmm
[13:36:43] <LeoNerd> Whatthehell kind of bootloader needs floating point numbers?
[13:36:56] <nuxil> lol
[13:36:56] <Mikael_> I have my application and bootloader in the same project and moving all bootloader code to BOOTLOADER_SECTION.
[13:37:20] <Mikael_> I stole the delay_us code ...
[13:37:28] <Mikael_> from delay.h.
[13:38:12] <gevorg> can't you do the same with macros ?
[13:38:26] <gevorg> F_CPU is constant anyways
[13:38:48] <LeoNerd> That's not the problem
[13:38:59] <LeoNerd> (F_CPU) / 4e3 will be a compiletime inlined constant
[13:39:07] <LeoNerd> (that constant) * __ms won't
[13:39:10] <LeoNerd> Since __ms is a double
[13:39:40] <Mikael_> I guess I could change it to an uint16 in my case.
[13:40:05] <Mikael_> constant * uint16 will not compile to a call then?
[13:40:10] <gevorg> yeah, but isn't delay_us inline ?
[13:40:40] <gevorg> it isn't a function call, as far as I know, it just does predifined amount of decrements and branches
[13:41:19] <Mikael_> gevorg: delay_us is inline but it doesn't help if things it does compiles into a function call ... to a function that is placed at a "random" location in flash.
[13:42:49] <gevorg> .. wat ?
[13:44:08] <gevorg> that's the deal, there are no function calls, it expects a "compile time integer constant"
[13:47:41] <Mikael_> Sorry, I don't understand.
[13:49:11] <gevorg> Mikael_: try to compile a _delay_us with a variable, it gives you the error, saying it wants a compile time integer constant, so it can calculate the number of cycles, and start decrementing that number
[13:59:29] <Mikael_> Hmm.
[13:59:48] <Mikael_> I have to leave now but thanks for your help.
[15:10:32] <nuxil> :D
[15:11:27] <nuxil> my coke lamp is working. 3xpwm for fading in&out led colors :D
[15:15:08] <nuxil> Box..
https://gyazo.com/d99146d6b41ef14a99433f03d1ada798 Red:
https://gyazo.com/11498f532f08fbf25c91df21652cc6c9 Green:
https://gyazo.com/6818e6f187a5bcfa893524cc931b2229 Blue:
https://gyazo.com/b88e6e068ce0b4b9748911c1aa0e3d97 and random
https://gyazo.com/2cd9516bc246363ffabcd74410b378e1 lol.. :p
[15:37:45] <netizen> hi all
[15:39:21] <netizen> I'm having some troubles setting an ATtiny85 timer0
[15:40:20] <netizen> I've worked with Atmega328 timers before, and it went fine, so i figured this was gonna be ok
[15:40:37] <netizen> but it doesnt -- probably a stupid mistake
[15:42:10] <netizen> in my test code i'm trying to toggle a led state every second (or so)
[15:45:16] <nuxil> its its not time critical. why dont you just use the _delay_ms() fnc ?
[15:46:38] <netizen> i set the prescaler to /64 (CS01 & CS00), so it should overflow roughly every 1ms with a 16MHz clock (1/16e6*256*64), right?
[15:47:24] <netizen> nuxil, it's rather time critical, i need to schedule tasks on a regular basis using this timer interrupt
[15:55:21] <netizen> however, it toggles the led state every second only if i update its state every 65536 overflows. What did i do wrong?
[15:57:03] <netizen> in other words, it's about 64 times faster than i expected. As if the prescaler was off.
[15:59:50] <netizen> if i set the prescaler 4 times slower (/256 or CS02), the led toggles states… 8 times slower :-/
[16:01:44] <netizen> i must have missed something pretty obvious…
[16:06:08] <netizen> and if i set the prescaler 16 times slower (/1024 CS02 & CS00) it toggles at the same frequency than /8… :-(
[16:06:57] <netizen> sorry, /4 (In other words, every 8s)
[16:09:00] <netizen> ok, let me say it again: a /1024 prescaler setting yields the same frequency as a /256 prescaler setting (8x slower than a /64 prescaler setting)
[16:10:56] <nuxil> i wish i could help but i cant. only suggestion i can give is bad :p
[16:11:52] <nuxil> and thats to (ab)use the watchdog timer :p WDTCR = 1 << WDIE | 1 << WDP1 | 1 << WDP2; should do 1 sec. then use ISR(WDT_vect) { do stuff :p
[16:12:03] <nuxil> <--is a noob :D
[16:12:19] <LeoNerd> You might need parens
[16:12:28] <LeoNerd> (1<<WDIE) | (1<<WDP1) | ...
[16:27:57] <netizen> Thanks LeoNerd, you nailed it! It wasn't exactly parens but you put me on the right track! I had an error in my macros and was setting TCCR0B with the value of CS0x instead of its bit value (1<<...)
[16:28:12] <netizen> silly me!
[16:29:02] <netizen> Thanks again, LeoNerd, much appreciated!
[16:29:36] <LeoNerd> :)
[16:29:41] <LeoNerd> This is why I like _BV(...)
[16:33:23] <netizen> Yeah, I'm using a whole lot of those, layers of them actually. That's probably why (i guess) i missed the lack of a "bit value upgrade" in this case
[16:33:45] <netizen> :-p
[16:34:56] <netizen> and thanks for your help nuxil. It's good to feel someone's caring…
[16:35:32] <nuxil> :)
[16:42:40] <LeoNerd> Soo.... ATmega TWI ("I²C") interface module. There's something I don't quite get about it
[16:43:17] <LeoNerd> When I want to send a byte because I'm in write mode, or because I'm sending the address/readwrite bit, I put the byte into TWDR and then set the TWINT and TWEN bits in TWCR
[16:43:43] <LeoNerd> When I want to receive a byte because I'm in read mode, I set the TWINT and TWEN bits in TWCR, wait, then read the returned byte from TWDR
[16:43:52] <LeoNerd> but how does the interface module know if it should be transmitting or receiving?
[16:50:33] <julius> WormFood, hi
[16:51:39] <julius> WormFood, is the code you use to flash chips over ethernet open source?
[17:53:01] <j9k> http://www.prnewswire.com/news-releases/microchip-technology-announces-that-its-proposal-to-acquire-atmel-has-been-deemed-a-superior-proposal-by-atmels-board-of-directors-300203728.html
[17:54:25] <studdentt_> how do i send multiple bytes with the CANbus ?
[18:23:46] <phinxy> j9k, does this mean the people behind pic now owns atmel?
[18:24:33] <j9k> Not yet but soon.
[18:26:21] <Lambda_Aurigae> microavr on the way!
[21:44:20] <Casper> I'm not sure if this is good or bad for atmel...
