#avr Logs
Mar 13 2017
#avr Calendar
12:48 AM daey_ is now known as daey
05:24 AM JanC is now known as Guest42627
05:24 AM JanC_ is now known as JanC
06:14 AM julius: hi
06:15 AM julius: does someone want to see some beautiful code? well your out of luck with me...but maybe somebody could take a look if the adc conversion code is correct? i get numbers between 387 and 390 via the bluetooth module: https://bpaste.net/show/5ed1953a02f9
06:15 AM julius: the bluetooth sending works
06:16 AM polprog: julius: the codes ok
06:16 AM julius: but the motion sensor should put out a "low" signal if it is detecting motion
06:17 AM julius: for experimentation i used the adc....that should output different values if the motion detector is detecting right?
06:17 AM polprog: check it with a meter/scope
06:18 AM julius: ah good idea
06:18 AM polprog: also in the datasheet for the sensor there should be the low and hi values and connection schematic
06:18 AM julius: just disconnected the md and it gives me the same values
06:18 AM polprog: oh
06:19 AM polprog: interrsting
06:19 AM polprog: imho the sensor should output a logic signal
06:21 AM julius: yes
06:21 AM julius: 3.31v when motion is there for a second and 0v when there is none
06:21 AM julius: not the other way around as i thoguht
06:22 AM julius: http://www.meccanismocomplesso.org/en/pir-motion-detector/ thats the one, different source though
06:22 AM polprog: connect it to a digital.input of thr avr. try adding a pulldown resistor
06:23 AM polprog: afk
06:40 AM Emil: you are talking about thr basic pir sensor?i
06:41 AM Emil: its only logic levels
06:41 AM Emil: no adc needed
06:41 AM Emil: it low passes internally
06:53 AM polprog: yeah
07:10 AM julius: ah yes...the arduino pictures were a little bit fucked up
07:10 AM julius: got the wrong input pin....now its working
07:54 AM julius: any idea why the led with this code only flashes very shortly instead of staying on for 3 seconds or off? https://bpaste.net/show/f07db0ea6e1a
07:56 AM cehteh: how is output defined?
07:56 AM cehteh: and better use a timer than delay
07:58 AM julius: one sec
08:03 AM cehteh: itoa is signed btw .. when you done what i suggested yesterday your adc value should be unsigned, that would run into trouble as well when converting
08:03 AM cehteh: reduce the resulution to 15bit would fix that
08:04 AM specing: or sprintf
08:05 AM cehteh: but julius fallen asleep :D
08:05 AM specing: or ptr = &string; while i > 0
08:05 AM specing: *ptr = '0' + i % 10
08:06 AM specing: i = i/10
08:06 AM specing: ++ptr
08:06 AM specing: }
08:06 AM specing: then reverse the string
08:06 AM specing: or use Ada and just do
08:06 AM cehteh: just build it forward :D
08:07 AM specing: mytype'Image (variable)
08:07 AM cehteh: no one but you uses ada :D
08:09 AM specing: false, tkoskine uses Ada.
08:09 AM specing: and everyone else that matters :D
08:11 AM julius: toilet...
08:12 AM julius: actually the output that is send out via bluetooth is ~650
08:13 AM cehteh: but how is output defined=
08:13 AM Emil: specing: pls stop with ada :D
08:13 AM julius: char output[3]
08:13 AM cehteh: char output[6];
08:13 AM julius: ive guess the 3
08:13 AM julius: guessed
08:13 AM cehteh: thats the problem
08:14 AM julius: so the adc returns 0...1023 as value, right?
08:15 AM Emil: julius: why are you doing things hard?
08:15 AM cehteh: make it 7 .. why: because a 16 bit integer can be -32767 .. thats 5 chars plus a trailing \0 and the minus sign
08:15 AM Emil: wtf
08:15 AM cehteh: then you covered all bases
08:16 AM cehteh: when you are absolutely certain that only 0-1024 is needed then array size of 5 would suffice
08:16 AM Emil: If you output data to a computer minimise computation on uc side. Send nibbles encoded to A-P if you must be quick and all, also have start stop dymbol
08:16 AM cehteh: but for just 2 bytes more you fix the problem completely without worries
08:17 AM specing: Emil: no
08:17 AM Emil: cehteh: 0-1023
08:17 AM cehteh: eh yes
08:17 AM Emil: ;)
08:17 AM Emil: specing: pls ;.;
08:17 AM cehteh: well 5 chars would work for -999 to 9999 :)
08:17 AM cehteh: decimal
08:17 AM Emil: pls
08:17 AM specing: Emil: it is 2017 and your are still dealing with internal representation ...
08:17 AM julius: and with my 3 itoa would put the first part of the conversion in them and then forget the rest?
08:18 AM Emil: julius: send - only if necessary
08:18 AM cehteh: julius: your problem is a buffer overflow and your program constantly crashes and restarts, thats why it never hits the _delay
08:18 AM Emil: dont unnecwssary store it in ram
08:18 AM julius: ah
08:18 AM julius: ok
08:18 AM Emil: specing: >muh datatypes >b-b-buts datatypes!
08:19 AM Emil: specing: ULOS
08:19 AM Emil: :D
08:19 AM cehteh: when you want to truncate the integer to ascii result then you need sprintf with some fancy formatting specs
08:19 AM specing: Emil: ?!
08:19 AM specing: Just tell Ada how to represent it and be done with it
08:20 AM Emil: pls no
08:20 AM specing: subtype adc_value is Integer range 0 ... 1023;
08:20 AM Emil: julius: you want to send data out of serial?
08:21 AM Emil: And want to send thr ascii representation?
08:21 AM Emil: Or do you just need to log the data computer side?
08:22 AM julius: ive seen python...anything else is just garbage
08:22 AM Emil: Mate answer me :D
08:24 AM cehteh: look at lua, its better than python :D
08:24 AM julius: now i only get a reading via bluetooth every 3 seconds which i would expect...but the led only flashes shortly. i was expecting it to stay on for 3 seconds or go off for 3
08:24 AM specing: cehteh: indeed
08:25 AM specing: I do casual gamedev in lua, its really nice
08:25 AM julius: its like both if and else would be executed
08:25 AM julius: led on and right off again
08:25 AM cehteh: julius: thats a problem somewhere else in your code, what does readADC() do etc?
08:26 AM cehteh: and did you set F_CPU correctly .. and again . dont use the fucking delay functions :D
08:26 AM cehteh: timers ftw
08:26 AM julius: i know that delay is a dirty trick
08:27 AM specing: you can use delay and threading in Ada along with the Ravenscar runtime
08:27 AM julius: F_CPU is set to 16mhz, bluetooth wouldnt work of the frequency would be off
08:27 AM specing: its easy
08:27 AM specing: :)
08:27 AM cehteh: specing: stopp trolling at least
08:27 AM julius: let me paste the code
08:27 AM cehteh: i mean in contrast to emil imo its ok here to talk about ada *if approbiate* .. but that wont help julius no in any way
08:28 AM cehteh: if you find someone who wants to talk with you about ada .. go on
08:28 AM cehteh: otherwise keep shut
08:28 AM cehteh: (yes thats mean :D)
08:28 AM julius: https://bpaste.net/show/05063d466516
08:29 AM cehteh: your code sux :D
08:29 AM cehteh: while(!(ADCSRA & (1<<ADIF)));
08:29 AM julius: its no problem...if somebody comes around with bash and tried to tell me that is powerfull i would also barry him with python things
08:29 AM Thrashbarg: cehteh: bah I've done worse haha
08:29 AM cehteh: yes me too
08:29 AM cehteh: but still
08:30 AM julius: whats not good about that?
08:30 AM Thrashbarg: I have a habit of making a hash of bitwise operations...
08:31 AM cehteh: julius: delay might be interrupted by the isrs and isrs *must* not delay for extended time else other interrupts may not be handled or even get lost
08:31 AM julius: im not connected via bluetooth at the moment, wouldn that keep the ISR from firing?
08:32 AM cehteh: should .. but still a bug
08:32 AM julius: ok i see
08:32 AM cehteh: comment the flash_leds () thing out
08:32 AM cehteh: and again: did you set F_CPU on your compilation?
08:32 AM cehteh: else delay wont work
08:33 AM julius: F_OSC = 16000000 F_CPU = $(F_OSC) CFLAGS = -mmcu=$(DEVICE) -DF_CPU=$(F_CPU)
08:33 AM julius: delay works, when connected via bluetooth i only get a value ~3s
08:33 AM cehteh: ok then everything should be ok on a first sight
08:34 AM cehteh: maybe comment the whole bluetooth/uart stuff out completely and check if it works then
08:34 AM cehteh: debug it work forward until you find the cause
08:34 AM julius: yeah
08:34 AM cehteh: i have to go be back later
08:34 AM cehteh: and .. learn about timers :D
08:35 AM cehteh: in my mµOS one can scheldule functions to be called at some time intervals btw :D without delays
08:35 AM cehteh: eventually i should continue working on it
08:35 AM cehteh: bbl
08:41 AM julius: as soon as: USART_Init(MYUBRR); is enabled in the code it just keeps the led on all the time and it goes off very shortly inbetween
08:41 AM julius: but USART_Init does nothing to the LED Port
08:42 AM julius: cehteh, have fun
09:59 AM Emil: hmm
10:00 AM Emil: I should write a small scheduler and syscalls
10:00 AM Emil: well, "syscalls"
11:24 AM cehteh: re
11:25 AM polprog: reee
11:25 AM cehteh: Emil: some details on a scheduler can become surprisingly complex for some cases :D
11:25 AM cehteh: at least when you want to do it 'correct'
11:26 AM cehteh: .. and save memory
12:56 PM homa_: hi Casper
01:10 PM Casper: o/
01:11 PM homa_: can i find driver for usbasp for ubuntu
01:15 PM Casper: there is no driver needed
01:15 PM Casper: avrdude talk to the device directly
01:15 PM Casper: (which is also why there is often permission issue)
01:17 PM homa_: Casper: maybe avrdude can't work with fake programmer
01:17 PM Casper: that is a possibility
01:17 PM Casper: ask your seller about it
01:18 PM homa_: all usbasp programmer have same pid and vid
01:18 PM Casper: what is your already?
01:19 PM homa_: 16c0:05e1
01:20 PM homa_: is it fake programmer ?
01:21 PM Casper: I am on something
01:22 PM Casper: lsmod do you see cdc_acm loaded?
01:23 PM homa_: yes
01:23 PM Casper: :D
01:23 PM Casper: :DD
01:24 PM Casper: that's the issue
01:24 PM Casper: due to the wrong PID a module get loaded
01:25 PM homa_: ok , what is it ? and how can i solve that ?
01:25 PM Casper: I never had to do it, so I am not sure
01:25 PM Casper: try to rmmod cdc_acm and see if avrdude work
01:27 PM homa_: avrdude: error: programm enable: target doesn't answer. 0
01:27 PM homa_: avrdude: initialization failed, rc=-1
01:27 PM homa_: Double check connections and try again, or use -F to override
01:27 PM homa_: this check
01:29 PM Casper: that actually may be your avr
01:29 PM Casper: check the connections and make sure the avr is powered
01:31 PM homa_: Casper: i use atmega16a and connect from 5-11 pins and 11 pin is GND
01:32 PM Casper: that tell me nothing
01:32 PM homa_: Casper: what command i should use
01:32 PM Casper: be sure that the programmer miso -> miso mosi->mosi sck->sck reset->reset and gnd->gnd and that the avr receive power from your power source and is a good stable 5V
01:33 PM Casper: not sure on the command, I'm not on my flashing computer, which don't have the stuff installed due to some conflicts I had... need to reinstall stuff...
01:38 PM homa_: Casper: programmer work on windows fine
01:39 PM Casper: with avrdude?
01:39 PM homa_: no
01:40 PM homa_: codevision
01:41 PM Casper: but anyway, one thing you may want to try: disconnect the programmer, reboot, lsmod > preconnection.txt, dmesg -c, connect, analyse dmesg and compare lsmod with the preconnection.txt no driver shall get loaded for it
03:21 PM homa_: bye my friends
03:21 PM Arlenx: hi, i have some little infrared decoder program,NEC protocol that's finally looks like it works(sometimes it doesn't :) ) but i have some problem collecting the data. here is the program: http://pastebin.com/mff0Esdp line 161 and 167 works good but the variable 'data' is not.i'm sure i'm doing something stupid with the bit shift.
03:36 PM Arlenx: is there a way to debug avr chip? for example i want the program to stop at a breakpoint is it possible?
03:38 PM LoRez: Arlenx: if you have a jtag interface and have the pins available, probably.
03:38 PM Casper: hey LoRez !
03:39 PM LoRez: Hey!
03:39 PM Casper: there is a bot that try to identify to my alternate nick several time a day, is there a way to figure out where that bot is so I can try to find the owner so I can get him to fix it?
03:39 PM Arlenx: LoRez, it can also catch infrared signal and stop at some breakpoint line?
03:40 PM LoRez: Arlenx: I've not actually ever jtagged a running AVR. I'm not sure what you could get it to do. I'm usually debugging applications on PCs while they're running.
03:41 PM LoRez: You might be better off compiling in some extra output methodology so you can "print" information you want when you get a signal
03:41 PM Casper: the way I debug it is with the serial port
03:41 PM LoRez: ^^^^^
03:41 PM Arlenx: i'm also using serial port but it's not help all the time
03:41 PM LoRez: Casper: I've got things doing that to me too.
03:42 PM Casper: vodaphone?
03:42 PM Arlenx: sometimes printint to serial port ruin the timing with infrared
03:42 PM Arlenx: so i can't see exectly what's happen
03:42 PM LoRez: Casper: random things. same people sometimes.
03:42 PM Casper: debugging WILL screw your timing anyway
03:42 PM LoRez: Arlenx: are you using interrupts?
03:43 PM Arlenx: yep
03:43 PM LoRez: yeah, you won't have any reasonable timing when debugging
03:43 PM Arlenx: life is very hard without debugger:(
03:44 PM LoRez: Now I'm curious. I would have to unpack a bunch of stuff to see exactly how that behaves.
03:47 PM Casper: LoRez: so no way to figure out where that bot sit isn't it?
03:47 PM Casper: unless I bribe an unbribable oper?
03:49 PM LoRez: an operator might be nice enough to correlate the IP with an existing user, but ymmv there.
03:58 PM Casper: do you know of one that is that nice?
04:02 PM arij is now known as arij_work
04:18 PM LoRez: If they're still on staff, they're nice.
04:27 PM specing: what did you do LoRez to get un-staffed?
04:31 PM LoRez: Decided to not be staff.
04:39 PM specing: <trump>Sad!</trump>
04:45 PM NoHitWonder: Arlenx you need ATMEL-ICE for debugging
04:45 PM NoHitWonder: then you can run your code step by step and set breakpoints
04:46 PM NoHitWonder: but atmel tools are expensive
04:47 PM NoHitWonder: stm32 dev boards always have debugger built in
04:48 PM Arlenx: NoHitWonder, thanks!
04:48 PM Emil: Just fyi
04:49 PM Emil: interrupt driven serial is always more efficient than blocking
04:49 PM Emil: even at 1Mbaud
04:51 PM specing: if you write your ISR in asm...yup
04:51 PM specing: otherwise no, as gcc will waste 20 cycles setting it up
04:52 PM NoHitWonder: its seems ATMEL-ICE prices has gone up
04:52 PM NoHitWonder: its now 131 euros at mosuer
04:52 PM specing: It is always a good time to migrate to stm32
04:52 PM Emil: specing: even then it is more efficient
04:52 PM NoHitWonder: *mouser
04:52 PM specing: NoHitWonder: stm32 is $10 with debugger included
04:52 PM Emil: specing: but you do ada so you wouldnt know ;)
04:52 PM specing: OpenOCD (gdb) supported
04:52 PM NoHitWonder: yeah
04:52 PM Emil: specing: the overhead is 40 cycles
04:53 PM Emil: ish
04:53 PM Arlenx: i wonder if this stm32 on bangood will do the job: http://www.banggood.com/STM32-Board-Nucleo-NUCLEO-F411RE-STM32F411RE-STM32-Development-Board-Support-Arduino-p-1124758.html?rmmds=buy
04:53 PM Emil: Arlenx: just buy a real nucleo
04:53 PM Emil: they cost 10 dollars
04:54 PM NoHitWonder: i have that Arlenx
04:54 PM Arlenx: it's working?
04:54 PM Emil: specing: so please don't make claims when you dont know ;)
04:55 PM NoHitWonder: Arlenx yes
04:55 PM Arlenx: great
04:55 PM specing: Emil: what claims
04:55 PM specing: it was 20 cycles last I checked, which was 5+ years ago
04:56 PM Emil: total 40
04:56 PM Emil: in out
04:56 PM NoHitWonder: but do you wanna switch to ARMs Arlenx ?
04:56 PM specing: and I had a brainfart and though that 1mbaud is in megabytes for some reason, in reality it is 128 cycles in between
04:56 PM Emil: specing: and even at 40 cycles it is still more efficient than blocking
04:56 PM specing: yes
04:57 PM Emil: specing: 160*
04:57 PM Arlenx: NoHitWonder, currently i'm on avr atmega328p and attiny... and i really really need debug tool
04:57 PM NoHitWonder: oh my, ATMEL-ICE price have doubled
04:57 PM NoHitWonder: then buy ATMEL-ICE and stay with AVRs
04:58 PM Emil: Arlenx: eh
04:58 PM Emil: Arlenx: serial out
04:58 PM Emil: or spi out
04:58 PM Emil: or leds
04:58 PM Arlenx: :( yep
04:59 PM Emil: Show us the code
04:59 PM specing: Emil: 144, no parity ;p
04:59 PM specing: wait, is there a stop bit?
04:59 PM julius: hi
04:59 PM Emil: specing: yes :D
04:59 PM specing: damn
04:59 PM Emil: lol
04:59 PM specing: don't blame me, I haven't done embedded dev in over 5 years
04:59 PM Emil: you dun goofed mate :D
05:00 PM Emil: ...
05:00 PM Emil: MATE
05:00 PM julius: is it possible that the USART_RX_VECT (atmega328p) does fire even though there is no bluetooth client connnected to the module that is connected to that pin?
05:00 PM Emil: >Use ada gyes its great
05:00 PM specing: DUDE
05:00 PM specing: yes it is
05:00 PM specing: problem is that getting a working toolchain for Ada is a nightmare :(
05:00 PM Emil: >havent done embedded in 5 years
05:00 PM specing: I use Ada on GNU/Linux
05:01 PM Emil: Maybe the speed on your linux box has blinded you ;)
05:01 PM Emil: I have no trouble mallocin 1k blocks 0 initialised on a normal machine but on an avr? ":D"
05:02 PM julius: Arlenx, you could check aliexpress if theres a ice clone
05:02 PM Emil: julius: shor code
05:02 PM Arlenx: julius, yep
05:02 PM Emil: show*
05:02 PM specing: Emil: its too fast for me, that is for sure
05:02 PM Emil: heh
05:03 PM specing: I need a cyborg upgrade
05:03 PM Emil: julius: it is USART_RX_vect
05:05 PM Emil: And the interrupt is only executed on valid data
05:21 PM Arlenx: here is my suck NEC decode code: http://pastebin.com/mff0Esdp line 161 and 167 works good but the variable 'data' does not show the correct number.maybe i'm doing something wrong with bit shift.someone might see the problem,help please.
05:43 PM Arlenx: cya guys and thanks
06:01 PM polprog: i was trying to use my scope to exeperimentally measure the speed of light
06:01 PM polprog: it failed
06:12 PM julius: polprog, :)
06:13 PM julius: is it possible that the USART_RX_VECT (atmega328p) does fire even though there is no bluetooth client connnected to the module that is connected to the rx pin?
06:13 PM polprog: if usart pin is floating all things can happen
06:14 PM polprog: i dont remember if its pulled inside any way
06:14 PM julius: so i should put a 1mohm pin from uart rx -> gnd?
06:14 PM julius: resistor i mean
06:14 PM polprog: 1mohm is a bit much, i use 10k
06:15 PM julius: but it would reduce the current, would it not?
06:15 PM polprog: in theory theres a whole methodology on selecting the proper resistors there. 10k is safe
06:15 PM julius: ok
06:16 PM julius: gonna try that tomorrow
06:16 PM polprog: too small will overload, too big wont work
06:16 PM julius: out of curiosity, what would go wrong im the resistor is to big?
06:17 PM julius: ah crap...my sentences really need some sleep
06:19 PM polprog: it could be unable to suspress tiny currents inducing on the signal line
06:19 PM Lambda_Aurigae: 1Mohm resistor will be too large to properly pull the line high at 5V...waaay too high at 3.3V
06:19 PM polprog: and theese currents would produce voktages giving false readings
06:19 PM Lambda_Aurigae: 10Kohm is usually safe for most things.
06:20 PM Lambda_Aurigae: I've used 22Kohm for some things if there's not a lot of other noise around the trace.
06:20 PM polprog: there was an application note on that, by ti
06:20 PM Lambda_Aurigae: 4.7Kohm is often considered a strong pullup/pulldown.
06:21 PM Lambda_Aurigae: there have been a couple dozen I'm sure.
06:21 PM Lambda_Aurigae: by various manufacturers.
06:21 PM Lambda_Aurigae: it's a tradeoff in the noise immunity vs current draw fight.
06:21 PM polprog: they calculated the proper value taking bus capacitance, freq, voktahes and a couple of other things
06:21 PM Lambda_Aurigae: yup.
06:22 PM Lambda_Aurigae: there's math for it.
06:22 PM Lambda_Aurigae: if you look at the pullups built into the avr, I do believe they are 10K.
11:59 PM scrote: hi