#avr Logs
Jun 20 2017
#avr Calendar
12:24 AM polprog_: NoHitWonder^: thanks :)
12:26 AM polprog_: why ukrainian guy :P
01:01 AM rue_house: he laft?
01:22 AM polprog_: obviously
01:22 AM polprog_ is now known as polprog
02:38 AM dunz0r_ is now known as dunz9r
02:38 AM dunz9r is now known as dunz0r
02:50 AM Emil_ is now known as Emil
02:50 AM Guest15146 is now known as Emil_
03:52 AM crib- is now known as crib
04:24 AM Emil: For others interested
04:25 AM Emil: If the readout is actually between 0 and 0.3 and not just over the component, then simply playing with the value at vref is enough to get full range
04:25 AM Emil: unless vref has a minimum voltage value
04:37 AM polprog: context?
04:49 AM Jartza_ is now known as Jartza
06:35 AM Emil: polprog: above
06:36 AM Emil: wirts-leg at 06:30:41 +0300
10:03 AM Emil: https://www.youtube.com/watch?v=QCqxOzKNFks
10:06 AM bss36504: Are sumo bots autonomous? I don't know anything about it
10:09 AM bss36504: I like the one at 4:09 that just shits it's batteries out
10:10 AM Emil: Yeah they are autonomous
10:11 AM Emil: I like the one that just steps out of the way :D
10:11 AM bss36504: It really is quite amusing
10:23 AM learath_ is now known as learath
10:35 AM Casper: I prefer the battlebots
10:35 AM Casper: some are sooo dangerous
10:36 AM Casper: like the one that threw out some steel piece over the fence, just beside the commenters
10:36 AM Casper: that was some carnage :D
10:42 AM LeoNerd: For my next big PCB design, I'm thinking of making a 328PB breakout board, with plenty of configuration options for doing "isolated" IO of various kinds. I'm thinking of putting in an isolated SPI port, I²C port, a few spare GPIO lines,... each one powered by a DC isolator
10:43 AM LeoNerd: I think the idea will be that the board itself has lots of space for those options to be installed, but I won't necessarily populate them all every time.. something a bit customisable. Anyone else have much need for galvanically-isolated IO? What else might I consider?
10:43 AM LeoNerd: I might also do the UART, possibly optionally also as an RS-485
10:43 AM Emil: Galvanic isolation :D
10:43 AM Emil: How are you going to achieve that?
10:44 AM LeoNerd: There's loads of chips. Analog Devices, for example; go see the ADuM14xx series
10:44 AM LeoNerd: Those are expensive, but there's cheaper clones made by TI, Maxim and Silicon Labs
10:44 AM LeoNerd: Maxim also make a /really/ nice 6-channel isolator that's got 4 fast unidirectional lines, good for SPI, and 2 bidirectional open-drain ones that are perfect for I²C
10:45 AM Emil: but
10:45 AM Emil: why
10:45 AM LeoNerd: But if I used that, I'd force SPI and I²C buses onto the *same* ground reference, which might not be what was wanted
10:45 AM LeoNerd: The why, is because right now I'm working on a circuit that needs a ground-lifted ADC, and probably next I'll be working on a bigger thing that needs lifted ADC and DAC
10:46 AM Emil: "ground-lifted"?
10:46 AM LeoNerd: ground at ADC is not ground at MCU/front panel/power supply to unit
10:47 AM Emil: then why not just use either a differential to sigle end converter (easy) or just use a differential adc directly (super easy)
10:47 AM Emil: costs pennies
10:47 AM LeoNerd: Differential ADCs can only cope with inputs that are still within their own power supply range
10:47 AM LeoNerd: This isolator can cope with commonmode difference of up to 1kV
10:48 AM Emil: but
10:48 AM LeoNerd: So e.g. I can put 12 or 24V or whatever onto it and that's fine
10:48 AM Emil: well I mean sure, but it still sounds convoluted af :D
10:48 AM LeoNerd: It's a very standard technique
10:48 AM Emil: why not just use opto isolators?
10:49 AM LeoNerd: Optos are /slooooow/
10:49 AM Emil: lol wtf :D
10:49 AM LeoNerd: Go look at recovery times of optos. Now go read about the ADuM140x chips. Latter can do 100Mbit/sec if you get the highest grade version
10:49 AM LeoNerd: You have to pay fancy to get 100kbit/sec out of optos. Often things like the 6N25 are nowhere near that
10:50 AM LeoNerd: Er.. 4N
10:50 AM LeoNerd: But yes in essence these modern digital isolators really just act like a faster simpler version of an optoisolator
10:50 AM LeoNerd: Just usually they come in more channels. And are smaller. And faster. And more reliable. And easier to drive
10:50 AM LeoNerd: Digital-in digital-out directly
10:55 AM Emil: Well
10:55 AM Emil: I'm intriqued
10:55 AM Emil: Why the fuck are optos so slow
10:55 AM LeoNerd: Recovery time of phototransistors, mostly
10:55 AM Emil: But I'm sure they can pass modulated signals?
10:55 AM Emil: That don't turn completely off
10:55 AM LeoNerd: The (usually IR) emitter is nicely quick, but the transistor that picks it up has a slow response to recover from saturation
10:55 AM LeoNerd: So it can't turn off very quickly
10:56 AM LeoNerd: Yes; that's what fancier optos do. E.g. look at the crazy electronics inside a 6N137
10:56 AM LeoNerd: That one is fast enough to handle DMX (250kbit/sec)
10:57 AM LeoNerd: But that's still nothing on even the cheapest low-range end of these digital isolators. They usually work either capacitively, or inductively
10:57 AM LeoNerd: The circuit *inside* those chips is much more complex again, but from the outside treating it as a blackbox, they're really simple to use
11:00 AM LeoNerd: Hmm. Maybe one SPI w/ single SS line, one I²C and 4 GPIOs, 2 in each direction, is probably sufficient
11:01 AM LeoNerd: Question becomes do I keep those on three potentially-separate power domains, or combine them? if I combine them then I can use that Maxim chip to do I²C and GPIO in one go
11:01 AM LeoNerd: Oh and the UART/RS485. Hmm
11:14 AM Emil: Hmm
11:14 AM Emil: So
11:14 AM Emil: When streaming real time
11:14 AM Emil: You have this tricky situation
11:15 AM Emil: Where time between samples is annyoingly small
11:15 AM Emil: But you need to transmit samples faster or at the same rate as you sample
11:16 AM Emil: Sometimes you miss the deadlines
11:16 AM Emil: but there are techniques to mitigate those
11:16 AM Emil: anyone remember or know where I could read more about them?
11:16 AM Emil: Real time audio glitching popping cracking removal
11:16 AM cehteh: what samples? audio, video, data?
11:16 AM cehteh: ah
11:17 AM Emil: I found a good article on it some time ago
11:17 AM Emil: But can't find it anymore :D
11:17 AM cehteh: you can interpolate missings samples
11:17 AM bss36504: Faster CPU
11:17 AM bss36504: :P
11:17 AM Emil: bss36504: faster cpu does not realy help
11:17 AM Emil: and it's not the issue, either, really
11:18 AM cehteh: also adjust playback speed by a little bit
11:18 AM cehteh: https://github.com/ahjolinna/mpv-conf/blob/master/mpv/etc/scripts/streamcache.lua
11:18 AM bss36504: Well if youre not able to sample and send fast enough, a faster CPU would help, right?
11:18 AM cehteh: i put that into my mpv config
11:18 AM Emil: cehteh: hmm, that's pretty evil but does actually work
11:18 AM LeoNerd: Are we talking audio streaming, or..what?
11:18 AM Emil: LeoNerd: audio
11:18 AM Emil: yeah
11:18 AM LeoNerd: Many different concerns, problem domains, allsorts
11:18 AM Emil: Hmm
11:19 AM LeoNerd: Usual technique is a jitter buffer with backpressure
11:19 AM LeoNerd: The larger the buffer, the higher the end-to-end latency but the better it can cope with occasional sending failures, dropouts, etc
11:19 AM Emil: Is there an article or something I could read about it?
11:19 AM LeoNerd: I'd just start by googling "jitter buffer"
11:19 AM cehteh: see the streamcache above, adjusting playback speed to keep the buffer filled
11:20 AM Lambda_Aurigae: just buffer it.
11:20 AM Lambda_Aurigae: that's what ram is for!
11:20 AM LeoNerd: Mm.. RAM
11:20 AM cehteh: then you can work with reasonable small buffers
11:20 AM LeoNerd: I'm using one of those tiny little I²C-attached inch-wide OLEDs, and half of my RAM has gone just on a display buffer for it
11:20 AM Lambda_Aurigae: so get a better chip!
11:21 AM Emil: cehteh: that is a good strat
11:21 AM Lambda_Aurigae: or add an spi attached sram chip!
11:21 AM Emil: Lambda_Aurigae: buffer doesn't help
11:21 AM LeoNerd: Hrm. That could be amusing
11:21 AM Emil: Lambda_Aurigae: larger buffer*
11:21 AM Emil: Point is to prevent glitches on output
11:21 AM LeoNerd: Buffering adds latency, but papers over small delays in transmission or other problems
11:22 AM cehteh: when samples are really missing you want to prevent clicks and noise, that means you have to interpolate the last waveform and fade towards zero, but that needs fft
11:22 AM LeoNerd: Fundamentally if the data isn't there, the data isn't there.. you'll have to do *something*
11:22 AM cehteh: i guess you want to opt for least possible latency right?
11:22 AM LeoNerd: cehteh: Eh; the human ear will be fine with a simple linear trend to zero
11:22 AM LeoNerd: No need to get FFT involved
11:22 AM Emil: Point is that there is no resend :D
11:22 AM Emil: And it'll be done with an avr
11:22 AM LeoNerd: Yah, you don't want to resend
11:23 AM LeoNerd: That adds even more latency. If the data isn't there at the time it is needed, having it too late is useless
11:23 AM LeoNerd: The point of the buffer is to send data ahead of when it's needed so there's time to fill it and be sure you've got it
11:23 AM cehteh: LeoNerd: depends, if it was sharply rising you cant just swap the direction towards zero that will be audible, well lacking data will alwasys be audible, the question is only how annoying it is
11:23 AM LeoNerd: But the buffer-fill process still wants backpressure to keep the rates matched
11:24 AM Emil: Hmm, I think sample interpolation with low pass filtering should work
11:24 AM Emil: playbackspeed adjustment might also work in some cases
11:24 AM cehteh: depends on your quality demands
11:24 AM LeoNerd: Depends what the source is
11:24 AM Lambda_Aurigae: audio should all just go back to analog!
11:24 AM Emil: heh
11:24 AM LeoNerd: If the source is recorded media from a file, you can adjust the sender's speed to match the receiver
11:24 AM LeoNerd: Have the receiver *pull* it
11:24 AM cehteh: audio has a lot frequency range you cant simply interpolate it
11:24 AM LeoNerd: If the source is some live input you've no control over, then yes you'll have to do fancier interpolation techniques to match the rates
11:25 AM Emil: LeoNerd: live
11:25 AM cehteh: yes pushing some control to the sender to speed up/slow down might be better than adjusting the playback speed if possible
11:26 AM cehteh: the best thing is to have a rolling fft over the past data to use it to fade to zero, but fft on avr, i guess thats a nogo
11:27 AM cehteh: mhm is your receiver a avr or only the sender?
11:27 AM Emil: both
11:27 AM cehteh: you may also batch/buffer data on zero crossing boundaries, switching silent at zero is a bit better than anywhere else
11:28 AM cehteh: but still abrupt
11:28 AM LeoNerd: Audio on an AVR is pretty tough. 16MHz, 48kS/sec, gives 333 instructions per sample.
11:28 AM Emil: and that's only for 8 bit
11:33 AM cehteh: so almost nothing doable
11:33 AM cehteh: there are a lot clever things to optimize audio, but they need a bit processing power
11:34 AM Emil: Yeah, compressing allows one to send at a vastly smaller datarate
11:34 AM Lambda_Aurigae: I would go with dspic or pic32 myself...but,,
11:35 AM Emil: Hmm
11:35 AM Emil: What cheap compression methods are useful for audio
11:37 AM cehteh: compressing adds latency too (you have to look at the data and process it)
11:38 AM Emil: sure
11:38 AM Emil: well
11:38 AM cehteh: i doubt you can
11:38 AM cehteh: stereo or mono?
11:38 AM Emil: actually it depends
11:38 AM Emil: it does not add more latency than just buffering a fixed amount of samples
11:38 AM Emil: cehteh: mono
11:39 AM Lambda_Aurigae: bah..just remove all the zeros...it's just the ones that you are interested in after all!
11:39 AM cehteh: buffering a fixed amount of samples means latency
11:39 AM Emil: And since single sample streaming is super inefficient that's not what I'm going to be doing :D
11:39 AM Emil: cehteh: sure
11:39 AM Emil: yes
11:39 AM Emil: cehteh: but no one does single sample audio streaming
11:40 AM Emil: except if analogue
11:40 AM cehteh: sure .. on board when you need no latency and have a dedicated bus thats ok
11:40 AM cehteh: (or enough allocated bus bandwidth)
11:41 AM cehteh: anyway audio compression is a complex thing and the human ear is much more sensitive to errors than the vision
11:41 AM cehteh: you can do some logarithmic encoding look at the old µ-law and A-law codecs
11:41 AM cehteh: send only the difference to the previous samples (usually thats has lower magnitude)
11:42 AM cehteh: when you do that you can compress this somewhat just needs some encoding scheme
11:43 AM Emil: hmm
11:43 AM Emil: How about double delta encoding
11:43 AM Emil: derivative encoding
11:43 AM cehteh: use bandwidth peeling, only transfer the most siginificat bits (low pass filtered) first, then the details, if the details get missing you still have a (albeit bad/lossy) signal to playback
11:43 AM Emil: since audio is always changing
11:43 AM cehteh: and so on
11:43 AM cehteh: just google
11:43 AM Emil: encode the difference in rate of change
11:43 AM cehteh: yes
11:44 AM cehteh: well and foremost you want to lowpass on your input even before the adc, half of the sampling frequency
11:44 AM cehteh: else you sample a lot aliasing noise which makes it harder to compress and dont improve the signal
11:45 AM Emil: yeah
11:45 AM cehteh: lowpass is a good way to improve compression anyway
11:46 AM Emil: I'm doing hardware lowpassing, saves cycles
11:46 AM Emil: and allows for a sharp filter
11:46 AM cehteh: doesnt need to be that sharp
11:46 AM Emil: no
11:46 AM Emil: but it's always nice
11:46 AM Emil: I mean
11:47 AM Emil: hardware low pass is effectively free computation here :D
11:47 AM cehteh: yes
11:48 AM cehteh: and you want to keep the shit from the adc, so you basically have to use at least a simple analog filter first
11:53 AM psf: Newbie question/issue, I believe... I'm quite new to AVR, I'm basically playing with arduinos for now but bought an atmega328p to trying something (I don't have anything in mind right now). Anyway, kinda that I'm feeling like I need a direction to begin. Found this playlist from Atmel https://www.youtube.com/playlist?list=PLtQdQmNK_0DRhBWYZ32BEILOykXLpJ8tP. But I do likes books though. Any tips, advices, book recommendations?
11:54 AM LeoNerd: I personally think the entire world of microcontrollers and digital electronics lately is moving a bit too fast to consider a dead-tree-paper book
11:55 AM LeoNerd: I have a couple of books on general electronics design (H&H 3rd Ed., Principles of PCB Design) because those are pretty stable topics that aren't going to massively change in 10 years time
11:56 AM LeoNerd: But anything AVR-specific I'd stick to online things; especially at the moment due to the ongoing merger between Atmel and Microchip
11:56 AM psf: "is moving a bit too fast": I see, good point.
11:56 AM LeoNerd: Lots of fun new things coming up now (e.g. the 328PB which I'm playing with)
11:56 AM LeoNerd: There's *basically* little point in continuing with a 328P now the PB exists
11:57 AM tpw_rules: what's the PB?
11:57 AM Lambda_Aurigae: tpw_rules, new version...
11:57 AM tpw_rules: what's different
11:57 AM LeoNerd: Muuuch nicer. New version of the 328P
11:57 AM Lambda_Aurigae: has some new bits...double spi and double i2c
11:57 AM psf: sounds about right... too bad I live in a shit country lol and things are a little bit slow around here so I only have easy access to 328p
11:57 AM psf: I believe.
11:57 AM Lambda_Aurigae: maybe double usart too.
11:57 AM LeoNerd: Two SPI, two I²C, two UARTs... entire new GPIO port
11:57 AM LeoNerd: PORTE - 4 pins, adds digital IO ability to the previously analog-only ADC6/ADC7, also steals two of the power pins as IOs
11:57 AM Lambda_Aurigae: it was one of the last things atmel did before microchip bought them.
11:58 AM LeoNerd: Internally, even more timers. It has three clones of the 16bit timer1 now
11:59 AM Lambda_Aurigae: if they would just kick up the core cpu speeds dangit! and give us something that can execute code from sram,,internal or external....that's not an xmega
11:59 AM LeoNerd: Personally I find the CPU speed fine; usually the thing that bites me is lack of IO pins, or IO pins colliding
11:59 AM * LeoNerd mumbles *again* about the stupid 32U4
11:59 AM LeoNerd: Though lately RAM is my pinching point; see above about OLEDs
12:00 PM Lambda_Aurigae: I like the atmega1284p...lots of flash, lots of ram, lots of i/o
12:00 PM Lambda_Aurigae: that 16K sram is nice.
12:01 PM Lambda_Aurigae: would love to be able to load 4K applets into sram and execute them.
12:01 PM LeoNerd: Hmm.. not a bad looking chip
12:01 PM Lambda_Aurigae: bit pricy last time I bought them though.
12:01 PM LeoNerd: Eh, execute from SRAM has all sorts of complications on it
12:01 PM Lambda_Aurigae: pic32mx270f256b is my go-to chip these days.
12:01 PM LeoNerd: Personally I like knowing I can't possibly overwrite the *program* with runaway pointers
12:02 PM LeoNerd: Huh the summary claims it has three SPI ports
12:02 PM Emil: psf: https://emil.fi/avr
12:02 PM Lambda_Aurigae: 64K sram..and it CAN run from sram.
12:02 PM Lambda_Aurigae: LeoNerd, 2 hard SPI and the USART in SPI mode.
12:02 PM LeoNerd: Ah
12:02 PM LeoNerd: Oh, no... one SPI, two USARTs with SPI ability
12:03 PM Lambda_Aurigae: ok.
12:03 PM Lambda_Aurigae: something in that direction.
12:03 PM Lambda_Aurigae: hehe
12:03 PM Lambda_Aurigae: same smell different finger.
12:03 PM LeoNerd: But yah, that's a bit of a cheat I feel
12:03 PM psf: Emil: thanks... and thumbs up for ASCII and not fancy image and stuff like that.
12:03 PM Emil: psf: I'm glad you like it
12:03 PM Emil: I try to please :D
12:04 PM Emil: LeoNerd: sounds like you need linux ;)
12:04 PM Emil: MPU and shit
12:04 PM Emil: And MMU
12:05 PM LeoNerd: Hah.. Linux on an AVR
12:06 PM bss36504: LeoNerd: http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit
12:07 PM LeoNerd: Yah Iv'e seen that before
12:07 PM LeoNerd: Thats' more Linux on an ARM that is *emulated* on an AVR
12:07 PM bss36504: Thats almost more impressive to me lol
12:09 PM Lambda_Aurigae: LeoNerd, been done....
12:09 PM Lambda_Aurigae: arm emulator running on an atmega1284p with external 4MB ram stick.
12:09 PM LeoNerd: Yes, that's the link above
12:09 PM Lambda_Aurigae: oh....screen slow refresh here.
12:10 PM Lambda_Aurigae: I'm remoted into home from my work laptop over a crappy cell modem link....in the basement so no signal for squat.
12:10 PM Tom_itx: It takes about 2 hours to boot to bash prompt ("init=/bin/bash" kernel command line). Then 4 more hours to boot up the entire Ubuntu
12:10 PM Tom_itx: hah
12:10 PM Lambda_Aurigae: Tom_itx, I've built it!
12:10 PM Lambda_Aurigae: it does run.
12:11 PM Lambda_Aurigae: have kinda(vaguely) considered adding another avr or two and reworking it into a multiprocessing system.
12:11 PM Lambda_Aurigae: maybe 8 more....for 8 cores plus a supervisor chip.
12:12 PM Lambda_Aurigae: I should dig it out and hook the OctaPentaVeega to it for display.
12:12 PM Emil: :D
12:57 PM bss36504: http://hackaday.com/2017/06/19/intel-discontinues-joule-galileo-and-edison-product-lines/
12:58 PM bss36504: Color me surprised...not
12:59 PM specing: not enough backdoors for them :)
01:00 PM BongoShaftsbury_: is there a particular method or technique when interfacing with the to have the cursor stay in one position and push all the text down / up?
01:01 PM BongoShaftsbury_: i thought of keeping track of all the data written to the lcd and rewritting the adjusted data, but i'm thinking there has to be a way to use the data already on the lcd
01:08 PM cehteh: check datasheet of the lcd, does it have some cursor control sequences like terminals do?
01:10 PM polprog: its that graphucal lcd?
01:10 PM polprog: graphical*
01:11 PM BongoShaftsbury_: like a dot matrix?
01:11 PM BongoShaftsbury_: yes
01:12 PM BongoShaftsbury_: i see commands for addresses
01:12 PM BongoShaftsbury_: not a cursor control
01:13 PM polprog: theres no cursor then
01:13 PM polprog: you set a pointer to an adrress
01:13 PM DKordic: ``Read-Modify-Write'' should be enough for inserting, right?
01:14 PM DKordic: It has just a few bits anyway.
01:14 PM cehteh: inserting what?
01:14 PM polprog: there could be autoincrement, but not sure if theres shift mode
01:17 PM DKordic: cehteh: Inserting text on a GLCD (http://www.newhavendisplay.com/app_notes/ST7565R.pdf).
02:57 PM Jartza: evening
03:01 PM NoHitWonder^: evening
03:28 PM Emil: Iltaa
03:29 PM polprog: czesc
03:29 PM polprog: o/
03:35 PM Jartza: esc-c-z to you too
03:36 PM polprog: the 595 handler in assembly is fast
03:36 PM polprog: like really fast
03:36 PM Emil: benchmark it against a C implementation
03:36 PM Emil: Or if you give me the specs, I'll try to write one
03:36 PM polprog: well, the c implementation had delays in it...
03:36 PM polprog: :P
03:37 PM Emil: You have learned well
03:37 PM polprog: yes mastrr
03:37 PM Emil: Misinformation is the first step into becoming a hardware guru
03:37 PM polprog: the parcel is coming and in it there are violet leds (i dont have that color yet) and some 16 channel ti pwm controllers i think...
03:38 PM polprog: or maybe some other pwm led drivers... i dont remember... the TIs were expensive,
03:38 PM Emil: heh
03:39 PM Emil: It's always great receiving packets with electronics inside :3
03:39 PM polprog: we should make a travelling giftbox
03:39 PM polprog: circulating
03:40 PM Emil: But I... Lambda_Aurigae will probably loot the whole thing!
03:41 PM Emil: Hmm
03:41 PM Emil: Anyknow know about attiny814/816/817?
03:41 PM Emil: I wonder where I could get definitions for them
03:41 PM cehteh: atmel?
03:41 PM Emil: yeah
03:41 PM Emil: Well, Microshit
03:42 PM Emil: they are like only attinys by name and ram amount :D
03:42 PM cehteh: oh hardware multiplier
03:42 PM polprog: Microshit is microsoft
03:43 PM Emil: Noo
03:43 PM Emil: M$ is Microsoft
03:43 PM Emil: Microshit is Microchip
03:43 PM polprog: definitions, you mean headers that associate registers to names
03:43 PM Emil: (this is how you never get Microshit to send you free shit)
03:43 PM Emil: polprog: you need 4 thinks
03:43 PM Emil: things
03:44 PM Emil: Well, 5
03:44 PM Emil: crtatmega328pb.o io.h iom328pb.h libatmega328pb.a avrdude.conf
03:44 PM polprog: ok, i get whats avrdude.conf
03:44 PM cehteh: check recent avrlibc source/git or whatever
03:44 PM cehteh: if not there, write it
03:44 PM polprog: what's the rest for
03:44 PM Emil: Well, 4, since they have this new and absolutely poropietari new programming interface
03:45 PM Emil: that avrdude doesn't support yet iirc
03:45 PM Emil: cehteh: I built the toolchain for my raspi
03:45 PM Emil: cehteh: the support for m328pb doesn't even come included yet :D
03:45 PM polprog: raspi has nice spidev programmer builtin that avrdude supports, nota bene
03:45 PM Emil: You have to steal it from like the atmel toolchain
03:46 PM Emil: atmel studion *
03:46 PM Emil: psf: if you have a raspi you can use that as a programmer, too
03:46 PM polprog: i just said that o_O
03:46 PM Emil: Iirc anything with the linux gpio driver works
03:46 PM Emil: polprog: just highlighted it for him
03:47 PM Jartza: Emil: I have attiny817 chips
03:47 PM Jartza: I've played with them a bit. they seem to be pretty fun.
03:47 PM cehteh: wow looking nice these chips
03:47 PM Emil: And cheap
03:47 PM Emil: Jartza: tell me moar
03:48 PM Emil: you use the python programmer and a usb to serial cable?
03:48 PM Emil: What toolchain do you use?
03:49 PM Jartza: http://www.microchip.com/wwwproducts/en/ATTINY817
03:49 PM Jartza: and specs are there
03:49 PM Jartza: I use avr-gcc
03:49 PM Jartza: :)
03:49 PM Emil: Where did you get the definitions?
03:49 PM Emil: And files I referenced
03:50 PM Jartza: although programming is a bit PITA with the python-tool
03:50 PM Jartza: it sometimes just fails for no apparent reason
03:50 PM Emil: crtattiny817.o io.h iot817.h libattiny817.a
03:50 PM Emil: interestin
03:50 PM Emil: I bet it is because of not being able to generate the break signal
03:51 PM Jartza: http://packs.download.atmel.com/
03:51 PM polprog: hey that configurable custom logic is like a mini FPGA!
03:51 PM Jartza: yeah. and lot of other nifty stuff in that chip too
03:51 PM Emil: GAH
03:51 PM Jartza: it has PIC peripherals, but AVR (xmega2!) core
03:51 PM polprog: why didnt you mentin that yesterday!
03:51 PM polprog: i could order it
03:52 PM polprog: it's just over a buck in QFN
03:52 PM psf: Emil: yeah I do have (Pi 3 and Zero W).
03:52 PM polprog: :((
03:52 PM Emil: could or could have?
03:53 PM polprog: or couldn't order because they dont have it in stock
03:53 PM polprog: :(
03:54 PM Jartza: the ".atpack" is really a zip
03:55 PM Emil: psf: you can use those to program whatever you want into avrs
03:55 PM polprog: goodnight people
03:55 PM polprog: o
03:55 PM Emil: polprog: good night
03:56 PM Emil: but this ccl is pretty damn niftyt
03:56 PM psf: Emil: that's cool too...
03:56 PM psf: I'll google about it
03:56 PM psf: Thanks, Emil ...
03:56 PM Emil: Thank polprog :)
03:57 PM Jartza: I just unzipped the specs-file for attiny
03:57 PM Jartza: then just run:
03:57 PM Jartza: avr-gcc -mmcu=attiny817 -B /Users/jartza/src/atmel-packs2/gcc/dev/attiny817/
03:57 PM Jartza: of course, change the path to whereever you unzip your specs zip
03:57 PM Jartza: but beware, the atmel ".atpack" doesn't contain root folder, so mkdir && cd first
03:58 PM Emil: hngh, that's pretty cancerous :/
04:02 PM Emil: Waaaait a second
04:02 PM Emil: is EVSYS
04:03 PM Jartza: oh and of course, you need one more parameter
04:03 PM Jartza: -I /Users/jartza/src/atmel-packs2/include/
04:03 PM Jartza: event system. yes.
04:04 PM Jartza: sort of like poor man's DMA
04:04 PM Emil: Yeah
04:05 PM Emil: Also
04:05 PM Jartza: and the core is NOT tiny
04:05 PM Jartza: it's xmega2!
04:05 PM Jartza: so it has HW MUL
04:05 PM Emil: Unless there are some silly restrictions or already existing peripherals
04:05 PM Jartza: and all the other xmega2 core features
04:05 PM Emil: I think that event system can be used to get a capacitive reading directly
04:06 PM Emil: Wait
04:06 PM Emil: 817 is Atmel design
04:06 PM Emil: not Microchip
04:06 PM Emil: Damn
04:06 PM Emil: They were up to so many nice things and then they got bought out
04:06 PM Emil: fuck
04:07 PM Jartza: well, it DOES have microchip peripherals
04:07 PM Jartza: and the EVSYS comes from microchip too
04:07 PM Emil: hMM
04:07 PM Jartza: at least the register names look like microchip ones
04:07 PM Emil: I wonder why the datasheet is branded Atmel
04:08 PM Jartza: well the new one isn't
04:08 PM Jartza: still lot of transition stuff going on it seems
04:08 PM Jartza: old datasheets still say atmel in many places but are to be replaced with microchip
04:08 PM Jartza: http://i.imgur.com/QfEZFs0.png
04:08 PM Emil: Oh that's true
04:08 PM Jartza: at least this attiny817 datasheet says microchip
04:09 PM Emil: I do prefer the Atmel style though
04:09 PM Jartza: they don't seem to update datasheets that often, maybe once, twice a year
04:10 PM Jartza: also if you check the timers
04:10 PM Jartza: the register names are totally different than before, and even the documentation style is different from old atmel datasheets
04:10 PM Jartza: so it's actually microchip peripherals on top of xmega core plus some ram and flash
04:11 PM Jartza: why did they call it tiny, I don't know :)
04:11 PM Jartza: because previously the difference between tiny and mega -series was mainly missing MUL instruction and of course some limited memory
04:11 PM Emil: Aww
04:11 PM Jartza: now we have "tiny" with xmega core and better peripherals than most megas :D
04:12 PM Lambda_Aurigae: if it was only available in the evil DIP package!
04:12 PM Lambda_Aurigae: hehe
04:12 PM Jartza: I have that!
04:13 PM Lambda_Aurigae: on a board.
04:14 PM Jartza: http://i.imgur.com/VuixRhy.jpg
04:14 PM Jartza: :D
04:30 PM hetii: Hi :)
04:37 PM hetii: I try to use IRMP library with v-usb in CDC configuration (writual com port) and have some odd issue regarding receving data on pc side. When I enable interrupt for irmp and meantime send some data to pc (let say some string) its printed out but after some period of time its stop
04:38 PM hetii: as I check uC can still get data from PC side and invoke usbFunctionWriteOut()
04:39 PM hetii: Only by restarting terminal software (minicom or gtkterm) I get again my string printed out
04:39 PM hetii: Any idea how to trace such issue?
04:48 PM Lambda_Aurigae: well, for starters, CDC on low speed USB is not officially supported.
04:48 PM Lambda_Aurigae: it's a hack on top of the v-usb hack.
04:50 PM hetii: ok I can understand that its maybe not perfect solution but still it works fine till I don`t activate timer.
04:50 PM hetii: here is the main.c that I use to play with it: http://paste.ubuntu.com/24911246/
04:51 PM hetii: What is odd for me is that my uC works all the time, I can get data from host side and also do task in main loop
04:52 PM hetii: but from some reason host side after a while is not able to get my data.
04:56 PM Jartza: hmmh. I have shitload of attiny84 chips in stock it seems
04:56 PM Jartza: like. dozens.
04:57 PM Jartza: maybe it's time to invent some use for them
05:04 PM Jartza: should I port octapentaveega to it
05:04 PM Jartza: might be a bit pointless
05:33 PM robinak is now known as robink
05:33 PM Lambda_Aurigae: hetii, probably gets out of sync if you are doing too much outside of handling the usb data.
05:35 PM Lambda_Aurigae: running at 12MHz, that avr is having to spend about 80% of its time handling the usb stuff I would bet.
05:37 PM Jartza_ is now known as Jartza
05:37 PM Jartza: oh. some server timeouts
05:45 PM shifttym1ke is now known as shifttymike
05:45 PM hetii: Lambda_Aurigae, I use 16 MHz crystal
05:45 PM hetii: beside I found two other similar project that use v-usb and irmp together so its doable.
05:45 PM hetii: or least I hope :)
05:45 PM day_ is now known as daey
05:50 PM Lambda_Aurigae: you just have to watch the interrupts very carefully.
05:50 PM Lambda_Aurigae: that thing has to handle the usb interface every so often and if it misses the beat too many times it goes out of sync and that's it...time for reboot.
05:50 PM Lambda_Aurigae: run it up to 20MHz(if the chip is rated for it) and you may solve the problem.
05:58 PM hetii: Lambda_Aurigae, but you know, I can imagine that some out of sync happen, at least it looks like it does, but as usb host is controlled by host and in fact when get or send data happens the host pull it.
05:59 PM hetii: and moreover when my issue happen I don`t lost connection with device
05:59 PM hetii: i`m still able to send some data into it and it works fine
05:59 PM hetii: also kernel don`t raise any usb issues message
06:00 PM hetii: so don`t get it why he is not able to receive data.
06:00 PM hetii: and I don`t even need restart my uC, its just enough when restart terminal software
06:08 PM Lambda_Aurigae: something is losing sync somewhere.
06:24 PM aczid_ is now known as aczid
06:43 PM hetii: Lambda_Aurigae, I change crystal to 20MHz and won`t help, but also I notice that when I restart terminal software I got my last message that I set before restarting this terminal
06:43 PM hetii: so its look like the buffer is set but not pushed out and block queue.
07:21 PM toblorone: dumb question: the firmware for my dev board has an assembly file which i assume is setting up the interrupt vector table. it has entries like:
07:21 PM toblorone: .weak SysTick_Handler
07:21 PM toblorone: .thumb_set SysTick_Handler,Default_Handler
07:22 PM toblorone: But the handler for SysTick_Handler doesn't seem to actually be implemented anywhere...
07:25 PM toblorone: is this normal? Should I expect it to be defined in the source code somewhere?
07:31 PM toblorone: in my case the HAL library's timer functionality doesn't seem to be working. In digging into the source code it seems that it uses SysTick_IRQn (logical choice...)
07:31 PM toblorone: so shouldn't i see a handler defined for it somewhere?
07:43 PM hetii: toblorone, I saw many times initial code that have .weak function but without declaration
07:43 PM hetii: so probably its ok, and you can then declare it in your code.
07:45 PM toblorone: well I'm trying to figure out why the timing libraries provided with the board aren't working... I'm not too familiar with cmsis and HAL but seeing " HAL_NVIC_SetPriority(SysTick_IRQn, TickPriority ,0);" seems to suggest the timer is updated in SysTick_Handler
07:46 PM hetii: toblorone, if its not work at all then probably you need to enable some clock
07:48 PM toblorone: well if i define the handler myself, it gets called. its just that the timer object used by the library doesn't seem to be updated, which i would guess should happen in a handler
07:49 PM hetii: ok sorry no clue ;(
07:49 PM toblorone: no prob ;)
07:49 PM Jartza: systick timer is in arm core
07:50 PM Jartza: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0179b/ar01s02s08.html
07:50 PM hetii: ok time for me. Good luck.
07:52 PM Jartza: that entry just sets SysTick_Handler a default value, being Default_Handler
07:52 PM toblorone: oo right
07:52 PM Jartza: so if you enable systick, the default handler will get fired
07:53 PM toblorone: ok i'll search for that
07:53 PM Jartza: and it probably doesn't have any idea about systick, until you implement it :)
07:53 PM toblorone: yeah... well thats really odd. I shouldn't have to implement it myself... this is using mbed btw
07:53 PM Jartza: those are called vectors
07:54 PM Jartza: most often the systick is used by RTOS
07:56 PM Jartza: probably in HAL_CM0 or something like that has systick implementation
07:57 PM Jartza: haven't used mbed for long time anymore
07:57 PM Jartza: or CM3, CM4, depending which MCU
07:57 PM toblorone: well im not using rtos... If I simply try to call wait() it intializes the system timer and eventually ends up here: https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/TARGET_STM32F7/device/stm32f7xx_hal.c#L242
07:58 PM Jartza: well that seems to configure the systick
07:59 PM toblorone: yeah, which suggests that it uses it to increment the timer value, right?
07:59 PM Jartza: but probably either the board specific startup of HAL_CM[0-4] startup has some systick implementation
07:59 PM Jartza: very often it just increments timer, yes :)
07:59 PM toblorone: hmm well I've grepped through the source dir and I can't seem to find anything...
07:59 PM toblorone: maybe i messed up the search
07:59 PM toblorone: ill try again
08:00 PM Jartza: default systick-handler in mbed WHEN I used it (times ago) was something like just call to HAL_IncTick();
08:00 PM toblorone: ah ok
08:00 PM toblorone: i'll look at that
08:00 PM Jartza: and somehow I remember it was in HAL_CM0.s
08:00 PM Jartza: oops
08:00 PM Jartza: not there
08:00 PM Jartza: system_stm32l0xx.c
08:00 PM Jartza: maybe that
08:01 PM Jartza: it was very low power arm that I used and mbed was still at version 2 or something like that :)
08:01 PM Jartza: but mbed was a bit too arduino-ish to my taste :)
08:01 PM toblorone: yeah, i see that. unfortunately i have no choice in the matter ; )
08:03 PM toblorone: i'm trying to set up mbed to work with cmake and while it compiles, and I can use my ide this small bit seems to be broken...
08:04 PM Jartza: heh. I also hate cmake ;)
08:04 PM Jartza: meson for teh win
08:05 PM Jartza: http://mesonbuild.com/
08:06 PM Jartza: well anyhow, can't remember better the mbed solutions anymore as it's been a while
08:06 PM Jartza: and it's also 3:30am, I should be sleeping :)
08:08 PM toblorone: what exactly is better about meson? doesn't cmake have the advantage of being supported by a ton of ides?
08:08 PM toblorone: also
08:08 PM toblorone: i've found that HAL_IncTick is defined
08:08 PM toblorone: and its called in
08:09 PM toblorone: timer_irq_handler
08:09 PM toblorone: but that never seems to be called
08:09 PM Jartza: yeah. maybe just implement your own systick_handler?
08:09 PM Jartza: just a call to HAL_IncTick()
08:10 PM toblorone: well I'd expect that I shouldn't need to do that... but if i run out of options I guess ill do that
08:10 PM toblorone: oo
08:11 PM Jartza: well, if your code initializes systick, which it apparently does when using HAL, then you need handler for systick :)
08:11 PM toblorone: i might be using the wrong source files...? I see HAL_InitTick is defined in two different source files, one of which does what I want, whereas the other simply configures SysTick
08:12 PM toblorone: and the SysTick is declared __weak
08:13 PM Jartza: and well... meson is much less painful to configure than cmake, it's gazillion times faster especially on big incremental builds, the configuration is much more readable, it's modern and just fluffy and cute
08:13 PM toblorone: ha ok
08:13 PM toblorone: well i've heard the hype
08:14 PM toblorone: but unfortunately it doesn't seem to be supported by all the ide's my coworkers use ;)
08:15 PM toblorone: ok and the problem seems to be that the non-weak definition of HAL_InitTick (the good one) isn't overriding the bad one
08:18 PM toblorone: ok well my build system was to build the whole mbed-os as a static lib then link my executable to it
08:18 PM toblorone: but for some reason when doing it this way some of the functions like HAL_InitTick doesn't get overridden
08:20 PM toblorone: Jartza: thanks for the help!
08:21 PM Jartza: toblorone: no prob :)
08:21 PM toblorone: its not quite "fixed" yet but I now know what the problem exactly is so that helps...
08:21 PM Jartza: I need to hit the bed :)
08:22 PM kre10s_: I am using an avr168pb with 3.3v. Sometimes when I power up the IC it appears to hang. It does not apear to be the crystal, I can measure 16Mhz there... I have disabled interrupts, so It can't be that either... What else should I look for?
08:22 PM Lambda_Aurigae: is that chip rated to run at 16MHz at 3.3v?
08:23 PM Lambda_Aurigae: nope
08:23 PM Lambda_Aurigae: it is not.
08:23 PM Lambda_Aurigae: not more than 10MHz at 3.3V
08:24 PM Lambda_Aurigae: have to go to 4.5V to run stable at 16MHz
08:24 PM Lambda_Aurigae: datasheet, page 2
08:26 PM kre10s_: ... if only i could read
08:27 PM Lambda_Aurigae: illiteracy is a bitch, eh?
08:41 PM kre10s_: Its also a bitch that the 44pb and 88pb have the watchdog interrupt at 0x006 but the 168pb has it on 0x00C
08:42 PM kre10s_: why do they do that?
08:53 PM Lambda_Aurigae: because....
09:12 PM kre10s_: also. that makes the 168pb headers wrong... I should file a bug report.
11:01 PM aberon is now known as anonnumberanon
11:08 PM JanC is now known as Guest88964
11:08 PM JanC_ is now known as JanC
11:15 PM enhering: Good night.
11:16 PM enhering: Would you join two PCBs with this: http://www.fujipoly.com/usa/products/zebra-elastomeric-connectors/carbon-connectors.html
11:16 PM enhering: ?
11:42 PM polprog: i'd give it a try
11:43 PM polprog: if you have a way to keep contact between the strip and boards
11:46 PM polprog: also the strip is0 1k resistance so that's only for data
11:46 PM day_ is now known as daey
11:57 PM polprog: also noticed one thing, if tye pads happen to be off a bit, you can have a situation where one pad touches 2 strips and another pad touches onr strip. would that make them different resistance, like 500ohm and 1kohm?