#avr | Logs for 2016-06-15

Back
[00:59:09] <_ami_> i am confused after looking into http://www.8bit-era.cz/arduino-timer-interrupts-calculator.html
[00:59:54] <_ami_> is n't f_oc = (f_clock / (2 * N * (1 + OC)); ?
[01:01:44] <_ami_> At 1 MHZ and to get 440Hz, OCR should be 141 for prescalar = 8?
[01:06:36] <_ami_> f_oc = (f_clock / (2 * N * (1 + OC)); is mentioned in DS too.
[05:27:38] <veek> what are avr/io2313.h etc
[05:27:40] <veek> vs io.h
[05:27:55] <veek> chip specific detail?
[05:28:48] <veek> also on linux where aret he .inc files
[05:44:30] <veek> any tut that familiarises me with the various gcc options and avrdude without giving me crappy examples
[05:54:32] <Lambda_Aurigae> veek, the io*.h files are chip specific...io.h is a generic header that looks at the cpu definition from the compiler(often set in the makefile) and loads the appropriate io*.h
[05:54:59] <Lambda_Aurigae> there are so many gcc options,,,read the man pages or the website for it.
[05:56:39] <Lambda_Aurigae> http://www.tuxgraphics.org/electronics/200904/avr-c-programming.shtml
[05:56:46] <Lambda_Aurigae> but, yeah, there are examples in there.
[05:58:21] <Lambda_Aurigae> http://www.atmel.com/webdoc/AVRLibcReferenceManual/overview_1overview_gcc.html
[05:58:39] <Lambda_Aurigae> http://www.nongnu.org/avr-libc/user-manual/index.html
[05:58:55] <Lambda_Aurigae> last two are avr-libc pages...and pretty much duplicates of each other but laid out differently.
[05:59:33] <Lambda_Aurigae> http://www.nongnu.org/avr-libc/user-manual/using_tools.html
[05:59:53] <Lambda_Aurigae> http://www.nongnu.org/avr-libc/user-manual/using_avrprog.html
[06:00:49] <veek> thanks checking emm
[06:01:14] <Lambda_Aurigae> I suspect you need to read through the avr-libc manual more than the avr-gcc one..
[06:01:28] <veek> yeah stdlib's always the bigger pain
[06:01:30] <Lambda_Aurigae> avr-gcc is just gcc with avr extensions and targeted for the avr microcontroller.
[06:02:08] <Lambda_Aurigae> it is actually part of the main gcc chain.
[09:25:11] <LeoNerd> Anyone know how well the ADC inputs perform at very low voltages? I.e. close to 0V. I want to measure a sense signal that's down in the milivolt range
[09:28:09] <bss36504> Why not just amplify it? A 10-bit ADC at 3.3V only gives you 3mv/bit resolution.
[09:28:45] <bss36504> And that's assuming there is no noise in the ADC which of course is impossible.
[09:28:51] <LeoNerd> Full range still goes up that high
[09:29:07] <bss36504> Oh, well then you probably just need more bits.
[09:29:22] <cehteh> LeoNerd: i once digged the datasheets and they didnt really recommend that
[09:30:11] <LeoNerd> Hmm.. so maybe Ishould get an external ADC instead. plus I want more bits
[09:30:20] <cehteh> forget the reference, but somewhere are the limits described which are pretty high (differential inputs etc)
[09:30:53] <cehteh> you could use a opamp and this oversampling/decimation thing
[09:30:58] <cehteh> depending on your needs
[09:31:08] <bss36504> A 16 bit at 3.3V is 50uV of resolution, plus I'd assume something with that many bits would have better noise performance.
[09:31:09] <cehteh> ahh .. and some tinys have a gain amplifier
[09:31:16] <bss36504> External is probably the way to go
[09:31:22] <cehteh> if you can use that then you are fine
[09:31:34] <LeoNerd> I don't need fast. So any ol' I²C thing should be fine
[09:31:35] <cehteh> but dunno which if/which megas have that
[09:31:42] <LeoNerd> The higher res ones tend to be slower for the same price
[09:32:07] <LeoNerd> I'm only sampling a few times a second to read out some numbers on an OLED
[09:32:07] <cehteh> gain amp was 20x 40x 100x iirc
[09:32:19] <LeoNerd> which is already I²C attached.. so yay, no extra pins
[09:32:27] <cehteh> ok then
[09:37:00] <carabia> Anyone know of a place where you could easily rip off small (5x8, give or take a few) fonts with different codepages?
[09:37:26] <LeoNerd> Check licence, but maybe the "-misc-fixed-..." X11 bitmap fonts?
[09:37:27] <carabia> i'm really feeling like not making one :(
[09:37:36] <cehteh> terminus ftw
[09:37:50] <cehteh> mhm not that small iirc
[09:37:51] <LeoNerd> At least the larger sizes like 10x20 have /very/ full unicode support, so you should easily be able to find all the relevant glyphs for various legacy 8bit encoding pages
[09:37:57] <cehteh> well there are plenty around
[09:37:59] <LeoNerd> I thought terminus was vector?
[09:38:04] <cehteh> nop
[09:38:57] <carabia> LeoNerd: yesh, 10x20 just starts getting on the larger side. Not sure if the X11s have small enough ones
[09:39:07] <LeoNerd> Oh X11 definitely supplies a 5x8
[09:39:07] <carabia> But yeah, worth a shot. I'll check them
[09:39:28] <LeoNerd> I'm just not sure how complete it will be outside of the ASCII range... 5x8 is not a lot of space to draw the combining accents, for example
[09:40:19] <carabia> I know, it was just an arbitrary size I chose. I can be flexible.
[09:40:20] <_ami_> hey guys, where can i get the few very small round/circle or square size lcds of size equal to touch pad bttons?
[09:40:24] <_ami_> buttons*
[09:40:47] <LeoNerd> -circular- displays are likely not really a thing you can get
[09:40:48] <carabia> _ami_: the small OLEDs should do
[09:41:01] <LeoNerd> I can't recall ever seeing LCD/LED displays that weren't rectangular
[09:41:01] <cehteh> i wonder how much usable characters you can display with 5x8 before it all becomes just unreadable noise
[09:41:04] <carabia> but yes, totally not circular. Or then you're gonna have to throw some serious $$$ on it
[09:41:47] <_ami_> cehteh: i just want to draw 2 characters [] , X and O
[09:41:53] <_ami_> 3 characters*
[09:42:06] <carabia> cehteh: thing is I don't need the _full_ 128 char codepage after ascii. So I'll check an implementation and then modify if needed
[09:43:07] <cehteh> as long you dont need chinese in 5x8 double width :D
[09:43:08] <carabia> _ami_: google small oled, or similar.
[09:43:14] <_ami_> okay
[09:43:23] <carabia> I need bold kanji!!
[09:44:44] <carabia> even 4x8 is readable if you stay within ascii
[09:46:02] <carabia> and i'm drawing to a frame buffer anyway so it's not a big deal if i cross screen page boundary
[09:46:34] <carabia> going bigger, that is
[09:51:30] <carabia> _ami_: quick google came up with a .5" oled of 60x32. Now that's not really square, it's more like 16:9, but defo small enough anyway.
[09:51:54] <_ami_> carabia: on aliexpress?
[09:51:56] <carabia> You're gonna have to fuck around with FFCs, though
[09:52:04] <carabia> I think so, yea
[09:52:49] <carabia> Probably better off going with the ~1" ones that are way cheaper.
[09:53:14] <_ami_> carabia: i wanted to start with some basic lcd to start learning fun with AVR on LCDs. i think a small screen would be easier to know/understand the basic concepts related to this.
[09:53:58] <carabia> _ami_: well i'd probably go with a bigger screen in that case.
[09:54:41] <carabia> first of all, no need to fuck around with ffcs. and well, bigger screens are just easier to read.
[09:54:58] <_ami_> oh, so its other way around.
[09:55:01] <_ami_> good to know
[09:55:13] <carabia> _ami_: i wouldn't know, it's just my two cents on the issue
[09:55:14] <_ami_> 16x2 are the ones to good to start? carabia ^
[09:55:35] <carabia> _ami_: depends. 16x2 are character displays
[09:55:50] <carabia> means they have a memory in which a character set is stored and you can display those on the screen
[09:56:00] <_ami_> hmm
[09:57:23] <_ami_> carabia: my initial plan was to make a tic-tac-toe game in which i use a small lcd screen for each button which shows 0 or X or empty []
[09:57:29] <carabia> well technically with those you can draw stuff too because you can overwrite the character memory but that starts to get really fucking wonky heh
[09:57:51] <carabia> but if you really want to draw stuff on the screen apart from letters, you need a "graphic" display
[09:58:33] <carabia> if i were you, i'd get a 128x64 with a ks0108 or compatible driver on it
[09:59:00] <LeoNerd> The SSD1306 OLEDs are also quite nice for that
[09:59:24] <carabia> yeah, but oleds are just so small!
[10:00:24] <carabia> also a ks0108 lcd is nicer than an oled if you're working with 5 volts. iirc you don't wanna drive ssd1306 with 5 volt logic
[10:01:10] <carabia> then again you can get breakouts and dev boards and what not that have logic level shifting and whatnot...
[10:01:21] <carabia> and a couple more whatnots, apparently
[10:06:22] <carabia> oh and _ami_ I totally missed what you wrote. Yeah, if you really want to do that, you can. You had 3x3 in mind? Unless you want to break a bank, you get cheap (< 1") oleds with ffc connectors (not breakouts, costs $$$)
[10:06:46] <_ami_> yup 3x3
[10:07:53] <carabia> You can wire them all up in a single spi-bus, but you're gonna need a way to connect them physically...
[10:08:42] <carabia> for a (quite nuts) project like so, you would preferably spin a pcb for it but... :)
[10:09:44] <_ami_> i want to make this for my toddler. so i won't mind few $$$ though. i would few new stuffs also. so its a win-win situation for me. :P ;)
[10:09:59] <_ami_> would learn*
[10:10:41] <carabia> You know, you could get a bigger screen, and use one of those touch panels on top of it
[10:11:04] <_ami_> yeah, i know. :)
[10:11:12] <carabia> if you'd use single oleds in a 3x3 matrix, if you'd use breakouts you'd probably drop $100 or so on the screens alone?
[10:11:38] <LeoNerd> Nah.. Ijust bought an SSD1306 on a breakout board for £3
[10:11:38] <_ami_> but real hardware is more fun.
[10:11:48] <LeoNerd> ... that said it's yet to arrive so I can't say for definite that it *works*
[10:12:11] <_ami_> LeoNerd: i am still waiting for my first order from aliexpress to arrive. :/
[10:12:25] <_ami_> the wait is daunting
[10:12:27] <LeoNerd> I aliexpressed once, ever.
[10:12:31] <LeoNerd> It was fine. Just sloooow
[10:12:42] <LeoNerd> +5/+12V dualoutput PSU module
[10:12:57] <LeoNerd> You can get tonnes of cheap single rail ones on eBay, but it seems no duals for love nor money
[10:13:04] <LeoNerd> ... and I was prepared to offer either ;)
[10:13:47] <carabia> tmi
[10:14:57] <carabia> _ami_: yeah it's fun, but it would just be one hella expensive tictactoe. And not practical in any way, shape or form
[10:15:12] <_ami_> :)
[10:40:07] <_ami_> one q, is it necessary to wait for few micro Seconds in between clock pulse after sending pulse to data line in Shift register (74HC595)? i think it might depend on shift register ?
[10:40:12] <_ami_> https://github.com/amitesh-singh/amiduino/blob/master/avr/avr_programmming/shiftreg/shift.c#L59 li
[10:40:18] <_ami_> line: 59
[10:40:29] <_ami_> [=]]
[10:40:42] <LeoNerd> Have a look at the timing infomration in he chip's data sheet. Various 74xx families differ in their timing requirements
[10:41:02] <LeoNerd> That's what the next two letters mostly mean... HC == highspeed CMOS, LS == "low speed", etc..
[10:42:00] <_ami_> /-)<M?n.b60v,o9560p.7}*(<
[10:42:00] <_ami_> )>_https://github.com/amitesh-singh/amiduino/blob/master/avr/avr_programmming/shiftreg/shift.c#L59__>
[10:42:00] <_ami_> )<(}|*+/h-.0g,9fm8dnsb76av5A62B375O,6P.7B[]
[10:42:00] <_ami_> B7P.6,5CMIZ32BY63C5MI,O6P.7}m
[10:42:25] <_ami_> ah, sorry, my kid is on keyboard :/
[10:42:26] <_ami_> :P
[10:42:27] <Thrashbarg> no carrier
[10:47:22] <_ami_> thanks LeoNerd, i shall check.
[11:46:03] <_ami_> LeoNerd: https://github.com/amitesh-singh/amiduino/blob/master/avr/avr_programmming/shiftreg/shift.c => this seems to work on simulator but not on actual hardware. the LED blinks for very small of time. and then off.
[11:46:29] <_ami_> any hints please?
[11:47:33] <LeoNerd> No idea
[11:47:38] <LeoNerd> Why are you not using the SPI port?
[11:49:57] <LeoNerd> Also lines 5/6 look suspect
[11:50:06] <LeoNerd> I expect there's a negation missing ;)
[11:59:28] <_ami_> LeoNerd: that line is only for knowing me that i am building for atmega16a, its just a compiler warning.
[12:00:58] <LeoNerd> Eh.. seems odd but whatever
[12:01:05] <LeoNerd> Anyway you likely want to use the SPI port for this
[12:03:03] <_ami_> LeoNerd: i got the problem though. the problem was in my head. :P i was assuming that if i send some DATA to shift register, 595 will keep it for a while. :P this is not the case :)
[12:03:10] <_ami_> stupid of me! :
[12:03:28] <_ami_> actually to keep led on, i need to keep sending data in main loop.
[12:03:40] <LeoNerd> You shouldn't have to, no
[12:03:53] <LeoNerd> You just write to the SR when you want it to change state. It'll keep state inbetween time
[12:04:10] <_ami_> oh
[12:04:50] <_ami_> if i set Q1 of 595 high, it will remain ON for rest of time until i change the data bit again?
[12:05:03] <LeoNerd> That's the point of the SR, yup
[12:05:08] <_ami_> oh,
[12:05:56] <_ami_> LeoNerd: even i set Q1 high in setup (before while())?
[12:06:17] <LeoNerd> ?
[12:06:29] <_ami_> shift_out(...., 0b00000001, MSB); while (1);
[12:06:49] <_ami_> this will keep Q0 high always?
[12:06:51] <LeoNerd> I'm not even following your questions any more
[12:06:57] <_ami_> umm.
[12:07:01] <LeoNerd> You write an entire byte of 8 bits to the SR
[12:07:07] <LeoNerd> When you do that, it puts those 8 bits on its output pins
[12:07:16] <LeoNerd> If you don't want to change some pins, leave them at whatever level they are when you write
[12:07:26] <LeoNerd> If you always write the same number, then yo'ull always see the same state on the pins
[12:07:32] <LeoNerd> If you write different numbers, those pins that differ, will change
[12:07:37] <LeoNerd> I don't feel this is a hard concept
[12:08:45] <_ami_> http://pastebin.com/wr1hJPC6 LeoNerd^
[12:09:03] <LeoNerd> Can we avoid pastebin.com in future please? anytihng but that
[12:09:29] <_ami_> sure, i will not use it next time :)
[12:09:41] <LeoNerd> Anyway, you do a thing once on startup then idle-spin.. so that'll set up state once then leave it there
[12:09:54] <LeoNerd> But stlil my original question stnads: why are you bitbanging this and not using the SPI port?
[12:10:04] <LeoNerd> I'm reasonably sure the mega16A has an SPI port
[12:10:16] <_ami_> LeoNerd: i need to learn that SPI concept. i started with basic.
[12:10:19] <LeoNerd> It is far less likely to include all the bugs and mistakes in your original code
[12:10:22] <LeoNerd> ... you are _implementing_ SPI
[12:10:28] <LeoNerd> This is exactly what you have written
[12:10:38] <LeoNerd> Just you're doing it yourself in code, instead of just getting the hardware to do it
[12:10:54] <_ami_> ah, i am doing in software.
[12:10:57] <_ami_> hmm..
[12:11:47] <_ami_> LeoNerd: my question in this case is "To keep one port of 595 high, i do need to set it high everytime in a loop? right?
[12:11:59] <LeoNerd> I'm not sure why you say keep
[12:12:10] <LeoNerd> If you set it high once, and then never talk to the chip again, it will remain high
[12:12:20] <LeoNerd> If you keep talking to the chip, it will keep following whatever state you most recently told it to be in
[12:12:32] <_ami_> this is not happening currently for me.
[12:12:44] <_ami_> the 595 resets
[12:12:46] <LeoNerd> Wel, no
[12:12:50] <LeoNerd> that's because your code is wrong ;)
[12:13:01] <LeoNerd> If you use the SPI module properly, then you might actually be talking SPI correctly
[12:13:05] <LeoNerd> instead of wrongly, as your code is doing
[12:13:13] <_ami_> oh
[12:13:54] <_ami_> LeoNerd: ok, i shall google abt it.
[12:21:29] <_ami_> LeoNerd: btw, whats the problem with the code?
[12:21:35] <LeoNerd> the clock timing?
[12:21:46] <LeoNerd> You're totally not obeying whatever S&H timing your chip likely has
[12:21:56] <LeoNerd> So stop fiddling with that and just use the SPI module. Set its clock correctly
[12:21:59] <LeoNerd> then all will be fine
[12:22:37] <_ami_> LeoNerd: do you hv any sample on SPI interaction with shift register?
[12:24:55] <LeoNerd> Not offhand
[12:24:58] <LeoNerd> it's about four lines long
[12:25:04] <LeoNerd> seriously, just go read about SPI hardware on ATmega
[12:25:08] <LeoNerd> There's likely a billion articles about it
[12:25:18] <LeoNerd> Probably even examples of driving LEDs on a '595 as in exactly your case
[12:25:25] <LeoNerd> This ought to be textbook first example 101 stuff
[13:49:27] <xa0z> Tom_itx, It's 16mhz for the record.
[14:09:15] <rue_shop3> want 595 code?
[14:20:12] <rue_shop3> #include "74LS595.h"
[14:20:12] <rue_shop3> void LS595Send (unsigned char bits) {
[14:20:12] <rue_shop3> unsigned char temp;
[14:20:12] <rue_shop3> for( temp = 128; temp != 0; temp = temp >> 1) {
[14:20:12] <rue_shop3> if ( (bits & temp) == 0 ) {
[14:20:13] <rue_shop3> LS595SendZero();
[14:20:15] <rue_shop3> } else {
[14:20:17] <rue_shop3> LS595SendOne();
[14:20:19] <rue_shop3> }
[14:20:21] <rue_shop3> }
[14:20:23] <rue_shop3> }
[14:20:53] <rue_shop3> #define LS595StrobeH() SetBit(LS595Strobe, LS595Port)
[14:20:53] <rue_shop3> #define LS595StrobeL() ClearBit(LS595Strobe, LS595Port)
[14:20:53] <rue_shop3> #define LS595DataH() SetBit(LS595Data, LS595Port)
[14:20:53] <rue_shop3> #define LS595DataL() ClearBit(LS595Data, LS595Port)
[14:20:53] <rue_shop3> #define LS595ClockH() SetBit(LS595Clock, LS595Port)
[14:20:53] <rue_shop3> #define LS595ClockL() ClearBit(LS595Clock, LS595Port)
[14:20:55] <rue_shop3> #define LS595ClockPulse() LS595ClockH(); NOP(); LS595ClockL()
[14:20:57] <rue_shop3> #define LS595SendOne() LS595DataH(); LS595ClockPulse()
[14:20:59] <rue_shop3> #define LS595SendZero() LS595DataL(); LS595ClockPulse()
[14:21:57] <Fleck> ban!
[14:21:58] <Fleck> :D
[14:22:17] <rue_shop3> who was supposed to set up the wiki?
[14:22:24] <rue_shop3> oh, different channel, nevermind
[14:23:53] <rue_shop3> note that after calling Send for each byte in the chain, you have to set and reset the strobe line
[14:24:23] <rue_shop3> / turn all steppers off
[14:24:23] <rue_shop3> LS595StrobeL();
[14:24:23] <rue_shop3> LS595Send (0x00);
[14:24:23] <rue_shop3> LS595StrobeH();
[14:30:05] <rue_shop3> well I suppose I can work on my cam software
[14:31:04] <_ami_> rue_shop3: tanks
[14:31:06] <_ami_> thanks
[14:31:30] <rue_shop3> there are still some things to work out, but I think they are simple enough that you will be ok
[14:31:41] <rue_shop3> #define SetBit(BIT, PORT) (PORT |= (1<<BIT))
[14:31:41] <rue_shop3> #define ClearBit(BIT, PORT) (PORT &= ~(1<<BIT))
[14:31:45] <rue_shop3> #define NOP() asm volatile ("nop"::)
[14:33:19] <_ami_> rue_shop: i think iwrote the code ok..
[14:33:41] <rue_shop3> well that code DOES work
[14:34:03] <rue_shop3> and it you tweek polarities it works with a 40.....
[14:34:05] <_ami_> rue_shop3: https://github.com/amitesh-singh/amiduino/blob/master/avr/avr_programmming/shiftreg/bitbang/shift.c
[14:34:28] <_ami_> rue_shop3: can i get your full code somewhere on github?
[14:34:32] <_ami_> or pastebin
[14:35:05] <rue_shop3> its 6 files
[14:35:13] <rue_shop3> want a tgz?
[14:36:04] <_ami_> yeah, ok
[14:37:04] <_ami_> rue_shop2: my mcu runs at 8Mhz internal oscillator
[14:37:09] <_ami_> this should not be a problem?
[14:37:11] <_ami_> right?
[14:37:46] <rue_shop3> http://ruemohr.org/%7Eircjunk/robots/arm4/Steppermotion3.tgz
[14:37:57] <rue_shop3> I run mine at 16
[14:38:03] <rue_shop3> so you should be fine
[14:40:47] <_ami_> rue_shop3: also i use HC595 which is i think is FASTER than LS one
[14:41:18] <rue_shop3> iirc yes
[14:42:14] <_ami_> so will it work for HC too? it seems like My HC595 clock speed is way higher than the atmega16a
[14:42:24] <rue_shop3> yup
[14:42:47] <_ami_> I tried with f_clock/2 on SPI
[14:42:49] <_ami_> as well.
[14:43:39] <carabia> I'm noooot that much of a software person, so can any of you software-nerds explain PROGMEM for moi, please?
[14:44:02] <_ami_> rue_shop3: https://github.com/amitesh-singh/amiduino/blob/master/avr/avr_programmming/shiftreg/spi/spi.c
[14:44:30] <carabia> is it enough to declare a variable as [type] PROGMEM var, for it to be written to flash?
[14:44:56] <_ami_> carabia: when u use PROGMEM, there is only one copy
[14:45:14] <_ami_> consider an example: lcd_puts("Hello Ami");
[14:45:36] <carabia> eh, yes?
[14:45:51] <_ami_> in this case, "Hello Ami" is a string literals and it would be stored into data section
[14:45:56] <_ami_> as well as in RAM when loaded.
[14:46:14] <carabia> yeah now that's all fine and dandy but not what I asked
[14:46:33] <_ami_> carabia: yes, to your answer!
[14:46:47] <rue_shop3> 40...
[14:47:01] <carabia> I want certain variables written into the flash, and I'll load them from there when I need to. Can I do this with just the PROGMEM keyword or do I need to perform other kind of black magic aswell?
[14:47:44] <_ami_> PROGMEM if its constant.
[14:47:49] <_ami_> e.g. SOUND ints
[14:47:50] <_ami_> etcs
[14:47:56] <carabia> yeah I know that.
[14:47:56] <_ami_> or strings
[14:48:01] <rue_shop3> aha! 4094
[14:48:20] <rue_shop3> with a bit of polarity tweeking it also works with CD4094 chips
[14:49:01] <bss36504> carabia: http://www.nongnu.org/avr-libc/user-manual/pgmspace.html
[14:49:38] <_ami_> rue_shop3: did u test on 74HC595 as well?
[14:50:00] <rue_shop3> the HC595 is SO cheap, thats all I use
[14:50:11] <_ami_> i shall port ur bitbang code into my code to try at my end.
[14:50:19] <_ami_> 10 mins.
[14:50:40] <rue_shop3> I could be asleep in 10
[14:50:58] <carabia> bss36504: yeah, i read that aswell. It was as I thought it would be. Thanks anyway.
[21:43:48] <retrosenator> hi
[22:10:35] <_ami_> LeoNerd: yo, found the issue. it was my connection problem though. OE should have been grounded. :/
[22:10:42] <_ami_> waster 2-3 hrs in this.
[22:11:08] <Casper> connection issues are usually the biggest time waster
[22:12:24] <_ami_> Casper: indeed. it happens a lot when you try something new. :P
[22:12:46] <Casper> yup
[22:12:51] <Casper> or just go to sleep
[22:13:05] <Casper> as in you wake up and it magically stopped working
[22:14:22] <_ami_> yeah, thats what i did yesterday, it was not working at all.. Today's morning i tried it from scratch (code and connection both) and it worked. looked into tutorials more closely
[22:15:23] <_ami_> i am proud to say that now i know how 74HC595 actually works.
[22:15:45] <_ami_> I learned both bitbang and spi.
[22:16:13] <_ami_> i was scared of spi until LeoNerd spanked me. :P
[22:16:33] <_ami_> and spi is actually a lot easier than bitbang though :)
[22:22:16] <_ami_> i should write an article abt to it to help beginners like me. :)
[22:22:51] <_ami_> a best article covering both spi and bitbang
[23:11:14] <Snert> for someone that uderstands what assembeler even is.
[23:11:27] <Snert> but most noobs wouldn't know.
[23:13:23] <Casper> yeah, and people are too lazy to learn the basics...
[23:15:23] <Snert> alot of them don't even do the arduino tutorials. Either on the .cc site or anywhere else.
[23:16:02] <Snert> instead they buy $1.00 boards off ali or ebay and show up here bleeding how to make it work.
[23:16:21] <Casper> exactly
[23:16:44] <Snert> when they coulda spent $9.95 for an adafruit board and had excellent docs and a clear path to success.
[23:17:21] <Casper> or just google for the datasheet of the IC, and spend a few minutes to understand...
[23:17:25] <Casper> but no...
[23:17:38] <carabia> "bitbanging" is not intrinsic. It's mostly always referred to as implementing an interface in an end-user software implementation.
[23:17:44] <Casper> "I bought this shield, it don't work"... code it?
[23:18:20] <carabia> implementing an interface with - not in - rather
[23:21:28] <Casper> some even go as far as: "there is multiple ground and vcc pin, which one must I use?" "all of them!" "no, I want to use only one" "you must connect all of them, or it won't work proprelly or can damage it" "but which one much I use?" ....
[23:27:40] <veek> which would be better simavr or simuLavr
[23:28:33] <Casper> trueavr
[23:29:08] <veek> heh
[23:31:14] <veek> Casper, are you sure that exists - goog three up nothing
[23:31:18] <veek> for linux
[23:32:17] <Casper> sure, real avr does exists!
[23:32:45] * veek glares at Casper
[23:34:23] <veek> hmm simulavr is in apt but simavr isn't