#avr Logs

Jun 01 2017

12:27 AM day_ is now known as daey
03:23 AM julius: hi
03:39 AM Emil: Morninh
03:39 AM Emil: Anyone have the patches for atmega328pb?
03:39 AM Emil: LeoNerd: ?
04:50 AM Jartza: what patches?
05:16 AM Emil: Jartza: configs and definitions
05:17 AM Emil: so that avrdude, gcc-avr, avr-binutiks and libc-avr work like for any other avr
05:36 AM LeoNerd: Emil: I don't have *as such*, what I do have is some edited files
05:37 AM LeoNerd: For me I found that my avr-gcc + avr-libc already cope, it was only avrdude that needed help
06:26 AM Jartza: hmmh
06:26 AM Jartza: I have avr-gcc 6.2
06:27 AM Jartza: seems to support 328pb
06:57 AM noqnio1: hey. Is there a way to create default makefiles on linux?
06:57 AM noqnio1: why do they always seem to be such a hassle :o
07:14 AM cehteh: default is no makefile :D
07:15 AM cehteh: make has a lot buildin defaults
07:15 AM cehteh: (and i rather think thats a misfeature)
07:15 AM noqnio1: well i just copied&pasted a random one online and tweaked it a bit
07:16 AM noqnio1: now another question.... why does _delay_ms result in a 5x delay, e.g. i set 200ms and in reality it is 1 second
07:16 AM noqnio1: my f_cpu is correct
07:16 AM cehteh: it is F_CPU uppercase :D
07:16 AM noqnio1: and i checked the fuse bits, they are on default internal osc 9.6 mhz
07:16 AM noqnio1: it is yes, on the makefile
07:16 AM cehteh: what chip?
07:16 AM noqnio1: tiny13a
07:17 AM cehteh: iirc default is 1mhz
07:17 AM noqnio1: 5. The default setting of CKSEL[1:0] results in internal RC Oscillator @ 9.6 MHz. See Table 18-3
07:17 AM noqnio1: on page 119 for details.
07:18 AM cehteh: ah tiny13 has 4.8/9.6 yes
07:18 AM cehteh: but default is the CLKDIV/8 fuse which sets the main prescaler to /8
07:19 AM noqnio1: aaaahhhh i do that every time -.-
07:19 AM noqnio1: thanks mate
07:19 AM cehteh: you can either unfuse that or better set the prescaler in main
07:19 AM noqnio1: every single time i try to program an avr i forget about the divider
07:19 AM cehteh: on another note: delay is evil :D
07:19 AM noqnio1: you're damn right it is!!
07:20 AM noqnio1: do makefiles support 9600000 / 8 ?
07:20 AM noqnio1: one way to find out.
07:20 AM noqnio1: -DF_CPU=9600000/8
07:20 AM noqnio1: :s
07:20 AM cehteh: lol
07:20 AM noqnio1: will that work or will my avr explode?
07:20 AM cehteh: i think you have to call a make function for that
07:21 AM noqnio1: i just entered the divided value manually
07:21 AM noqnio1: and proper delay timing!!!
07:21 AM noqnio1: thanks
07:21 AM cehteh: do you want it at 1mhz?
07:22 AM noqnio1: I don't care, it is a really simple program, plus i'll get less power consumption
07:22 AM cehteh: 1.2 rather
07:22 AM cehteh: battery powered?
07:22 AM noqnio1: yeah
07:22 AM noqnio1: i have my change to fiddle with sleep modes :D
07:23 AM cehteh: then dont use delay :D
07:23 AM cehteh: and you can run the main clock from the watchdog osc .. 128khz
07:23 AM noqnio1: I won't, this is the hello world blinking :D
07:23 AM cehteh: thats pretty low power, and slow
07:23 AM noqnio1: oh i will check that out, thanks
07:23 AM cehteh: i used that for some battery watchdog
07:24 AM cehteh: for development i used the normal clock, with prescaler diviing to 125khz (tiny45 here)
07:25 AM cehteh: and final product then is fused to the watchdog osc to use even less power
07:25 AM noqnio1: what kind of reduction are we talking about, when switching from the normal clock to the watchdog oscillator ?
07:26 AM cehteh: see datasheet, its quite a lot
07:26 AM cehteh: http://git.pipapo.org/?p=battswitch.git;a=blob;f=src/battswitch.c#l264
07:26 AM cehteh: btw
07:26 AM noqnio1: will do, thank you !
07:43 AM enhering: polprog: Argon lasers wear out. The capsule gets conductive due to electrode sputtering. They usually deliver very low or no power when old. But one of the argon laser lines, the cyan one, is very beautiful.
07:44 AM enhering: If you guys have time, my little project made another step forward: https://hackaday.io/project/11724-yauvc-yet-another-unmanned-vehicle-controller/log/60610-good-news
08:08 AM noqnio1: can i have the pullup enabled on a int0 pin?
08:12 AM Emil: cehteh: iirc the fuse prescaler is fixed
08:13 AM cehteh: /8
08:13 AM cehteh: but you can clear that fuse then it runs at /1
08:13 AM Emil: yeah
08:13 AM cehteh: i still prefer to set the prescaler in main, thats mor idiot proof
08:13 AM Emil: but iirx you cant change it runtime
08:14 AM Emil: so if you have the fuse
08:14 AM Emil: that's the maximum
08:14 AM cehteh: nop
08:15 AM cehteh: you can always change the prescaler at runtime (but need to consider the side effects, ADC clock etc)
08:16 AM cehteh: and the avr-libc isnt aware about F_CPU becoming dynamic, you get some ugly things when you mess with it
08:17 AM * cehteh would prefer a F_OSC instead, i prolly implement that for my timing functions on my own
08:22 AM noqnio1: do the interrupts nest or run in series?
08:22 AM noqnio1: can my ISR function be interrupted but an ISR function of the same interrupt ?\
08:23 AM cehteh: they 'can' nest with some efforts, usually ISR's block others, and you have the interrupt flag for each interrupt which gives you a buffer for one interrupt pending of any kind
08:24 AM cehteh: unless it is extremely timing critical you shouldnt nest interrupts
08:24 AM cehteh: takes stack space
08:24 AM noqnio1: so i can just check the int flag inside of my int routine to check if the pin went to GND again? (my int is falling edge)
08:24 AM cehteh: err .. on a tiny13 thats stack space from 64 bytes SRAM .. haha
08:25 AM cehteh: yes you can check and clear the interrupt flags from another isr
08:25 AM cehteh: beware of races and sometimes writing a 1 there clears the flag. read the datasheet
08:25 AM noqnio1: sweet i'll do that, thanks
08:25 AM cehteh: better make your ISR's as small as possible and do the heavy lifting outside
08:26 AM noqnio1: there will be no heavy lifting :D
08:26 AM cehteh: almost anytihing on a tiny13 is heavy lifting :D
08:26 AM noqnio1: hahah
08:26 AM cehteh: jk
08:26 AM Emil: cehteh: interestin
08:27 AM cehteh: anyway nesting ISR's and also recursive function calls pretty soon hit the limit on the tiny
08:27 AM cehteh: 12
08:27 AM Emil: cehteh: I was always under the impression that the divide by 8 cannot be circumvented
08:27 AM cehteh: 13
08:27 AM noqnio1: well my isr is like... 6 lines so i guess it will be ok
08:27 AM cehteh: Emil: its only there to make a fallback for sane programming
08:27 AM noqnio1: INTF0 is the correct flag, right?
08:27 AM Emil: cehteh: lol
08:28 AM Emil: cehteh: it is the first thing I disable :D
08:28 AM Emil: about interrupts
08:28 AM Emil: they have overhead
08:28 AM cehteh: noqnio1: check the generated asm .. gcc isnt very good with saving registers on isr's, often saving too much
08:28 AM Emil: so if you need quick processing
08:28 AM cehteh: that can eat plenty bytes
08:28 AM Emil: you might not want to wxit as quickly as possible
08:29 AM cehteh: also isr has 6cycles overhead on calling them itself, thats without register saving
08:29 AM Emil: it's 4 iirc?
08:29 AM cehteh: when you manage to do the isr with fixed registers/global vars you can shave a lot from it
08:30 AM noqnio1: maybe i should just add a timer and be done with it
08:30 AM cehteh: generating asm, then make the ISR naked and inline that asm with some hand optimizations is a good approach sometimes
08:31 AM cehteh: but sometimes not worth the efforts, just try and see,
08:31 AM cehteh: when your stuff works, it works
09:07 AM Jartza: I like asm
09:10 AM Jartza: for no particular reason except, I feel in control then
09:24 AM rue_house: could you show me how to do 7.058*k in asm?
09:24 AM rue_house: ... then I need the square root...
09:36 AM rue_house: anyhow, if your not doing math, asm is sure good on space
09:37 AM noqnio1: apples and oranges :)
09:50 AM Jartza: I could, yes.
09:50 AM Jartza: but I'm also too lazy to do that :)
09:51 AM LeoNerd: Emil: How's the 328PB'ing? In need of my avrdude config sometime?
09:52 AM Emil: LeoNerd: yeah I'll take everything you can give me :D
09:53 AM LeoNerd: #phrasing
09:53 AM Emil: I'll try compiling the toolchain from source, also
09:53 AM Emil: see if gcc has added support
09:53 AM LeoNerd: Ah, yeah I don't know about that part. The gcc and libc I have already support it
09:53 AM LeoNerd: So I didn't have to do anything there
09:53 AM Emil: Ah
09:53 AM Emil: The io definitions are there?
09:54 AM LeoNerd: Yah
09:54 AM Emil: Oh niceee
09:54 AM LeoNerd: Ialready have an io/atm328pb.h
09:54 AM Emil: Then it is just a matter of avrdude config
09:54 AM LeoNerd: Yup
09:54 AM Emil: What version added the io definitions, do you know?
09:55 AM LeoNerd: Hrm... I'll see if Changes has any mention
09:57 AM LeoNerd: Emil: http://paste.debian.net/958391 <== turns out to be pretty easy ;)
09:59 AM LeoNerd: That just tells avrdude that a 328PB is basically a 328 with a different signature
09:59 AM LeoNerd: Since for avrdude's purposes, it is
10:09 AM Emil: yeah
10:09 AM Emil: thanks
10:11 AM Emil: http://download.savannah.gnu.org/releases/avrdude/?C=M&O=D
10:11 AM Emil: I should also see if the most recent version supports it already
10:45 AM Emil: LeoNerd: where is that config supposed to be put btw?
10:47 AM LeoNerd: I put it in my $HOME/.avrduderc
10:48 AM Emil: Interestin
10:52 AM polprog: enhering: yeah, i know they wear out. But for 100pln ($33) it's not much of a loss
10:52 AM polprog: enhering: and indeed the lines are beautiful :P
10:54 AM Emil: polprog: whatcha buying?
10:54 AM polprog: nothing
10:55 AM polprog: gotta check the street market tomorrow
10:55 AM polprog: *sunday
10:55 AM Emil: but you are referencing some product?
10:55 AM polprog: im talking about an unkown-condition argon (or other gas?) laser that i was offered or 30 bucks
10:55 AM polprog: for* :P
10:56 AM polprog: not sure of it's still there
10:57 AM polprog: if not, there are hundreds of electronic oddities to play with
01:05 PM toblorone: Hi, I'm trying to get "high speed" out of usb transfers, and I can't seem to figure out what the limiting factor is. At the moment, I'm using a CDC endpoint, with a userspace driver on the host side, and the fastest I'm managed to get is ~250kbps. While ultimately I'm hoping to see 5mbps, I'd be happy with 1mbps. here is the configuration descriptor I've pieced together: https://pastebin.com/SuCwC4mG
01:07 PM Emil: no
01:07 PM toblorone: hmmmm
01:07 PM Emil: you cant
01:07 PM toblorone: with cdc?
01:07 PM Emil: avrs do full speed or low speed
01:07 PM Emil: no high speed
01:08 PM bss36504: toblorone: Wait you're trying to do this with an avr?
01:09 PM bss36504: I assumed yesterday when we were talking that you were using another chip
01:09 PM toblorone: well I'm not actually using avr, this is just one of the few channels I could find that have people knowledgable about this stuff
01:09 PM bss36504: Oh ok
01:09 PM bss36504: Yeah, cause AVR definitely can't do 5Mbps
01:09 PM Emil: if you want 1Mbps use a spi/serial to (high speed) usb converter
01:09 PM Emil: bss36504: not usb
01:09 PM Emil: bss36504: but you can get data out at 8Mbps
01:10 PM bss36504: Yeah I know. I was talking with toblorone about this yesterday
01:10 PM toblorone: emil: any examples of one?
01:10 PM bss36504: I'm happy to have others weigh in
01:10 PM bss36504: toblorone: Go look at FTDI's website
01:10 PM Emil: toblorone: well, even the basic cp2102 works just fine at 1Mbaud
01:10 PM bss36504: they have a bunch of "USB to xxx" converters
01:10 PM Emil: which I use to stream 8 bit audio at
01:10 PM Emil: pcm
01:11 PM toblorone: bss36504: well in the mean time, I wrote my own CDC driver, but now I'm thinking there is actually no way to achieve the desired speed on CDC
01:11 PM Emil: not on full speed device, no
01:11 PM bss36504: I think the limiting factor will be hardware here
01:11 PM Emil: bss36504: the usb spec is also really shit actually
01:11 PM bss36504: I can't see why a CDC device wouldnt work.
01:12 PM Emil: at using the bandwidth
01:12 PM Emil: bss36504: the cdc class works and has low overhead
01:12 PM toblorone: well Im reading this site: http://www.usbmadesimple.co.uk/ums_6.htm
01:12 PM toblorone: oh
01:13 PM toblorone: so my board definitely supports usb 2.0 OTG HS
01:13 PM toblorone: but, I can't seem to figure out how to put it in HS mode, I guess. I was mistakenly trying to up the packet size
01:13 PM toblorone: but I see that with CDC 64 is the max
01:14 PM Emil: toblorone: also
01:14 PM Emil: toblorone: with usb
01:14 PM Emil: low latency cannot be achiwved with high throughput
01:15 PM Emil: usb is a horrible spec imho
01:15 PM toblorone: how low are you talking about?
01:16 PM toblorone: can i expect to achieve ~7-10ms?
01:16 PM Emil: from human perspective small but we are not very quick
01:16 PM Emil: toblorone: that should be fine
01:26 PM toblorone: are there any functional differences between normal USB and OTG that I should be aware of? I'm using an android phone as the host device
01:30 PM bss36504: OTG is just a device that can act as a host
01:30 PM bss36504: Your phone is an OTG device
01:40 PM toblorone: bss36504: ok, I was reading through a guide and they mentioned that they were going to add a section specifically dealing with OTG but they apparently never got around to it
01:43 PM toblorone: they even mention "OTG Descriptors"
01:53 PM bss36504: hmmm
01:53 PM bss36504: I'm not sure then
02:19 PM toblorone: So after reading through a bunch of guides (http://www.usbmadesimple.co.uk/ums_7.htm, http://www.beyondlogic.org/usbnutshell/usb1.shtml, etc) I still don't understand how high speed mode is initiated. The usb made simple guide (http://www.usbmadesimple.co.uk/ums_6.htm) makes it sound as if the speed is determined by the hardware
02:19 PM toblorone: but that can't be right, can it?
02:20 PM toblorone: There doesn't seem to be anything in the various descriptors that indicate the desired speed
02:22 PM bss36504: toblorone: https://en.wikipedia.org/wiki/USB#USB_2.0_Speed_Negotiation
02:24 PM toblorone: bss36504: right, thats what the other guide said... so I take it that the chosen speed it not set in the firmware?
02:24 PM bss36504: Or not supported by the hardware in the phone.
02:25 PM toblorone: is there any way other than an oscilloscope to verify the speed?
02:26 PM bss36504: It's not impossible that when acting as a host the phone can't do high speed
02:26 PM bss36504: I would assume if there is a way it would be via software on the phone
02:27 PM bss36504: for example, in windows you can use the device manager to figure out what speed grade you're running a device in
02:27 PM bss36504: Is there any way you can do some debug on an actual PC to rule out the device as being the problem?
02:51 PM day_ is now known as daey
02:55 PM toblorone: bss36504: sorry I was at lunch, yeah I'll try that
03:30 PM polprog: i believe windows would be pain for debugging usb
03:31 PM polprog: keep in mind im biased by using linux for the past 10 years
03:31 PM polprog: i cant think of any sane way i could debug usb with windoes
03:31 PM polprog: windows*
03:31 PM bss36504: I didn't mean debug per se, I just meant move to a more "conventional" computer vs sticking on the android
03:32 PM polprog: that would definitely help lol
03:32 PM bss36504: Windows should at least be able to provide some simple but useful info in this case, but so would linux or mac or whatever else
03:32 PM toblorone: yeah, I'm not tied to windows for this project, just so happens the toolchain was the easiest to set up on windows
03:33 PM toblorone: i have been able to determine that the device is being recognized as a Full Speed device and not a high speed device, even on windows
03:35 PM bss36504: well that's good information for you
03:35 PM bss36504: at least it points you in the direction of something concrete
03:35 PM bss36504: what chip are you using again?>
03:35 PM polprog: https://puu.sh/w7VzS/29a97143fc.jpg
03:36 PM polprog: vfd <3
03:36 PM bss36504: Every time I read VFD my brain says variable frequency drive
03:36 PM bss36504: not vacuum florescent display
03:38 PM polprog: if i could get a dead one
03:38 PM polprog: id repurpose the vfd in seconds
03:38 PM toblorone: bss36504: one, sec I'm looking through the data sheet of my development board to find the exact usb bus its using
03:40 PM _kl0wn is now known as kl0wn
03:55 PM toblorone: fuuuuuuck
03:55 PM toblorone: well I may have figured out my problem
03:55 PM toblorone: ;^)
03:55 PM toblorone: on some more digging through the spec sheet, it seems i was mistaken on whether my board supported usb HS
04:07 PM toblorone: sorry, im not too experienced with this stuff so I just want to double check, the data sheet on page 27 makes no mention of High Speed
04:07 PM toblorone: http://www.st.com/content/ccc/resource/technical/document/user_manual/group0/26/49/90/2e/33/0d/4a/da/DM00244518/files/DM00244518.pdf/jcr:content/translations/en.DM00244518.pdf
04:08 PM toblorone: so its safe to assume, this board is a dead end?
04:10 PM bss36504: Well the spec isnt exactly clear when "High Speed" is faster than "Full Speed"
04:11 PM bss36504: But yeah, looks like your board support OTG with Full Speed device mode
04:11 PM bss36504: aka, the 12mbit mode
04:18 PM toblorone: right, which means I can't possibly hit the desired throughput with a CDC endpoint
04:19 PM toblorone: with this bus my only option seems to be isochronous then
04:20 PM bss36504: Why not just change devices?
04:20 PM bss36504: Surely ST makes something fast enough
04:20 PM bss36504: You could develop part of your application on this board then port it to a faster controller at a later date
04:22 PM toblorone: yeah, I'll probably end up doing that
04:24 PM toblorone: well at least I've learned a bit of usb along the way
05:04 PM Emil: polprog: I also have a fancy vfd calculatoe
05:04 PM Emil: gonna repurpose it for log printing
05:16 PM day_ is now known as daey
10:50 PM rue_house: cfd is variable freq drive
10:50 PM rue_house: er vfd
10:50 PM rue_house: its also vacuum flourescent display
10:51 PM rue_house: -- hey --
10:51 PM rue_house: are we ALL switching over to stm32 processors?
10:52 PM rue_house: cause, not that I'm a topic natzi, but this is an 8 bit avr channel...
10:52 PM rue_house: if we all move over to stm32, were gonna have to change some things
10:53 PM -!- #avr mode set to +o by ChanServ
10:54 PM rue_house changed topic of #avr to: 8 bit atmel microcontrollers ...and stm32... http://wormfood.net/avrbaudcalc.php http://www.engbedded.com/fusecalc/
10:54 PM -!- #avr mode set to -o by rue_house
11:17 PM Casper: rue_house: yes you are a topic nazi, thru you are a true nazi! Are you proud of that nazi tag?
11:40 PM polprog: we obvuously need 4 8-bit channels to talk about stm33, duh
11:50 PM rue_house: stm33?
11:51 PM polprog: its the new one, theyve added a bit so you can do bigger numbers :P /s
11:52 PM rue_house: ah