#avr | Logs for 2016-01-16

Back
[00:39:28] <phinxy> if a relays pick up current is 80mW does that mean i can toggle it with only 0.00025A on 4V which is 0.25mA which is enough for a output pin without a amplifier?
[00:42:55] <phinxy> or do i need to add something to limit the current from going up
[00:52:09] <tpw_rules> are you sure it's not specified in mA? that's kind of odd
[01:07:53] <Casper> 0.25mA seems very unlikelly
[01:08:01] <Casper> 80mA on 4V seems way more likelly
[01:38:13] <phinxy> ok so it works, i hear it tick - tock when i make the set and reset coil high/low
[01:38:43] <phinxy> but i dont see any voltage on the switched pins =(
[01:39:59] <Xark> That seems odd...
[01:44:03] <phinxy> have i interpreted this schematic wrong? http://imgur.com/4iraz9s
[01:55:17] <phinxy> either way its too late since its potted in plastic
[05:18:36] <Jartza> Casper: no, I'm not driving the VGA out from 4 pins, but 3 :)
[05:18:55] <Jartza> 1 pin drives Hsync, Vsync and Red color
[05:18:56] <Jartza> :)
[05:19:53] <Jartza> the 4th pin is reserved for oscillator
[06:11:45] <Martin90> What is the name of the unit that fetch the first instruction from memory ? I mean the very first instruction after chip is powered ?
[06:13:59] <cehteh> dunno if there is a name, the mpu just initializes all registers to the default values which is 0 for the PC which in turn is the reset vector
[06:15:55] <Martin90> ok but then it has to read first 'programmed" instruction right ?
[06:16:00] <Martin90> from flash
[06:16:46] <cehteh> see datasheet
[06:17:11] <Martin90> do you think such info will be there ?
[06:17:29] <cehteh> thats what the datasheet is for
[06:17:51] <Martin90> ;P
[06:18:06] <cehteh> i have the 328p datasheet open here, section 6 describes the cpu architecture, section 10 describes the reset ogic
[06:18:36] <Martin90> btw, SRAM is physicaly separated from flash in all AVRs ?
[06:19:17] <cehteh> havard architecture
[06:19:39] <cehteh> that means data and programm have very different address spaces, divided on a hardware level
[06:19:39] <Martin90> thank you
[06:19:53] <cehteh> you cant put code in sram and execute it there
[06:20:34] <Martin90> right
[07:37:03] <phinxy> easiest way to have a kinda secure password with a 5 button input? up down left right press
[07:37:25] <phinxy> im thinking youre allowed to pick a 8bit value and if its wrong you got to wait 5 minutes
[07:37:50] <phinxy> or maybe just a sequence of presses
[07:41:35] <phinxy> how complex are RFID readers
[07:42:10] <MartinR90> 8bit value as a password ? Rather weak, don't you think so ?
[07:58:07] <apo_> it'll still take 10h to crack
[07:58:16] <apo_> if that's enough.. :p
[08:10:04] <Snert> a delay that increases exponentially.
[08:10:14] <Snert> each bad try doubles the wait
[08:22:22] <gevorg> well you can add time to it, like press buttons in a certain sequence, and with certain time delays in between, with some accuracy
[08:28:48] <cehteh> 8 bit is really weak
[08:29:48] <cehteh> and for the first few wrong tries you dont want a 5 min timeout, that would be really annoying for a legetimate user when he enters the wrong password once
[08:30:28] <cehteh> besides .. consider reset/powerdown attacks .. if one can just reset the chip, how could you enforce proper timeouts
[08:31:52] <cehteh> (one could write startup timeouts to eeprom, round robin to some addresses to prevent wear)
[08:32:21] <cehteh> and protect the password against read out, hashing and/or lockbits
[08:33:04] <gevorg> well if you get powered down while writing to eeprom, the data there will be corrupted
[08:41:22] <cehteh> thats ok
[08:41:40] <cehteh> as long you can detect such an attack and act accordingly
[08:55:10] <Flutterbat> im having some trouble with my atmega328p. it supposedly has 32kb flash. i have a program that uses an image saved has an int array. if i use the whole image the program doesnt work. if i cut the array in half, it draws half the image. but theres no way im close to 32kb. avrdude tells me avrdude: 5496 bytes of flash verified
[09:00:25] <gevorg> are you doing the whole thing with progmem ?
[09:01:04] <gevorg> i.e. are you saving the image to flash, and not loading it to ram
[09:03:29] <theBear> also if you have a bootloader that will cut into your progmem
[09:03:37] <theBear> or more like truncate it from your pov
[09:21:23] <ub|k> is it common to have parity errors in avr - computer communication over usb-serial?
[09:22:38] <phinxy> Flutterbat in the display library u8glib you can only have bitmaps/fonts in a max size. if the bitmap is larger than maybe 40x40 you would need to build up the image from pieces
[09:23:40] <phinxy> the array length is never a limit but the individual character cant be X big
[09:30:25] <Casper> ub|k: uncommon to even use parity
[09:30:47] <ub|k> Casper: ok
[09:30:48] <Casper> ub|k: usually people set 8n1, n is for no parity
[09:31:09] <ub|k> Casper: i'm losing bytes somewhere, but then i guess it's unlikely that it's a parity problem
[09:31:19] <ub|k> anyway, even if it was a parity error, i'd still receive something
[09:32:41] <ub|k> i'm filling up a circular buffer using USART_RXC_vect
[09:35:23] <Casper> first thing to check: settings. If you did indeed set parity on the avr, be sure that you have a matching parity on the pc
[09:36:23] <Casper> second thing to check: clock source, if you use the internal oscillator then expect trouble. If you use an external one, be sure that the clkdiv8 fuse is disabled, and that, if available, full swing oscillator is enabled
[09:37:37] <Casper> third is to confirm that you have less than 2% speed mismatch between the target speed and real speed (that happend with non-uart friendly clock source, like 16MHz, 18.432MHz is one of the uart friendly)
[09:39:03] <Flutterbat> phinxy: im not using any kind of premade library
[09:39:40] <phinxy> but the image youre talking about is a bitmap you send to a display?
[09:40:22] <Flutterbat> phinxy: well its an array. every element is 2byte and encoded in RGB 565 which i send to the display one by one
[09:40:45] <Flutterbat> if that how bitmap looks like then yes it is bitmap
[09:40:50] <Flutterbat> thats*
[09:43:05] <phinxy> well this is what someone said about u8glib: "U8glib has been written for 8 bit MCUs. So, the internal data structures do not allow more than 255 bytes per glyph."
[09:46:11] <Deskwizard> oh hey! :)
[09:46:49] <Flutterbat> what would a glyph be?
[09:47:28] <Flutterbat> ah its some arduino crap. again im not using that
[09:48:40] <Deskwizard> ... damn, it invaded over here too? I'm trying to run away from that crap damn it lol
[09:49:21] <Deskwizard> but then again now anything with a mcu is an arduino *rool eyes*
[09:50:14] <Deskwizard> anyhoo...
[09:50:36] <Deskwizard> I have ported the AVR307 app note to avg-gcc, and it's working on my attiny45 :)
[09:50:42] <Deskwizard> most of the time ..
[09:51:44] <Deskwizard> long story short, my timer 1 compare interrupt is fighting the USI overflow, and I get garbabe
[09:52:06] <ub|k> Casper, parity is off on both the avr and the pc. using an external osc. fuse settings are lfuse=0xff, hfuse=0xcf
[09:52:14] <ub|k> (it's an atmega32)
[09:52:22] <Deskwizard> but its working fine if I don't enable the timer 1 isr, or if I have it fire at a lower rate
[09:52:55] <Deskwizard> so I have the following idea that I want to you by you guys just to see if I'm mental (or currupted by arduino more than I thought)
[09:53:58] <WormFood> Deskwizard, what is AVR307? I don't want to search for it.
[09:54:01] <ub|k> hm... so i shouldn't be using 16Mhz?
[09:54:42] <Deskwizard> Considering that I have F_CPU and the current baudrate defined, If I disable my timer 1 overflow interrupt (its only a counter) while receiving/sending, I can calculate the time the UART was sending/receiving for using the number of bytes sent/received (known), F_CPU and the baudrate, correct ?
[09:54:58] <Deskwizard> WormFood Half duplex UART using the USI Interface
[09:55:55] <Deskwizard> WormFood the porting wasn't that hard, couple register change, remove pragma stuff and put proper isr vectors... that kinda thing...
[09:56:12] <ub|k> anyway, i'm not getting any of the error bits set. i think this is most likely an issue with my buffer
[09:56:32] <Deskwizard> its really my idea about calculating how long the timer1 overflow interrupt was disabled idea that I am unsure about
[09:56:48] <Deskwizard> the UART works fine if it doesnt get interrupter by t1ovf
[09:56:50] <WormFood> I used one of their app notes, for the software uart. I was able to make my code smaller, and more efficient. Which I kinda needed.
[09:57:16] <Deskwizard> WormFood yeah they really nice, I wasnt expecting it to be that easy
[09:57:52] <Casper> ub|k: one way to check if it is a prob with your code is to use peter fleury uart lib and see it that one work
[09:57:52] <Deskwizard> I would have been done in a matter of hours (since I'm still quite new at this) if I didnt clear the interrupt bit instead of setting it when I changed the code from IAR to gcc lol
[09:57:56] <WormFood> I know a few things about serial ports ;)
[09:58:15] <Casper> and for 16MHz, it have a mismatch in speed, and some speed is unusable
[09:58:19] <Deskwizard> WormFood want to look in case I made a stupid obvious mistake porting it ?
[09:58:37] <ub|k> Casper: yeah, i'll give it a try, thanks!
[09:58:59] <Casper> it work, but not on all speed... btw, wormfood baud rate thingy is great
[09:59:17] <WormFood> Thanks Casper, glad you find it useful.
[10:00:03] <Deskwizard> I might be interested in that baudrate thing if you guys dont mind ...
[10:00:05] <Deskwizard> ;)
[10:00:53] <Deskwizard> since as of now I just #ifdef F_CPU to shove working values down the USI's throat
[10:04:40] <WormFood> Deskwizard, just google for avr and baud
[10:04:45] <WormFood> ;)
[10:04:54] <phinxy> i want to make a byte in to a string, itoa works but leading zeros gets removed it seems
[10:04:56] <Deskwizard> ah, that one hehe
[10:05:26] <WormFood> I think my page comes up on the 2nd or 3rd google page, if you search for just "baud". I haven't tried it in a while, so don't know if that's still the case.
[10:05:51] <Deskwizard> I probably have it bookmarked, the cpu vs baudrate page with all the tables ?
[10:06:01] <WormFood> yeah.
[10:06:10] <WormFood> It's the most popular page on my website.
[10:06:15] <Deskwizard> hehehe OH
[10:06:18] * Deskwizard bows down
[10:06:24] <Deskwizard> thanks for all the help ;)
[10:07:07] <WormFood> And, there are no links to any of my pages, to my calculator. I shared the link in this channel twice, someone posted it to a mailing list, and then *everyone* picked it up. Lots of links to that page on some high profile sites (even sparkfun links to my calculator)
[10:07:24] <phinxy> awesome i wanted a history of 2bit keypresses. i just stored every keypress in a 16bit integer and then shifted it to the left 2bits and OR'd in the new keypress! :D
[10:07:43] <WormFood> That's "organic SEO". I didn't do shit, but write a good page ;)
[10:07:49] <Deskwizard> no doubt about that, theres no need for any other page about it once we found yours :P
[10:08:22] <Deskwizard> phinxy Wow, thats a great idea !
[10:08:30] <Casper> WormFood: and no google ads... could have made a tiny fortune with it! :D as if ads was that great...
[10:08:49] <phinxy> Deskwisard, so clean
[10:09:06] <Deskwizard> phinxy I read that once or twice and went Woah! :D
[10:09:07] <Deskwizard> lol
[10:09:08] <Casper> now, to pick on WormFood... :D
[10:09:27] <WormFood> I don't think I get enough traffic to really make any serious money with it. If I sold targeted ads, that would be worth a lot more, because nearly everyone that visits that page, and actually uses it, is an AVR geek, or wannabe geek ;)
[10:09:48] <Casper> WormFood: good is debatable! but sure thing is: better than everything else back then, and still better now
[10:09:50] <Casper> :D
[10:10:42] <WormFood> First version was 2005, so it's been online over 10 years.
[10:11:02] <WormFood> And, I have fixed bugs, and updated it. I should probably make my changelog public.
[10:14:00] <ub|k> is it normal that in avr-gcc there's PE, not UPE?
[10:17:35] <WormFood> I think that depends on which header you use.
[10:17:51] <WormFood> The header files, should follow the names defined by atmel.
[10:35:15] <Casper> WormFood: but joking aside, very usefull page, just need some other clock speed, but nothing really important
[10:36:05] * Casper shoulds make a web site...
[10:38:50] <WormFood> Casper, If you have any suggestions, for speeds I should remove and what I should replace them with, then I'm all ears (or is that "all eyes", on IRC?)
[11:12:08] <phinxy> is memory leaks something that happens on a micro?
[11:12:23] <phinxy> should i be worried if all i do is basic stuff
[11:12:32] <Deskwizard> idk, I tend to think I get those as well ... :P
[11:21:00] <Jartza> evening
[11:23:20] <Deskwizard> 0/
[11:31:33] <Casper> phinxy: memory leak is not a pc thing, it is bad coding practice and bugs
[11:33:09] <cehteh> with the few bytes you have on a mpu the would be devasting
[11:33:10] <Casper> phinxy: basically, pointer = malloc(); do stuff, pointer = malloc(); do more stuff; free(pointer); <=== notice that the first malloc has never been freed, the result is that the memory is still allocated but innaccesssible. You just leaked memory
[11:33:36] <cehteh> best is to avoid malloc alltogether
[11:34:42] <Casper> yup
[11:35:50] <Jartza> Casper: well, it's an old trick how I get 3 color bits and vsync+hsync out of 3 pins
[11:36:26] <Jartza> first, vsync and hsync are easy if you know what happens to those signals once they enter the monitor (in 99.5% of VGA monitors, at least, there are few exceptions especially in CRT versions)
[11:36:46] <Jartza> usually those monitors just XOR the two signals together before handling them
[11:36:53] <Casper> also, another leak... int foo() { pointer=malloc(); .... return(); } you would think that the function would release the memory, but nope, it is not like a normal variable...
[11:37:06] <Jartza> I just XOR them at the MCU end and connect VSYNC to VCC and XORed signal to HSYNC
[11:37:30] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxUkI0WWE3a0RIZ3M/view
[11:38:10] <Jartza> in that scope pic you can see HSYNC signals and when VSYNC happens, the signal is just basically "reversed" during VSYNC
[11:38:43] <cehteh> Jartza: so you made a sync on red instead sync on green?
[11:38:50] <Jartza> not red
[11:38:55] <Jartza> I'm not driving the sync signal to red
[11:38:57] <Jartza> nor green
[11:39:02] <Jartza> I'm driving it to hsync :)
[11:39:25] <Jartza> and it works on ~99.5% of vga monitors
[11:39:59] <cehteh> 99.5% .. that means you have at least 200 different monitors at home and one failed? :D
[11:40:05] <cehteh> WOW
[11:40:48] <Jartza> well, I only have 7 vga monitors and it works on all of them :D
[11:41:35] <Jartza> but I know there are rare monitors out there (usually very old and CRT) where it might not work
[11:41:38] <Jartza> anyhow
[11:41:53] <Jartza> the red color is driven out from the same pin using another very old trick
[11:41:59] <Jartza> meaning, AVR pins have 3 states, right?
[11:42:15] <Jartza> pull up, pull down, floating (hi-z)
[11:42:41] <Deskwizard> Jartza low, high, hi-z (and enable the pullup if you want)
[11:43:15] <Jartza> so, with some diode & pull-up & pull-down resistors in right combination I can actually drive both the sync and color
[11:43:30] <Jartza> because in VGA when the sync pulse happens, color signal needs to be 0V
[11:43:54] <Jartza> and when pixels are drawn, the sync signal needs to be high
[11:44:35] <Jartza> when I drive sync pulse, I set DDR register to output and drive the sync using PORT register
[11:44:36] <Deskwizard> I honestly said as much as my limited knowledge let me at this point.... sorry
[11:44:50] <Deskwizard> (but yeah sounds about right)
[11:44:58] <Jartza> when it's time to draw pixels, I set PORT to 0xFF
[11:45:06] <Jartza> and drive the pixels using DDR :)
[11:45:25] <Jartza> effectively switching between pull-up and hi-z
[11:45:54] <Jartza> in pull-up the sync signal is pulled high. in high-z the pin is floating, in sync pin I have pull-up resistor, so it still stays high (no change).
[11:45:54] <Deskwizard> uhm, not quite
[11:46:04] <Deskwizard> pull up is DDR input PORT high
[11:46:17] <Deskwizard> high Z is DDR input PORT low
[11:46:32] <Jartza> Deskwizard: I'm not talking about pull-up resistor
[11:46:38] <Jartza> pin in output mode is push-pull
[11:46:44] <Deskwizard> ah okay sorry
[11:47:06] <Deskwizard> <Jartza> effectively switching between pull-up and hi-z <= that part got me mistaken
[11:47:11] <Jartza> yea
[11:47:19] <Deskwizard> I'll shut up now :)
[11:47:22] <Jartza> well, effectively switching between "drive high" and hi-z
[11:47:26] <Jartza> that might be more understandable
[11:47:39] <Jartza> Deskwizard: nah, it's completely valid correction as that might get mistaken :)
[11:48:04] <Deskwizard> yeah, im a bit of a stickler for terminology
[11:48:06] <Jartza> anyhow. the color pin is connected behing diode
[11:48:13] <Deskwizard> or register nazi, whatever :P~
[11:48:29] <Jartza> so when driving pin high (pin as output and high) some voltage goes to color pin through diode
[11:48:48] <Jartza> when in high-z mode, VGA monitor's internal pull-down (75ohm) pulls that color pin down :)
[11:49:04] <Jartza> I use yellow LED as diode :P
[11:49:18] <Deskwizard> nice hehe
[11:49:49] <Jartza> I think something like 3.3V zener would work too
[11:51:46] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxWXNmQzZYSUhycEU/view
[11:52:04] <Jartza> near the bottom of the pic, that violet wire goes to hsync pin, that brown wire to red
[11:52:22] <Jartza> there's some extra pulldown in red color to keep it <0.7V
[11:53:40] <Jartza> and that sot23-6 in that red breakout is the MCU :)
[11:57:29] <Jartza> and this is what it currently outputs https://www.youtube.com/watch?v=8BMM-UMZQlY
[13:28:15] <stanreg> Is it feasable to use an AVR to produce a 6 mhz clock source?
[13:28:44] <cehteh> where does the avr get its clock from?
[13:28:56] <stanreg> 16.432 xtal
[13:29:04] <stanreg> Then I guess not, damn.
[13:29:15] <stanreg> What if it was an internal clock source, of say, 12 mhz?
[13:29:26] <cehteh> might work, at least close to 6mhz
[13:29:46] <stanreg> alright, thanks
[13:29:46] <cehteh> internal is not petty good, but you may just try
[13:29:55] <cehteh> which avr?
[13:30:16] <stanreg> ATmega2560
[13:30:17] <cehteh> some tinys have this crazy PLL which can run up to 64mhz on internal clock :D
[13:30:38] <stanreg> Woah.
[13:30:50] <cehteh> only for one timer, but you can do some funky things with that
[13:31:06] <stanreg> such as?
[13:31:14] <julius> what do you do with a bootloader on a atmega?
[13:31:15] <lald> Noob question, was the 16mhz not going to work but a 12mhz might because 6 is a multiple of 12 but not 16?
[13:31:24] <stanreg> right
[13:31:28] <lald> Cool, thanks
[13:31:51] <cehteh> someone posted a link with overclocking an tiny then generate 96MHz which plays music on FM band
[13:32:49] <cehteh> you can use one timer in frequency generation mode (or how its called) to generate other frequencies, not exact but often close enough
[13:33:28] <stanreg> hmm, interesting. I'll have to look into that.
[13:34:12] <cehteh> from 16.432 to 6 might be not work out .. just calculate how far you can get
[13:36:11] <Jartza> attiny85 has internal 64Mhz PLL
[13:36:20] <Jartza> which can be just "tuned" to higher
[13:36:23] <Jartza> using osccal
[13:36:28] <cehteh> yeah saied that
[13:36:48] <cehteh> but it can only hooked to the rc osc not to external clock :/
[13:37:02] <Jartza> julius: with bootloader you can load new firmware in to the chip flash
[13:39:21] <gevorg> ^ without using a programmer
[13:39:22] <cehteh> oh the mega 2560 has 3 compare match units on the 16bit timer, nice
[13:40:08] <gevorg> there was an atmega dedicated to pwm, can't remember the name though
[13:40:17] <gevorg> it had pwm on all of it's pins
[13:41:02] <cehteh> gevorg: i asked about a avr which has more than 2 compare match units on *one* timer some time ago
[13:41:24] <gevorg> well, I was here some time ago
[13:41:27] <cehteh> often you have 2 or 3 timers with 2 compare/match units each
[13:41:29] <gevorg> *was not
[13:42:03] <cehteh> but with one you can do some interesting things, RGB leds in 16 bit ... 3 phase motor control etc etc
[13:44:12] <gevorg> oh, it wasn't atmega, it's from classic family
[13:44:12] <stanreg> cehteh, atmega2560 has an internal clock of 8 mhz, though :(
[13:44:18] <gevorg> at90pwm1
[13:44:24] <cehteh> stanreg: and no PLL
[13:44:27] <gevorg> "On-chip PLL for fast PWM ( 32 MHz, 64 MHz) and CPU (16 MHz)"
[13:46:36] <cehteh> stanreg: yes tiny25, 45, 85 can do better with the PLL
[13:46:47] <cehteh> but the internal clocks are not very stable
[13:47:14] <cehteh> if thats not required then you can use that, if you have some external signal which you can use to calibrate along then you may use it too
[13:47:30] <cehteh> but when you neded a rock solid 6mhz clock, then nogo
[13:48:37] <gevorg> just take a 12 mhz crystal, ring it and divide it by two with d flip-flops
[13:48:41] <cehteh> these tinys can run on 16mhz from the internal 8mhz osc .. and the pll can drive one timer at 64mhz
[13:50:08] <cehteh> (64 / 256) * 24 = 6 .. hits 6mhz :)
[13:51:09] <cehteh> gevorg: or 6mhz crystal
[13:51:34] <gevorg> well that won't be an overkill now, will it
[13:51:34] <cehteh> or complete osc
[13:51:43] <stanreg> hah
[13:52:25] <cehteh> arent there any programmable osc's as integrated circruits?
[13:52:26] <julius> Jartza, ah ok
[13:53:25] <julius> load a new flash every time when theres power, or just once and then again on command?
[13:53:50] <cehteh> http://www.linear.com/product/LTC6903
[13:53:55] <cehteh> just random google result
[13:55:19] <gevorg> if your avr isn't doing anything, then you can probably get around it with code, just cli, then do some magic with nop-s and sbi-s
[13:57:21] <cehteh> julius: usually it boots up checks if some certain condition is met, then it goes into programming reading a program over serial or whatever and writes it to flash, or if these conditions are not met then it just enters the user program
[13:57:41] <julius> condition check over network?
[13:57:49] <cehteh> conditions can be some signal on serial, some pin(s) pulled up or down or whatever
[13:57:55] <julius> ah ok
[13:58:25] <cehteh> the arduino bootlader for example waits 1 second or so on serial if it sees some programmer calling for it there
[13:59:27] <cehteh> if you need fast boot times you usually disable such waits and use some other conditions, like reset from reset button + pinx X pulled to ground or so
[14:01:05] <julius> ah
[14:01:06] <Jartza> julius: depends of the bootloader but the most common use is when you want to put new software in your chip
[14:01:07] <julius> i see
[14:01:20] <Jartza> there are plenty of different bootloaders
[14:01:46] <Jartza> one use case is to allow end users to update firmware, without them owing a programmer
[14:02:01] <Jartza> for example my digital namebadge firmware can be updated playing mp3 to it .)
[14:03:52] <julius> weir
[14:03:53] <julius> d
[14:05:01] <gevorg> you mean mp3 that is not pleasant to hear ?
[14:05:34] <Jartza> yep
[14:05:39] <gevorg> nice
[14:06:28] <gevorg> can you generate something non ac with your sound card output ?
[14:06:43] <gevorg> like dc-ish, digital signal
[14:06:55] <gevorg> it's still ac, but not modulated by any freq
[14:07:00] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxRTVJNnNLc0tjVHc/view
[14:07:04] <Jartza> this is the latest firmware :)
[14:07:12] <Jartza> actually that's funny
[14:07:39] <gevorg> mm kindof don't want to try it :3
[14:07:44] <Jartza> the firmware in the device is acting in two stages, so the firmware in device listens to that audio, which first contains bootloader :)
[14:07:51] <Jartza> and then the bootloader loads the actual firmware
[14:08:17] <Jartza> gevorg: it's just mp3, won't break anything
[14:08:27] <Jartza> except maybe your ears if you play it too loud
[14:08:52] <Jartza> and IMO it doesn't sound that bad than most modems do :)
[14:09:19] <julius> just read 2 of the order confirms on aliexpress...they kinda try to jump backwards for you. first time for me
[14:09:22] <gevorg> well it could damage the speakers, but mostly it would damage the music, so no thanks
[14:10:11] <cehteh> you can do encryted firmware uploads too with bootloaders .. quite evil :D
[14:10:39] <gevorg> well can't do much encryption though
[14:10:47] <gevorg> but sounds interesting
[14:11:05] <cehteh> oh you have a lot time so you could do a lot
[14:12:18] <cehteh> i was thinking about only enabling flashing after one sends some 'identification' .. prolly the code which is already on the device, that give a rather big key :)
[14:12:28] <cehteh> so you send first the old code, then the new one
[14:12:54] <cehteh> for small sercurity sensitive open source things where you dont want anyone to reflash it
[14:12:57] <gevorg> and if something is getting messed up while you do that, you buy a new chip, as you have locked the old one already
[14:13:03] <cehteh> nah
[14:13:12] <cehteh> you can always do a full chip erase
[14:13:33] <cehteh> with proper lock bits one could just not read anything from the chip
[14:13:51] <julius> aliexpress does not know "ethernut" - what kind of board does include a bootloader functionality?
[14:13:59] <cehteh> mhm moment .. thats already a problem :D
[14:14:18] <cehteh> well .. this device needs to authenticate to the computer it connects to
[14:14:36] <cehteh> so its good enough when no one could read private keys from it
[14:14:53] <Jartza> but I still like the idea that customer can update the device firmware later
[14:14:56] <Jartza> whatever the device is
[14:15:34] <cehteh> depends, generally i agree and i dont want to shut 'legetimate' customers out
[14:15:45] <cehteh> but i want the device to be tamper proof
[14:15:56] <Jartza> I don't
[14:16:03] <Jartza> I like people tampering with devices :)
[14:16:26] <Jartza> depends of the use-case of the device, of course
[14:16:37] <Jartza> I don't want them to update crappy firmware by accident, that's for sure
[14:17:31] <cehteh> me thinks about a dongle which can unlock harddisk encryption, and / or have a hardware random generator
[14:17:57] <cehteh> more plaything than real product, but still the security should be good enough for a proof-of-concept
[14:18:19] <Jartza> something like this: http://blacksquaretechnologies.com/
[14:18:48] <cehteh> maybe
[14:18:59] <cehteh> just open source/free soft and hardware
[14:23:22] <Jartza> mmkay
[14:24:35] <cehteh> well i am still and slowly working on my scheduler ..
[14:25:25] <julius> can i just get a arduino uno with a "ethernet schield" and flash a bootloader on there?
[14:25:48] <cehteh> no idea
[14:25:59] <cehteh> you can flash via usb
[14:26:38] <cehteh> can the ethernet shield somehow setup a virtual serial port over ethernet? then maybe
[14:26:53] <cehteh> i never understood why one wants a ethernet shield on a avr
[14:27:29] <gevorg> to download porn using 8 bit architechture
[14:27:36] <cehteh> the ethernet shield has 100 times the processing power the arduino has :D if i want to hook something into a network i am easier and cheaper done with something else
[14:27:48] <cehteh> (.)(.)
[14:29:56] <gevorg> same goes with esp8266, but there is a reason to use another mcu with it
[14:30:07] <gevorg> esp can run up to 160 mhz, but it has very limited io
[14:30:33] <gevorg> not the new esp32 though, that thing should be amazing
[14:30:49] <cehteh> this node things with lua onboard
[14:32:29] <cehteh> http://www.banggood.com/V3-NodeMcu-Lua-WIFI-Development-Board-p-992733.html havent used them yet. but i should order a few, looks amazing
[14:33:13] <gevorg> seems like esp12e
[14:34:02] <gevorg> well you can program those guys in c, the sdk is available
[14:34:23] <cehteh> yeah
[14:34:28] <cehteh> but lua is amazing too
[14:34:50] <cehteh> when its not time critical and you need to have something working fast
[14:35:38] <cehteh> controll some power sockets over wlan .. in 20 lines of code
[14:36:55] <gevorg> well, you would be surprised, it's about that same size in c
[14:37:20] <gevorg> which is more correct to use with AVRs - ISP or ICSP ?
[14:37:27] <gevorg> the term I mean
[14:37:57] <cehteh> dunno
[14:44:40] <studdentt> someone familliar with the CAN bus ?
[14:47:24] <julius> cehteh, sure...it can do more. just looking for a easy solution to start with.
[14:48:00] <julius> gevorg, im a beginner, but i never heard the name icsp
[14:48:49] <gevorg> stands for in circuit serial programmer
[14:48:55] <gevorg> while isp is in system programmer
[14:49:34] <gevorg> both have the idea of programming the chip without unplugging it from existing system/circuit
[14:52:03] <julius> worked with some usbasp's, ic-prog2. it was always "isp" for me
[14:52:33] <julius> cehteh, the v3-nodemcu description says that you can program that in node.js style
[14:52:38] <julius> and lua
[14:52:43] <julius> whatever that is
[14:56:29] <gevorg> https://www.youtube.com/watch?v=t4e7PjRygt0
[15:05:24] <julius> thats not even porn, dude
[15:06:33] <malinus> studdentt: what about CAN bus?
[15:06:48] <malinus> people - just ask the question :D
[15:08:15] <gevorg> oh trust me it is porn, but not in literal sense
[15:17:12] <julius> youre right, its awfully quite in here since you posted
[15:17:22] <julius> :)
[15:52:02] <twnqx> i know more about CAN than i ever wanted to know
[15:52:07] <twnqx> but now it's bedtime
[16:06:29] <studdentt> malinus: i send K,L,M from one node to another but the receiver gets M,K,L , why is that? it is supposed to be a FIFO buffer
[16:07:31] <studdentt> malinus: also, is it ok if i assigne value for CANMSG back to back ? such as CANMSG = 1; CANMSG =2; CANMSG = 3;
[16:07:56] <studdentt> then i tell DLC = 3
[16:08:02] <studdentt> and loop
[16:12:35] <yids> .win 35
[16:14:20] <cehteh> julius: lua is a simple and very clean scripting language
[16:14:24] <cehteh> i use it a lot
[16:30:16] <studdentt> when there is a read on CANMSG, does the receive buffer push the next byte into the CANMSG register ?
[16:30:18] <studdentt> malinus
[16:39:19] <studdentt> can i fix wrong fuses settings using only the ICSP connector ?
[16:42:46] <Tom_itx> probably
[16:43:09] <Tom_itx> if you set the wrong clock source you may have to come up with a clock source to clock it
[16:44:05] <Tom_itx> it must be 4x the SPI clock rate too
[17:04:42] <studdentt> doesnt work for at90can
[17:04:45] <studdentt> only HVPP
[17:04:52] <studdentt> and the ic is on a pc >.>
[17:04:53] <studdentt> pcb
[17:06:38] <Jartza> HVPP or HVSP or HV TPI depending of the chip
[17:06:43] <Jartza> if you really mess up the fuses
[17:07:07] <Jartza> but if set to external clock, that's usually easy
[17:07:13] <Jartza> just clock it from some other chip :)
[17:13:34] <Lambda_Aurigae> http://hackaday.com/2016/01/15/wolfenstein-in-600-lines-of-code/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+hackaday%2FLgoM+%28Hack+a+Day%29
[17:13:51] <Lambda_Aurigae> Jartza, put that on an attiny85 and tie it to the octapentaveega.
[17:14:30] <cehteh> port AWK to the tiny6 first :)
[17:33:13] <Jartza> Lambda_Aurigae: lol :)
[17:42:37] <julius> cehteh, is it "clean" like pythob?
[17:42:40] <julius> python
[17:42:54] <cehteh> python is dirty compared to lua
[17:43:07] <cehteh> i like lua much more
[17:43:58] <julius> oh, than i have to take a look after my car pc project
[17:45:39] <julius> if you crack open a cheap dashcam that records to a cd
[17:46:27] <julius> sd card i mean, would it be possible to read the cameras 720p output with a raspberry2 over the gpio pins=
[17:47:07] <Lambda_Aurigae> you could, in theory, emulate an sd card with the rPI
[17:48:27] <cehteh> but you need to emulate the FAT fiilesystem too
[17:48:50] <cehteh> in theory .. yes .. practically: just get a camera with some useable output
[17:48:59] <Lambda_Aurigae> yes.
[17:49:05] <cehteh> some dashcams have a webcam mode, some have AV out
[17:50:12] <cehteh> getting a cheap webcam is prolly even better ..
[17:51:25] <cehteh> http://www.amazon.de/Logitech-960-000635-C270-Webcam/dp/B003PAOAWG/ works well under linux
[17:52:04] <julius> good idea, you get a casing and a usb output
[17:53:13] <cehteh> what do you exactly need?
[17:54:06] <julius> dashcam recording to the rpi2, probably going to a usb stick
[17:54:49] <julius> so yes the webcam will do, there are even mountings for the car window
[17:55:08] <learath> wouldn't it make more sense to get soemthing that can write directly to storage, rather than adding a rpi?
[17:55:58] <julius> no, the rpi is already there. for the radio
[17:56:07] <learath> ah.
[17:56:37] <julius> maybe that goes out later, but i will stay with something that runs linux
[17:56:53] <cehteh> you know that the rpi has very little i/o bandwidth
[17:57:20] <julius> now i do :)
[17:57:26] <julius> have to read up about that
[17:57:39] <cehteh> everything has to go through the usb stuff
[17:58:03] <Lambda_Aurigae> ethernet, wifi, and usb ports all go through one usb port on the chip don't they?
[17:58:14] <julius> yes no pci
[17:58:24] <cehteh> if video stream comes in via usb and you want to store it to usb flash then you have half the usb bandwidth already .. plus anything else which goes over it
[17:58:36] <cehteh> and the ethernet is internally connected over usb too
[17:58:42] <julius> yes
[17:59:27] <cehteh> getting some dashcam which records autonomusly and maybe sends webcam data over usb (if you need that) or av might really be better
[17:59:30] <Lambda_Aurigae> there is a port on my rPI B+ for a camera interface that, I believe, does not use the usb.
[17:59:36] <julius> i would have to decode mp3's, but probably running a whole linux on it and something like xmbc(kodie) might kill it
[17:59:53] <cehteh> yeah the rpi cam should work too
[18:00:49] <julius> all good points
[18:01:35] <cehteh> you know the mobius cam? ---
[18:01:52] <julius> usually all is hd these days, but i kinda like the read view camera that just displays without using any processing power
[18:02:20] <julius> no, let me check that out
[18:04:23] <cehteh> rear view cam? .. i guess you dont want any noticeable latency :D
[18:04:29] <cehteh> a lot cams have some latency
[18:05:00] <cehteh> just av and analog monitor is sometimes really what you want
[18:06:05] <MartinR90> Can you recommend good book on uCs architecure in general ? Memory -> CPU -> Instruction Featch -> Architecure -> Instruction Flow etc..
[18:08:57] <lorenzo> MartinR90: computer organization and design by patterson / hennessy
[18:09:10] <julius> thats a nice picture the moebius does
[18:09:27] <lorenzo> covers x86, armv7 mostly
[18:09:59] <MartinR90> lorenzo, thanks
[18:10:12] <lorenzo> for something more uC specific just read datasheets
[18:10:12] <julius> cehteh, since i dont want to record it and the camera is mounted on the plate, i went for the cheapest 22€ i could find. crappy picture. but at least you know if there are kids, dogs or elves moving around
[18:10:41] <julius> it also got night vision
[18:12:16] <Lambda_Aurigae> MartinR90, microcontroller is no different from a computer,,,only all on a chip..
[18:12:43] <Lambda_Aurigae> there are some which are harvard architecture, some which are von newman architecture, and some which are kind of hybrid.
[18:14:24] <Lambda_Aurigae> julius, there are dozens of backup cameras out there that have camera, display, and all the hookups premade...not so good for your average hacker mentality but they still work..
[18:14:25] <julius> cehteh, 18.4mbit/s at 1080p....i guess that would really make the rpi cry
[18:14:58] <julius> Lambda_Aurigae, true, but you said the magic word. i kinda wanna hack a bit
[18:15:00] <Lambda_Aurigae> julius, rPI can display 1080p but no way it could record that over usb.
[18:15:43] <julius> uh, and the moebius camera outputs 1.38gb for 10m. so no h264 compression
[18:15:55] <MartinR90> Lambda_Aurigae. yep I know
[18:16:33] <Lambda_Aurigae> I know someone who used a cheap wifi camera mounted on the back of his truck and broadcasts to his phone.
[18:17:37] <julius> i dont really like recording to micro sd, would be full all the time. recording to a non expensive usb stick makes more sense for me
[18:17:53] <julius> that would probably look good
[18:18:02] <julius> but i dont want to look at it while driving
[18:19:04] <Lambda_Aurigae> I want to put a display on the back of my truck with a distance vs speed measurement
[18:19:21] <Lambda_Aurigae> 10 feet for every 10 miles per hour..if you are closer than that I'm slamming on my brakes.
[18:19:45] <Lambda_Aurigae> which, I do anyhow just for the hell of it.
[18:20:56] <Lambda_Aurigae> I just got vnc server and client working on my phone and tablet.
[18:20:57] <julius> thats a good idea
[18:21:08] <Lambda_Aurigae> so I can see the phone'
[18:21:20] <Lambda_Aurigae> so I can see the phone's map display on my tablet while driving.
[18:21:27] <Lambda_Aurigae> much larger, easier to see.
[18:21:49] <julius> then you probably found way to hold the pad while driving?
[18:21:51] <Lambda_Aurigae> 10 inch vs 5 inch.
[18:21:53] <Lambda_Aurigae> it'
[18:21:56] <Lambda_Aurigae> it's mounted.
[18:22:07] <julius> very nice
[18:22:13] <Lambda_Aurigae> so I can glance down and see it...right in front of the radio which I seldom use.
[18:22:50] <julius> its quite fascinating what you can buy for not that much money
[18:23:10] <julius> ive seen a cheap rear view camera that also displayed distance to the back
[18:23:20] <Lambda_Aurigae> yeah.
[18:23:29] <julius> so those sensors are probably not that expensive
[18:23:41] <julius> you just have to figure out how to mount them on the truck
[18:23:46] <Lambda_Aurigae> wife has a ford escape with built in camera...has little lines on the display showing where you will go...and they bend when she turns the steering wheel.
[18:24:02] <Lambda_Aurigae> distance is easy...they are little ultrasound sensors.
[18:24:24] <Lambda_Aurigae> wife's car has them too...it beeps at you when you are about to hit something...the faster the beeping the closer the object is.
[18:24:29] <Lambda_Aurigae> they are mounted in the rear bumper.
[18:25:06] <Lambda_Aurigae> I have similar toy robotics ultrasound sensors but the range on those is only about 2 meters.
[18:25:36] <julius> ok, you can drill in the bumper.
[18:25:40] <Lambda_Aurigae> ultrasound/ultrasonic
[18:31:19] <julius> keep me updated what kind of sensors you buy
[18:31:35] <julius> could be interresting for a friend of mine
[18:31:59] <Lambda_Aurigae> I doubt I will make it....one of the many funzie projects on my board to do when I have time and funds.
[18:32:07] <Lambda_Aurigae> one of a couple dozen right now.
[18:32:34] <Lambda_Aurigae> it is a couple of steps above the caltrop dispenser for the truck.
[18:33:14] <Lambda_Aurigae> however, I just moved one project up the ladder a bit.
[18:33:40] <Lambda_Aurigae> I just acquired 9 identical okidata microline 320 printers....time to build my next generation 3d printer/milling machine base.
[18:34:13] <julius> that sounds like a lot of playtime
[18:34:20] <Lambda_Aurigae> the printhead slide rails and positioning systems are much more accurate than what I built from drawer slides, steppers, and allthread.
[18:34:48] <Lambda_Aurigae> one must have playtime to keep one's insanity in check.
[18:35:55] <studdentt> Jartza: ive got a stk500, only thing is to solder wirewraps from pins to som socket
[18:37:05] <Lambda_Aurigae> current on the bench project is a controller and aux display system for KSP.
[18:38:20] <Lambda_Aurigae> hoping to be able to use Jartza's octapentaveega display adapter to drive a 14 inch touchscreen vga monitor to augment the control system.
[18:39:47] <Lambda_Aurigae> the touchscreen monitor has a serial port interface for the touchscreen so I can tie that back to the computer through a usb enabled microcontroller, probably pic32, to enable some aux processing for the touches and display.
[18:41:33] <Lambda_Aurigae> http://www.circuitspecialists.com/csips2002h_hand_held_power_supply.html?utm_source=csips2002h&utm_medium=email_campaign&utm_campaign=emc_00029&utm_source=Circuit+Specialists+Newsletter&utm_campaign=34cf84ef86-EMC_00029_16_January_2016&utm_medium=email&utm_term=0_dd242259e3-34cf84ef86-52892937
[18:41:35] <Lambda_Aurigae> I want!
[18:41:43] <Lambda_Aurigae> that would be an awesome toy.
[19:18:53] <julius> nice
[19:35:44] <t4nk623> Looking for some help with an i2c device - anyone on?
[19:48:40] <nikomo> I gotta ask, do you guys ever actually use the band gap reference that's available in the ADC? looking at the 328, there's a 200mV range and the bandgap could be anything in that range.
[19:56:08] <Casper> it depend on what you want to mesure, a 200mV may still be fine, but I personally use an external
[19:57:27] <nikomo> Yeah I'm just gonna drop in an LM336-2.5, I bought a few of those some time ago
[19:58:11] <Casper> a tl431 can work great too
[19:58:22] <nikomo> yup, don't have any of those on hand unfortunately
[19:58:40] <nikomo> doing a one-off based on what I have in my possession, lol
[21:06:20] <nikomo> first time I want to use an AVR by itself without stupid Arduino in front, it's amazing how badly the Arduino libs limit your thinking
[21:06:43] <nikomo> I think I might still do a POC with Arduino before I do a proper implementation though
[21:13:36] <Casper> the board itself is not too bad
[21:13:40] <Casper> but the libs... ew
[21:14:19] <nikomo> well the problem with using the board, is that now you have to keep looking at the pin mapping to know what is what
[21:15:56] <Casper> yes, but make a cheat sheet and it's okish
[21:16:14] <Casper> depending on what bad decision they took
[21:16:17] <Casper> like one board...
[21:16:31] <nikomo> also, there's that god-forsaken gap
[21:16:47] <Casper> the idiot that designed it decided it was a bright idea to connect the LCD to the precious ADC pins....
[21:16:48] <nikomo> how much is it again, 2mm instead of 2.54mm or something like that?
[21:17:04] <Casper> 2.54mm or 100mils
[21:17:23] <nikomo> The gap is smaller than 2.54mm
[21:17:39] <Casper> gap on what?
[21:17:47] <nikomo> between D7 and D8
[21:17:58] <Casper> on what board?
[21:18:09] <nikomo> Uno, Mega2560, the ARM one
[21:20:10] <Casper> the mega2560 is not arm afaik
[21:20:27] <nikomo> it uses the mega2560, which is why it's called the mega2560
[21:20:33] <nikomo> the ARM one is a different board
[21:20:39] <nikomo> Arduino Due
[21:21:07] <nikomo> had to google a little, but found it. the spacing between D7 and D8 is 160mil instead of 100mil
[21:21:15] <nikomo> so I was wrong, it's bigger not smaller
[21:22:09] <nikomo> regardless, it's one of the more evil things someone could do
[21:22:09] <Casper> I see that gap... yeah... that's stupid
[21:22:15] <Casper> they should have aligned it on a grid
[21:22:30] <Casper> between PWM7/8
[21:22:34] <nikomo> apparently it was one of those things where they had the board all laid out etc. but had to make a quick change
[21:22:45] <Casper> same with analog 7/8
[21:43:30] <studdentt> got 4 bytes out of a can msg )
[21:44:28] <nikomo> wanted timer1 on the 328 for an RC filter DAC - no other part needs those pins. feels good
[21:44:39] <nikomo> now I just have to figure out how to shuffle the other stuff around to make that fit
[22:09:10] * theBear imagines some little resonant tank-ey components all acting casual, maybe one wearing a helmet or something ... in preparation for the RC shake