Back
[03:12:54] <BusError> Hey guys, does anyone used an AVR to program another (smaller) AVR? -- ie using a m32 to flash a m88 for example... I'd like to put the 'target' firmware high in the flash of the bigger AVR, and have it program the smaller one without any cables..
[03:13:35] <Valen> there is nothing inherently stopping you doing that
[03:13:43] <improvnerd> BusError: I’ve used an Arduino to do that.
[03:13:52] <BusError> I know. just asking if someone had done it before
[03:14:11] <improvnerd> http://arduino.cc/en/Tutorial/ArduinoISP
[03:15:09] <BusError> yeah but that uses a cable... it's a 'conduit'..
[03:15:30] <BusError> well perhaps I'll hack uspasp firmware...
[03:15:48] <improvnerd> The Arduino board reads data off the serial port and writes it to the SPI connector, and toggles the reset line of the programmed device.
[03:16:05] <improvnerd> You want to write from an AVR to an AVR with no computer involved?
[03:16:19] <BusError> yep. make some sort of 'programming stick'
[03:17:06] <BusError> I program the programming stick on my bench, got to the device anywhere, plonk it on the ISP connector and zoom, reprogrammed
[03:17:18] <improvnerd> That’d be tricky, but not impossible.
[03:17:55] <Valen> I'd put a memory chip in your stick to be honest
[03:18:15] <Valen> also it sounds like the sort of thing that probably would have already been done?
[03:18:26] <improvnerd> One approach would be to use a third AVR to record the serial data sent across from the desktop, and then play it back.
[03:18:34] <BusError> yeah thats why I asked...
[03:19:04] <Valen> heh, raspi + lipo?
[03:19:33] <improvnerd> Or you could hack the ArduinoISP sketch to write the incoming bytes to flash memory, and then play them back itself.
[03:19:51] <Valen> http://www.kanda.com/products/Kanda/HH0120.html ?
[03:20:31] <improvnerd> You might need to go to an external flash memory chip, because the data being sent across the wire is less compact than once it’s stored in program memory.
[03:22:09] <improvnerd> Oh, I bet you could write a cloner! Read the program memory from a “master” AVR chip and write it to a “copy” chip.
[03:22:32] <improvnerd> Would just involve SPI, probably not rocket science.
[03:34:49] <BusError> I already wrote a SPI driver, for linux tho, would need to trim it down
[03:38:03] <improvnerd> You could use the Arduino one. I assume you could also do it by hand, but I’m not that far through the AVR Programming book yet.
[03:39:02] <Tom_itx> there are standalone avr programmers
[03:44:10] <Tom_itx> http://www.adafruit.com/products/462
[03:44:49] <Tom_itx> http://www.fischl.de/ispnub/
[03:45:46] <improvnerd> It looks like the hardware does all the work. You just write a byte tot the SPDR and wait for the SPIF bit on the SPSR to go high.
[03:47:01] <BusError> http://oomz.net/ftdi_avr_isp.c wrote that a while back, I have the basic logic, I'm sure I could port it down to AVR
[03:49:41] <improvnerd> Here’s the standalone programmer tutorial from AdaFruit.
https://learn.adafruit.com/standalone-avr-chip-programmer
[03:50:49] <improvnerd> You use a program called Optiloader that includes the hex file that you want to burn onto the new chip.
[03:51:00] <improvnerd> Works with Arduino or standalone AVR as the programmer.
[04:03:02] <BusError> this is great thanks improvnerd
[04:05:43] <Ox4C4A> Hello! I'm using AVR Studio 6 to program an Attiny 9. Recently I turned off code optimization, since it messed with the algorithm and suddenly during compiling, two errors pop, both with the following text "operand out of range:0x3f"
[04:06:10] <Ox4C4A> My problem is, that I can't seem to find these files
[04:06:17] <Ox4C4A> in which the error is shown
[04:06:37] <Ox4C4A> the source file compiled is CPP, but the errors are shown in some temporary *.s files
[04:06:50] <Ox4C4A> Can anyone give me a hint on how to tackle the problem?
[04:07:27] <Timmy> i've used a 11.0592MHz XTAL for a ATMega8. what should I enter for F_CPU? 11059200L ?
[06:18:30] <Lambda_Aurigae> ok..methinks next week is play with cap sensing technology on AVRs time.
[07:19:29] <BusError> is he maintainer(s) of avr-libc hanging around here?
[07:20:24] <Tom_itx> none i've ever seen
[07:21:25] <BusError> current version in debian sid has borken bits. missing/wrong declarations etc
[07:21:45] <Tom_itx> why the hell would he be using CPP on a Tiny 9 anyway
[07:24:25] <Valen> could you guys cast your eyes over
http://i.imgur.com/ywxm3Dk.png
[07:24:33] <Valen> its the schematic for my stepper driven clock
[07:24:50] <Valen> the "ups with inrush" has a 1.5F cap on it
[07:25:18] <Valen> anything glaringly wrong, or any other suggestions?
[07:28:43] <Valen> (i'll take compliments too lol)
[07:31:22] <Tom_itx> keep D+ D- the same length
[07:31:47] <Tom_itx> and short
[07:32:30] <Tom_itx> i'd put those supressors on em
[07:35:39] <Valen> I know I should....
[07:36:19] <Tom_itx> 650-PESD0603-240
[07:37:26] <Tom_itx> one on D+ D- to gnd
[07:39:49] <Valen> I normally use a dedicated USB protection IC if I'm doing that
[07:40:54] <Tom_itx> you could use a resonator instead of the crystal if you wanna save a bit
[07:41:14] <Valen> I didn't think resonators were really good enough for usb
[07:41:23] <Tom_itx> i found some that work good
[07:41:32] <Valen> not worth the risk lol
[07:41:42] <Tom_itx> iirc they're made for usb
[07:42:03] <Valen> yeah something like this
http://au.element14.com/stmicroelectronics/usblc6-2p6/diode-array-tvs-usb2/dp/1295310
[07:43:03] <Tom_L> http://search.murata.co.jp/Ceramy/CatalogAction.do?sHinnm=? &sNHinnm=CSTCE16M0V53-R0&sNhin_key=CSTCE16M0V53-R0&sLang=en&sParam=CSTCE
[07:43:19] <Tom_L> http://www.mouser.com/ProductDetail/Murata/CSTCE16M0V53-R0/?qs=%2fha2pyFaduhhXjHR0Z3WgVvZP5Z9PaySiX%2f9%2fizYDMG1BrpSTX4aLw%3d%3d
[07:43:31] <Tom_itx> i've used hundreds of those
[07:44:31] <Tom_itx> your xtal will cost 2x that probably
[07:44:33] <Tom_itx> or more
[07:44:40] <Tom_itx> the ones i initially used did
[07:46:13] <Valen> as a % of the overall cost its nothing
[07:46:33] <Tom_L> http://www.digikey.com/product-detail/en/NX3225SA-16.000MHZ-STD-CSR-1/644-1049-1-ND/1128921
[07:46:36] <Valen> I appreciate the advice, but for this paticular job its not worth doing something new ;->
[07:46:39] <Tom_L> 8pf
[07:46:56] <Tom_L> i was also after space savings
[07:47:05] <Valen> i mean its going to be a stepper motor driving a clock and it has an atmega driving it ;->
[07:47:52] <Tom_L> those were the smallest xtals i could find
[07:48:13] <Valen> yeah I have seen those, pretty small as i recall
[07:48:41] <Tom_L> http://tom-itx.no-ip.biz:81/~webpage/boards/atmega32u4/atmega32u4_1.jpg
[07:50:47] <Tom_itx> hard to read the values etc on your png but it looks like you've covered most of it pretty well
[07:51:16] <Tom_itx> HWB and RST are right
[07:51:39] <Valen> looks like you got your modem sorted out
[07:51:49] <Tom_itx> router?
[07:52:01] <Tom_itx> no i wound up getting another one until i can sort it out
[07:53:01] <Tom_itx> there was something really picky about the DVR app it didn't like
[07:53:35] <Valen> sounds weird
[07:54:01] <Tom_itx> nothing i could figure out
[07:54:11] <Tom_itx> i was on their forum with no luck
[13:11:20] <wondiws> hi there
[13:16:01] <wondiws> are virtual methods an issue on avr, because I've got problems with them
[13:42:33] <thekindlyone> Using an atmega 32 trying to get ADC from a LDR, I have set
[13:42:34] <thekindlyone> ADMUX=(1<<REFS0);
[13:42:34] <thekindlyone> Do I need to connect Avcc to Vcc? and what do I do with the pin 31 which says GND, Do I have to ground it?
[13:43:21] <Thrashbarg> yes
[13:43:33] <thekindlyone> to both?
[13:43:43] <Thrashbarg> yes
[13:44:33] <Thrashbarg> usually when there's a power pin, you connect it to said power lol
[13:46:02] <thekindlyone> I tested the LDR with an LCD connected and it was working with AVcc, Aref and the GND(pin 31) not connected and it gave accurate looking values.
[13:46:41] <thekindlyone> but doing the same in this other code is producing unexpected delays
[13:46:50] <thekindlyone> could this be the reason?
[13:48:27] <Thrashbarg> you could always try it and see
[14:13:46] <RikusW> ALWAYS connect AVcc
[14:13:51] <RikusW> to Vcc
[14:14:09] <RikusW> or use a 10uH inductor + a 100nF cap on AVcc
[14:35:58] <Tom_itx> funny... that's what the data sheet says
[14:46:49] <Casper> thekindlyone: failing to connect AVCC can result in damage or malfunction
[14:46:57] <Casper> same with GND
[14:47:09] <Casper> so never forget to wire all of them
[14:47:24] <thekindlyone> hmm, did that. sadly if it had any effect can only be found out after atleast 30 minutes.
[14:47:26] <Casper> on some chip you have AVCC and AGND...
[14:51:17] <thekindlyone> okay I have another question.. say my atmega32A is set with 1Mhz internal RC and my avrgcc makefile has F_CPU as 8Mhz, what issues do you expect?
[14:51:53] <wondiws> depends on if you use F_CPU macro in your code
[14:52:12] <thekindlyone> I don't. In that case it doesn;t matter right?
[14:52:26] <wondiws> no, F_CPU doesn't do anything then
[14:52:33] <wondiws> you need not define it in the Makefile either
[14:52:46] <thekindlyone> is there a way to find out what fewquency the avr is set on?
[14:52:52] <thekindlyone> *frequency
[14:53:15] <wondiws> you can read the flags of the pll some way with your programmer
[14:53:39] <thekindlyone> I have usbasp
[14:53:51] <wondiws> but you use avrdude?
[14:54:01] <thekindlyone> yea
[14:54:29] <thekindlyone> I did set the bits , but forgot what settings
[14:55:07] <wondiws> you can read them back
[14:55:11] <wondiws> but I'm in game now ;)
[15:01:25] <thekindlyone> thanks wondiws
[15:02:22] <malinus> thekindlyone, are you implying that windows servers even are a thing?
[15:20:31] <thekindlyone> malinus : what do you mean?
[15:20:54] <malinus> nvm. just joking around
[15:22:47] <Jartza> hmmh. modem is working so reliably now that I'm pondering to implement two-way-comm
[15:23:16] <Jartza> except it's much harder on android to make the modem, as they don't have pin-change-interrupt easily available ;)
[15:23:47] <thekindlyone> why doesn't
http://pastie.org/9332142 work?
[15:24:16] <thekindlyone> I intend it to toggle that pin every 5 seconds
[15:25:12] <Jartza> what chip?
[15:25:22] <thekindlyone> atmega 32A
[15:26:23] <Jartza> why "1 << 0"
[15:26:28] <Jartza> why don't you use pin name?
[15:26:38] <Jartza> like "1 << PB0" etc
[15:26:48] <twnqx> well, first you could try to toggle the LED in your interrupt routine, just to check if it wilöl blink in #1
[15:26:57] <twnqx> second
[15:26:58] <thekindlyone> that is working
[15:27:04] <twnqx> you need to declare the secodns volatile
[15:27:17] <thekindlyone> if I toggle in the ISR it works
[15:27:19] <twnqx> or the compiler will assume no change
[15:27:24] <thekindlyone> what voatile? how?
[15:27:29] <twnqx> because of optimizations
[15:27:35] <twnqx> volatile uint8_t seconds=0;
[15:27:39] <twnqx> instead of what you have
[15:28:24] <twnqx> third, you might just want to sleep inside your main loop
[15:28:25] <thekindlyone> oh, great. it works.
[15:28:48] <thekindlyone> how?
[15:29:07] <twnqx> #include <avr/sleep.h>
[15:29:20] <twnqx> before your main loop, set_sleep_mode (SLEEP_MODE_IDLE);
[15:29:43] <twnqx> first thing in your mainloop, sleep_mode ();
[15:29:52] <twnqx> so the chip will sleep until interrupt triggers
[15:30:28] <thekindlyone> and after interrupt triggers it will evaluate the rest of the stuff in the main?
[15:30:31] <twnqx> yes
[15:30:37] <twnqx> and then sleep again until next interrupt
[15:30:46] <thekindlyone> oh my god! that is awesome!
[15:30:55] <thekindlyone> thanks
[15:31:06] <twnqx> you're welcome
[15:31:08] <thekindlyone> this might solve my heating problem
[15:33:08] <twnqx> as a simple rule, if you modify a variable asynchronously (e.g. from an interrupt handler) you need to declare it volatile, or the compiler assumes that it doesnät change
[15:33:34] <twnqx> and as such optimizes the test away, sees that nothing ever happens in your loop, and kills all code ;)
[15:34:14] <thekindlyone> I see
[15:34:32] <twnqx> volatile means "assume nothing, always check that varaible"
[15:34:44] <twnqx> because its content is volatile :)
[15:34:53] <thekindlyone> I never thought I would have to explicitly state that.
[15:35:19] <thekindlyone> variable and volatile are almost synonyms
[15:35:39] <twnqx> few people that don't do low-level programming (e.g. no operating system) know about this :)
[15:36:07] <thekindlyone> so this is in general gcc too?
[15:36:12] <twnqx> it could of course also appear with inter-process communication via shared memory, or threaded programming
[15:36:15] <twnqx> any C
[15:36:20] <thekindlyone> I see
[15:37:20] <thekindlyone> if I have multiple interrupts
[15:37:54] <thekindlyone> can I set which interrupt will wake up the mainloop?
[15:38:03] <twnqx> no, any interrupt will
[15:38:35] <twnqx> and don't use sleep_mode() inside interrupt handlers, the program most likely won't work
[15:38:54] <twnqx> rather live with the few extra wake-ups
[15:51:39] <thekindlyone> this is the code
http://pastie.org/9332200 and this is the schematic
http://i.imgur.com/cpT28d3.png
[15:52:55] <thekindlyone> I need the relay to be set on when the ADC is below 700 AND the pir is high. Then I need to keep the relay on till 3 mins after last PIR high(motion stopped)
[15:53:07] <thekindlyone> after which the relay can turn on again
[15:53:13] <thekindlyone> *turn off again
[15:53:49] <thekindlyone> it works, but after being some 2-3 hrs, it responds very slow
[15:53:55] <thekindlyone> like 30-40 secs slow
[15:54:17] <thekindlyone> but the turning off part is on time.
[15:54:22] <thekindlyone> what could be the problem
[15:55:20] <Tom_itx> not an exact clock source?
[15:55:29] <Tom_itx> are you counting ALL the cpu cycles?
[15:56:30] <Tom_itx> Jartza, you do android programming?
[15:56:37] <Jartza> yes
[15:56:52] <Tom_itx> easy as avr?
[15:56:54] <wondiws> http://pastie.org/9332244
[15:56:57] <wondiws> why does this not work?
[15:57:04] <Jartza> Tom_itx: not so :)
[15:57:08] <wondiws> if you define NOTWORK that is ;)
[15:57:21] <Thrashbarg> thekindlyone: strange. My first impression is it's executing multiple if statements until one wins out
[15:57:23] <wondiws> otherwise it does work
[15:57:51] <Tom_itx> Jartza what toolchain do you use?
[15:59:02] <Tom_itx> well crap... i gotta run
[15:59:31] <wondiws> nevermind I got it :p
[15:59:35] <thekindlyone> my clock source is the internal 1Mhz
[15:59:44] <Tom_itx> not that accurate
[15:59:52] <Tom_itx> unless maybe if you calibrate it
[16:00:37] <thekindlyone> yes but the turning off part is absolutely clockwork. after the delayed relay ON, exactly 3 minutes later the relay goes off.. and that is the bit the timer thing does.
[16:01:03] <Tom_itx> hmm
[16:01:34] <thekindlyone> the delays only happen when for a long time the pir hasn't set high
[16:01:44] <Tom_itx> did you include #define F_CPU?
[16:01:46] <thekindlyone> long 30-40 second delays.
[16:01:49] <Tom_itx> if that might matter...
[16:01:50] <thekindlyone> No.
[16:01:53] <Tom_itx> you need to
[16:02:00] <thekindlyone> like how?
[16:02:21] <Thrashbarg> thekindlyone: put #define F_CPU 1000000 at the start of the code
[16:02:31] <Tom_itx> #define F_CPU 1000000
[16:02:37] <thekindlyone> and remove mention of F_CPU from makefile?
[16:02:48] <Tom_itx> try it yes
[16:03:01] <Tom_itx> just don't have it in 2 places
[16:03:24] <Tom_itx> gotta run...
[16:04:00] <thekindlyone> mm okay
[16:04:14] <thekindlyone> I am going to try this, but the results take few hours.
[16:04:30] <thekindlyone> no ways to tell if it worked before that,
[16:04:54] <thekindlyone> thanks Tom_itx
[16:05:19] <thekindlyone> Thrashbag: could you tell me what difference the #define F_CPU will make?
[16:05:24] <Thrashbarg> thekindlyone: I'm worried about the structure of your if statements. E.g. if(bit_is_set(PINB,1) && lightoff) which sets lightoff to false immediately followed by if(bit_is_set(PINB,1)&& !lightoff)
[16:05:51] <Jartza> Tom_itx: standard "google android sdk" with eclipse CDT
[16:07:09] <thekindlyone> yeah I want to restart the clock if sensor senses motion and light is still on
[16:07:39] <thekindlyone> basically I want the light to be on till 3 minutes of last detected motion
[16:07:55] <thekindlyone> I don't understand the problem, can you explain
[16:07:57] <thekindlyone> ?
[16:10:38] <Thrashbarg> thekindlyone: it's difficult to explain but I think what you should do is separate the loop into two parts, the top part reads all inputs to variables and the bottom half executes one or no if statements when the conditions are right
[16:12:20] <thekindlyone> ah, so that it is guaranteed that every iteration, we are working with the same states of pins?
[16:12:26] <Thrashbarg> yea
[16:12:29] <thekindlyone> I see
[16:12:37] <thekindlyone> this is very promising
[16:12:44] <Thrashbarg> also use "else if" to make it execute only one if statement
[16:13:00] <Thrashbarg> when it finds the first if statement that matches it doesn't execute anything other if statement
[16:13:54] <Thrashbarg> nested if statements can cause problems here too, so that if(ReadADC(1)<700) statement should be put into the if statement that it's in
[16:14:45] <Thrashbarg> i.e. if(bit_is_set(PINB,1) && lightoff && ReadADC(1)<700)
[16:14:56] <thekindlyone> that is what I had done
[16:15:00] <Thrashbarg> ok
[16:15:11] <thekindlyone> then someone told me it is slowing down because the compiler is reading the adc everytime
[16:15:19] <thekindlyone> even if the first 2 conditions were false
[16:15:42] <Thrashbarg> is it slowing down progressively, or does it work then just not work
[16:15:53] <thekindlyone> no it is slowing down
[16:15:59] <thekindlyone> it always works
[16:16:07] <thekindlyone> but after a long time of pir inactivity
[16:16:21] <thekindlyone> reaction takes 30-40 seconds
[16:16:32] <Thrashbarg> I'll rephrase, does it get slower and slower or does it go from a working speed to a really slow speed suddenly
[16:16:41] <thekindlyone> I don't know
[16:16:52] <Thrashbarg> long time bases can be hard to measure
[16:17:25] <thekindlyone> I need this contraption running 24*7
[16:17:32] <Thrashbarg> yeah I see
[16:18:22] <Thrashbarg> myself I'd go with a discrete option using a comparator and a resettable one-shot :P
[16:18:32] <Thrashbarg> but meh that doesn't help
[16:18:37] <thekindlyone> how do I get the boolean value of bit_is_set to a variable
[16:18:40] <thekindlyone> what kind of variable?
[16:18:44] <thekindlyone> does this have a bool?
[16:18:52] <Thrashbarg> C doesn't, C++ does
[16:19:39] <Thrashbarg> in C you just store a number to a variable, if it's equal to 0 it's false, anything else is true. However I can't guarantee that because it might change from compiler to compiler
[16:20:10] <thekindlyone> so char?
[16:20:13] <thekindlyone> int?
[16:20:16] <thekindlyone> what?
[16:20:24] <thekindlyone> int
[16:20:26] <Thrashbarg> char will save you a byte
[16:20:42] <Thrashbarg> :P
[16:21:07] <thekindlyone> char pinstate= is_bit_set(pinB,1);
[16:21:08] <thekindlyone> ?
[16:21:27] <Thrashbarg> yup that'll do it
[16:21:41] <Thrashbarg> PINB needs to be capitals too. C is case sensitive
[16:21:48] <thekindlyone> I have suddenly lost all confidence after the volatile reveal
[16:21:59] <thekindlyone> now I can;t trust any of my intuitions
[16:23:42] <Thrashbarg> speaking of volatile, you could probably move that global 'seconds' variable to main() and just reset it in the if statements after stopwatch() is called, rather than putting it in stopwatch() and potentially causing problems
[16:23:42] <thekindlyone> can the slowing down be because I am not using interrupts ?
[16:24:41] <Thrashbarg> I'm thinking not. My guess is something's exceeding a value you're expecting it to be in, so when it's over that value it loops around back to 0, then works
[16:26:03] <thekindlyone> I ran this device with out the ADC bit for a few weeks
[16:26:11] <thekindlyone> it did slow down a bit sometimes
[16:26:17] <thekindlyone> but hardly noticable
[16:26:22] <thekindlyone> nothing this dramatic
[16:26:57] <thekindlyone> after the LDR was introduced the delays deteriorated
[16:27:22] <Thrashbarg> if you're testing it I'd recommend setting the timeouts to something short, like 5 seconds, to make it easier
[16:28:20] <theBear> ldr aren't known for speee
[16:28:21] <theBear> speed
[16:28:37] <thekindlyone> but it will have some resistance right?
[16:28:43] <thekindlyone> all the adc is doing is reading voltage
[16:28:54] <Thrashbarg> yea that's fine, it just needs to be calibrated
[16:28:56] <thekindlyone> even if the LDR takes 5 minutes to react to light changes
[16:29:20] <Thrashbarg> it won't take *that* long on the LDR's side. It'd be the software playing up
[16:29:32] <thekindlyone> the microcontroller should just get the previous voltage
[16:29:34] <thekindlyone> yeah
[16:30:32] <thekindlyone> how long can reading ADC take?
[16:30:45] <Thrashbarg> milliseconds
[16:31:04] <thekindlyone> so this is not because of not using interrupts and polling things right?
[16:31:30] <Thrashbarg> I don't think it's as simple as that... I'd recommend restructuring the code
[16:32:23] <thekindlyone> http://pastie.org/9332309
[16:32:40] <thekindlyone> this has all your suggestions.. right?
[16:33:41] <Thrashbarg> put ReadADC into the same if statement too
[16:33:46] <Thrashbarg> with &&
[16:33:48] <thekindlyone> ah okay
[16:34:07] <Thrashbarg> the order they come in is important too
[16:34:27] <thekindlyone> yes
[16:34:42] <thekindlyone> I think the reading should be last.. right?
[16:34:49] <thekindlyone> reading adc
[16:35:17] <Thrashbarg> maybe you'll have to fiddle with it
[16:35:25] <Thrashbarg> also pinB should be PINB on line 57
[16:36:16] <Thrashbarg> generally speaking, stacking if statements which change the values of the conditions in other if statements is to be avoided
[16:36:43] <Thrashbarg> ideally I'd use a state machine in this situation but that introduces other programming complexities
[16:36:50] <thekindlyone> even if I do else if?
[16:39:08] <Thrashbarg> it'd probably be easier to use a pseudo state machine, thinking about it. If you set up while statements within the while(1) loop, it'll sit in the while statements until the condition is false, then move to the next while statement
[16:39:33] <thekindlyone> D:\embedded\pirldr/main.c:57: undefined reference to `is_bit_set'
[16:40:08] <thekindlyone> oh sorry
[16:40:10] <Thrashbarg> did you declare pirstate?
[16:40:11] <thekindlyone> it is bit is set
[16:40:16] <Thrashbarg> ah
[16:40:26] <Thrashbarg> yes you did never mind
[16:40:29] <thekindlyone> yoda error
[16:40:31] <Thrashbarg> heh
[16:41:03] <thekindlyone> okay I didn;t understand your nested while idea
[16:41:16] <Thrashbarg> let me see if I can make an example
[16:41:28] <thekindlyone> that would be very helpful
[16:41:32] <thekindlyone> thanks for taking the time
[16:49:10] <Thrashbarg> thekindlyone:
http://pastie.org/9332341 <-- something more like that. Don't run it verbatim, check it first
[16:49:37] <thekindlyone> okay
[16:49:38] <thekindlyone> the last code
[16:49:44] <thekindlyone> the one I sent
[16:49:56] <thekindlyone> with your suggestions
[16:49:58] <Thrashbarg> bah freenode...
[16:50:08] <Thrashbarg> yes
[16:50:29] <thekindlyone> I have only connected a led with PB0
[16:50:47] <thekindlyone> nothing connected in PB1 and ADC1
[16:51:00] <thekindlyone> and after 3 minutes the led goes on
[16:51:04] <thekindlyone> permanently
[16:51:11] <thekindlyone> this should not happen at all
[16:51:12] <Thrashbarg> that could be noise getting into the pin
[16:51:20] <Thrashbarg> because 'nothing' is connected
[16:51:27] <thekindlyone> ah
[16:51:34] <thekindlyone> how to get rid of that?
[16:51:42] <Thrashbarg> pullup resistors
[16:51:55] <Thrashbarg> or just wire the inputs to GND
[16:53:45] <Thrashbarg> on the code I pasted, between lines 15 and 16 should be the statement seconds = 0;
[16:56:30] <thekindlyone> your code doesn't call stopclock()
[16:56:41] <thekindlyone> stopwatch()
[16:56:49] <thekindlyone> the timer never gets started
[16:57:09] <Thrashbarg> ok so put it before the while(1) statement
[16:59:12] <thekindlyone> it started with the led on
[16:59:22] <thekindlyone> and I have grounded the pir input pin
[16:59:36] <Thrashbarg> this is with your modified code
[16:59:38] <Thrashbarg> ?
[16:59:47] <thekindlyone> this is with the stuff you sent me?
[17:00:27] <thekindlyone> my modified code , after grounding the input pin was not throwing false positives, but haven't tested anything else
[17:03:13] <thekindlyone> while(bit_is_set(PINB, 1) && (ReadADC(1)<700));
[17:03:19] <thekindlyone> what is this supposed to do?
[17:03:44] <Thrashbarg> wait until both PINB(1) is set and the ADC is less than 700
[17:04:34] <Thrashbarg> then it switches the light on
[17:04:46] <thekindlyone> I think that line is not working
[17:04:49] <Jartza> isn't that the opposite
[17:05:10] <Thrashbarg> yea
[17:05:21] <Jartza> it waits until PINB(1) is unset and ADC is more than 699 :)
[17:05:38] <Thrashbarg> yup
[17:05:49] <thekindlyone> so I can not both?
[17:06:10] <Jartza> but I haven't really followed the conversation
[17:06:17] <Thrashbarg> you can make it be either, not both
[17:06:42] <Thrashbarg> while(!(bit_is_set(PINB, 1) || (ReadADC(1)<700)));
[17:07:17] <thekindlyone> nope
[17:07:23] <thekindlyone> I think I have to not each expression
[17:07:28] <thekindlyone> and then or the 2
[17:07:31] <thekindlyone> demorgans law
[17:07:48] <Jartza> no idea what you're trying to do :)
[17:07:51] <Thrashbarg> heh
[17:08:14] <thekindlyone> well the cahnge you suggested had no effect
[17:08:15] <Thrashbarg> while(!(bit_is_set(PINB, 1) && (ReadADC(1)<700))); <-- waits until both PINB(1) and ADC<700
[17:08:21] <thekindlyone> so alternate theories I was thinking of
[17:11:25] <Jartza> I was too busy with my modemstuff so I didn't follow what you're trying to do
[17:11:50] <Thrashbarg> I'm just procrastinating
[17:13:04] <Jartza> :)
[17:20:22] <thekindlyone> while(!(bit_is_set(PINB, 1) && (ReadADC(1)<700)))
[17:20:30] <thekindlyone> I missed the !
[17:20:56] <thekindlyone> that is what I was saying btw, !(a&&b)=!a||!B
[17:21:31] <Thrashbarg> yes
[17:22:19] <thekindlyone> didn't occur to me that I can just not the whole thing and C will take care of the rest
[17:22:22] <thekindlyone> :P
[17:22:35] <Thrashbarg> heh
[17:22:39] <thekindlyone> okay so atleast the led isn;t turning on
[17:23:02] <Thrashbarg> did you want it to be when *both* the conditions are true, or just one
[17:23:13] <thekindlyone> both
[17:23:22] <thekindlyone> the ADC reads ambient light
[17:23:27] <Thrashbarg> ok
[17:23:37] <thekindlyone> and the input pin is PIR
[17:23:56] <Thrashbarg> can you turn the LED on?
[17:24:30] <thekindlyone> the moment I removed PB1 from gnd, led went on
[17:24:34] <thekindlyone> now waiting for it to go off
[17:24:37] <thekindlyone> 3 minutes
[17:24:50] <Thrashbarg> if you set it to 10 seconds it might elp
[17:24:51] <Thrashbarg> help
[17:25:24] <Thrashbarg> thekindlyone: point is, do you see how the program works? There are two states, light on and light off. Certain conditions cause the states to change
[17:26:16] <thekindlyone> yeah trying to understand your code now
[17:26:23] <thekindlyone> it looks like it is working
[17:26:36] <Thrashbarg> huzzah I'm useful
[17:27:29] <thekindlyone> okay I get it.
[17:27:37] <thekindlyone> pretty cool and clean
[17:28:50] <z0idb3rg> hey
[17:29:08] <thekindlyone> thrashbarg: you are more than useful
[17:29:15] <z0idb3rg> does anyone have some experiences with thermal printers?
[17:29:42] <Thrashbarg> thekindlyone: don't mind me, I've got self esteem problems heh
[17:29:59] <thekindlyone> :D
[17:30:07] <thekindlyone> now lets see if it still slows down
[17:30:12] <thekindlyone> after a few hrs
[17:30:15] <Thrashbarg> working?
[17:30:16] <Thrashbarg> ok cool
[17:30:17] <thekindlyone> just installed it
[18:50:05] <Ox4C4A> Hello!
[18:51:10] <Ox4C4A> What does an ATtiny do with the CPU registers, when it enters an ISR?
[18:51:54] <Ox4C4A> If I write the code in assembly, specifically. Does it clean them up or can I use, say, R31, as a sort of global variable holder throughout the program?
[18:52:32] <Ox4C4A> I tried searching for it, but couldn't come up with any proper resources detailing the behaviour. :/
[18:54:08] <Lambda_Aurigae> Ox4C4A, did you look in the datasheet?
[18:54:45] <Ox4C4A> Yeah, but it doesn't specifically say anything about it.
[18:55:04] <Ox4C4A> Am I to assume since it doesn't mention it - it doesn't do anything with it?
[18:55:17] <Ox4C4A> As in - the registers remain untouched?
[18:55:35] <Lambda_Aurigae> let me look.
[18:55:48] <Ox4C4A> ATtiny9 to be specific.
[18:59:51] <Lambda_Aurigae> I would say it does nothing with them.
[19:00:22] <Ox4C4A> I guessed so too, but got some weird effects. I guess it was due to other stuff in the code.
[19:00:29] <Ox4C4A> Thanks a bunch for your time though.
[19:00:40] <Lambda_Aurigae> now, if you are using gcc then you get all kinds of setup and teardown stuff.
[19:00:53] <Ox4C4A> I'm coding assembler
[19:01:35] <Ox4C4A> Yeah, I guess I should've checked the disassembly after launching the code on the simulator
[19:01:48] <Ox4C4A> Didn't think of that
[19:02:12] <Ox4C4A> I just started and am unsure what the compiler adds on it's own
[19:02:35] <Lambda_Aurigae> gcc compiler adds lots of stuff.
[19:02:43] <Lambda_Aurigae> the assembler shouldn't add much at all if anything.
[19:03:10] <Ox4C4A> Yeah, I shrunk my ~700 byte code to ~90 bytes by rewriting it in assembler. Feels real good. :)
[19:03:20] <Lambda_Aurigae> it happens.
[19:03:45] <Lambda_Aurigae> on the commodore computers years ago it was nice to write in assembly...
[19:04:32] <Ox4C4A> Okay, thank you for the assistance, I'm going to continue attempting to trick out my percussion synthesizer.
[19:06:22] <Lambda_Aurigae> http://www.avr-tutorials.com/interrupts/about-avr-8-bit-microcontrollers-interrupts
[19:24:48] <thekindlyone> Thrashbarg: do you see an obvious problem with this:
http://pastie.org/9332809
[19:24:49] <thekindlyone> ?
[19:25:19] <thekindlyone> CTC interrupt instead of polling the timer I tried
[19:25:33] <thekindlyone> but instead of 1 minute like I said it is waiting exactly 2 minutes
[19:25:40] <thekindlyone> before turning off the pin
[20:37:23] <Duality> hmm so a avr without sram, won't support stack and thus can only do limited things ?
[20:40:06] <Lambda_Aurigae> it will have a very small stack.
[20:40:25] <Lambda_Aurigae> but, yes, it will be very limited.
[20:45:55] <Duality> Lambda_Aurigae: what do you meen verry small stack ?
[20:51:45] <Lambda_Aurigae> what chip are you referring to?
[20:52:06] <Lambda_Aurigae> so I can grab the datasheet.
[20:54:18] <Lambda_Aurigae> I don't see any tiny avr chips without any ram.
[20:54:23] <Lambda_Aurigae> the lowest being 32 bytes.
[21:01:09] <Duality> Lambda_Aurigae: i am sure i saw one without ram
[21:01:38] <Lambda_Aurigae> I just went through the list and didn't see any without sram.
[21:02:16] <Duality> hmm maybe my mistake :)
[21:02:30] <Duality> but a microcontroller without any ram would still function right ?
[21:03:35] <Lambda_Aurigae> would be kinda useless far as I'm concerned.
[21:03:49] <Lambda_Aurigae> no place to put variables.
[21:04:13] <Duality> well you have 32 registers ..
[21:04:27] <Lambda_Aurigae> which is probably the 32 bytes of ram on the attiny4.
[21:05:26] <Duality> nah
[21:05:35] <Duality> attiny4 has only 16 registers
[21:05:42] <Lambda_Aurigae> I'm looking...have never played with the little attiny chips.
[21:06:09] <Lambda_Aurigae> yeah....first 64 bytes are i/o memory, followed by 32 data memory locations.
[21:07:05] <Lambda_Aurigae> plus 16 registers.
[21:08:36] <Lambda_Aurigae> and it has a stack pointer so there is a functional stack that works in the 32 bytes of sram.
[21:11:42] <Duality> but sya
[21:11:45] <Duality> say*
[21:12:06] <Duality> take a atmega328p and remove sram. would you still be able to do stuff with it :)
[21:24:27] <FreezingCold> can I use avrdude to flash ROM chips other than Atmel?
[21:24:35] <FreezingCold> just regular ISP chips
[21:24:44] <FreezingCold> got a 'USBASP v2.0'
[21:27:43] <jacekowski> FreezingCold: nope
[21:27:59] <FreezingCold> jacekowski: question, my USBASP v2.0 doesn't seem to be getting picked up by dmesg
[21:28:03] <FreezingCold> [246696.985599] usb 4-1.1: new low-speed USB device number 6 using ehci-pci
[21:28:11] <FreezingCold> Bus 004 Device 006: ID 16c0:05dc Van Ooijen Technische Informatica shared ID for use with libusb
[21:28:12] <FreezingCold> that's it
[21:28:19] <jacekowski> good enough
[21:28:45] <jacekowski> it just means that there is no driver claiming the device
[21:29:06] <jacekowski> but userland libusb will work
[21:29:20] <FreezingCold> ah, what driver do I need to flash ISP chips?
