#avr Logs

Jun 29 2017

01:29 AM mark4: so i have a 9600,8N1 coms port set up on a atmega324PA board and im transmitting a letter 'x' every second. the data coming througyh however is not an 'x' which is hex value 0x78 but 0x98 and every few seconds its coming through as a 0xb8
01:31 AM mark4: wtf
01:31 AM Casper: are you using a crystal?
01:31 AM mark4: no
01:31 AM Casper: then wonder no more
01:31 AM mark4: i cant change the clock in the software and i smoked my avr dragon
01:31 AM mark4: :(
01:31 AM mark4: rc osc is at 1mhz
01:31 AM mark4: thats not reliable for comms?
01:31 AM Casper: the internal oscillator of the avr is not precise (+/-10%) and have high jitter
01:31 AM mark4: drat
01:31 AM Casper: you may need to calibrate it
01:31 AM mark4: how?
01:31 AM Casper: for 9600 it could work after that, but remember that the speed depend on the supply voltage and chip temperature, and also part and aging
01:32 AM Casper: do you have an oscilloscope?
01:32 AM mark4: i have a DSO Quad but i have no idea where it is lol
01:32 AM mark4: unfortunately
01:32 AM mark4: you think this is all down to the clock being unreliable?
01:33 AM Casper: you can try to see if going up and down on the baud select register...
01:33 AM Casper: most likelly yes
01:33 AM Casper: as I said, +/- 10%
01:33 AM mark4: ya
01:33 AM Casper: uart have issue past 2%
01:34 AM mark4: i think it IS possible to switch to the external xtal in software but the freeking manual is undecipherable and there is no code examples for doing this that I can find
01:34 AM Casper: I think it is, but I never seen it in the datasheet, but I read some reference to it
01:34 AM Casper: probably in the half of the datasheet that I didn't checke
01:35 AM mark4: this is the 324PA not the 328
01:36 AM mark4: the ONLY hits i can find are "setting up external osc with fuse bits"
01:36 AM mark4: useless to me
01:41 AM gjm: http://www.atmel.com/webdoc/avrlibcreferencemanual/group__avr__fuse.html
01:45 AM mark4: you can write the fuses from code?
01:45 AM mark4: i thought not
01:46 AM mark4: define the fuses at compile time?
01:46 AM mark4: gjm i can define my fuse settings at compile time?
03:42 AM mark4: well reception now seems to be stable but still not correct
03:43 AM mark4: im transmitting 'x' and im receiving 0x00
03:43 AM mark4: always 0x00
04:59 AM Emil: The internal rc is 3% by default
04:59 AM Emil: and 1% with calibration
05:00 AM Emil: It is plenty accurate for 9600 8n1
05:00 AM Emil: If your fuse is set to 1MHz you can just set the prescaler in software to 1
05:00 AM Emil: And then you have 8MHz
05:01 AM Emil: It is not possible to change the clock source in code
05:01 AM Emil: only by fuses
05:01 AM Emil: rtfm
05:20 AM LeoNerd: Depends on the chip. Some of the newer chips have software clock selection
05:20 AM LeoNerd: That's a reason for having the UART_START interrupt by the way
06:12 AM julius_: hi
06:13 AM julius_: can i use this paste that is used to enable better thermal flow between coolers and chips on a orangepi to attach some passiv cooler without the cooler being held in place by screws?
06:14 AM LeoNerd: Thermal paste isn't usually very adhesive
06:14 AM julius_: im kinda worried that the cooler (about 1cm+1cm) will fall off and shorten something
06:14 AM LeoNerd: I think you *can* get thermal glue, but normal paste isn't
06:14 AM julius_: yeah, thats what i thought
06:14 AM julius_: maybe just a tiny bit of normal glue?
06:15 AM Snert: google thermal epoxy.
06:15 AM Snert: normal gloo is not it.
06:17 AM LeoNerd: Alternatively you could use a dab of regular glue at the corners to hold the heatsink on, while the bulk of the pad was thermal paste. But you'd have to check the high-temperature performance of that glue
06:17 AM julius_: ah yes ok
06:18 AM julius_: thanks
06:22 AM cehteh: there are self adhesive thermal pads too
06:31 AM julius_: yes
06:32 AM julius_: i was more looking into something i got at hand, but nothing here for higher temperature
06:32 AM julius_: s
07:56 AM julius_ is now known as julius
09:59 AM Thrashbarg_ is now known as Thrashbarg
11:07 AM Emil: Anyone know of a chip that would do Asymmetric and symmetric crypto for me through, lets say spi interface?
11:07 AM Emil: Lookin at these atm http://www.atmel.com/products/security-ics/cryptoauthentication/default.aspx
11:07 AM LeoNerd: *asymmetric* might be tricky, but I could well expect someone has made a simple AES offload engine
11:08 AM Lambda_Aurigae: Emil, any Intel i7 should handle it just fine.
11:08 AM Emil: Lambda_Aurigae: sucks that I can
11:08 AM Emil: 't embed that one
11:08 AM polprog: why not :P
11:08 AM Lambda_Aurigae: ok..go with an atom then.
11:08 AM Lambda_Aurigae: not as fast but embeddable.
11:08 AM Emil: LeoNerd: Problem with just symmetric is that I need to store and manage keys
11:09 AM Emil: And no forward secrecy
11:09 AM Emil: Hmm, perhaps I should just use some other wifi chip
11:10 AM Emil: That has a proper TLS stack
11:10 AM polprog: cant you just use wpa2?
11:10 AM polprog: id expect a wifi chip to have that
11:10 AM Emil: matey
11:10 AM Emil: wat
11:10 AM Emil: :DDD
11:11 AM polprog: oh, its implemented i softwara
11:11 AM polprog: software
11:11 AM polprog: brainfart...
11:11 AM Emil: polprog: wpa2 is just to secure the device-access point connection
11:11 AM Emil: what
11:12 AM Emil: polprog: wpa2 does nothing against mitm
11:12 AM polprog: look, i dont know more that i need to use linux aps on a daily basis
11:12 AM Emil: Wrong answer
11:12 AM Emil: Anyase
11:13 AM Emil: wpa2 protects the physical connection betweena device and an accesspoint
11:13 AM Emil: it's a point to point protocol
11:13 AM polprog: which osi layer would that be
11:13 AM Emil: phy
11:13 AM Emil: 1
11:13 AM polprog: kk
11:13 AM Emil: Well no
11:13 AM Emil: 2
11:14 AM Emil: Well, it depends
11:14 AM Emil: OSI is not really flexible
11:14 AM polprog: whatever, i dont wanna mess aroud with encryption ow
11:14 AM polprog: now*
11:18 AM polprog: i ever managed to sniff, say packets that my phone sends over wifi with my laptop, not even in monitor mode
11:18 AM polprog: i dont know what am i doing wrong
11:18 AM Emil: never*
11:18 AM Emil: not ever
11:19 AM polprog: never, phone keyboard is shit
11:19 AM Emil: Ah
11:19 AM Emil: explains
11:20 AM polprog: no tutorial i found worked
11:25 AM polprog: that would be very useful for debugging a project involving embedded wifi modules
11:40 AM TLoFP: 1. How can the 328PB be out of stock @ digikey/mouser. Is Microstiff killing the AVR?
11:41 AM TLoFP: 2. I have a timer interupt call a simple pin change function every 39 clock cycles (2.5 uS). In the ISR I call a function that defines the next function call (pointer) the next global counter position (incremented in the ISR) and performs a pin change. Even with these "slow" timing requiremments of 2.5 uS I am seeing massive jitter... what gives? The cpu isn't doing anything else
11:42 AM Emil: TLoFP: lol
11:42 AM Emil: Perhaps someone made a big purchase
11:42 AM TLoFP: when I change the setup to the more complicated goto structure the jitter impoves significantly but does not go away....
11:42 AM Emil: Holy shit this is ridiculous
11:42 AM Emil: all of them gone :D
11:43 AM Emil: TLoFP: matey
11:43 AM Emil: wat
11:43 AM TLoFP: Emil: can't tell if being sarcastic
11:43 AM LeoNerd: TLoFP: If you want a 328PB I'll sell you one on a breakout board ;)
11:43 AM Emil: TLoFP: >every 39th clock cycles
11:43 AM Emil: >ISR
11:43 AM Emil: >Calling a function inside ISR
11:43 AM TLoFP: Emil: yes
11:43 AM Emil: is this "how to fuck up the perf" general?
11:44 AM Emil: "Slow" timing requirements of only 2.5us :D
11:44 AM TLoFP: I was trying to look up the overhead for function cals but couldn't get a reference
11:44 AM Emil: Matey
11:44 AM Emil: a) ditch the fucking ISR
11:44 AM TLoFP: I figured it be a couple of cycles for the call, couple of cycles for the ISR, couple of cycles for the logic check... should not be a problem
11:44 AM TLoFP: Emil: and just do it in software?
11:44 AM cehteh: yes
11:44 AM Emil: Don't call a function inside an ISR
11:45 AM cehteh: or use faster clock
11:45 AM TLoFP: ugh... this 8 banger is sooo not the right tool for the job at hand :(]
11:45 AM Emil: It will PUSH ALL THE REGISTERS
11:45 AM cehteh: naked isr and inline code
11:45 AM TLoFP: Emil: I tried a naked ISR, not much improvement
11:45 AM cehteh: still isr's have some overhead and functioncalls as well
11:45 AM Emil: TLoFP: share the code
11:46 AM cehteh: do you need to do that constantly or only for short bursts?
11:46 AM TLoFP: less jitter: https://pastebin.com/qniqiGuV
11:46 AM cehteh: sbi and cbi are deprecated btw
11:47 AM cehteh: and you dont need the gotos
11:47 AM TLoFP: very bad jitter: https://pastebin.com/x36gwYb2
11:47 AM TLoFP: cehteh: duh, your right... thought of goto to jump to outside function, but can't do that anyways
11:48 AM Emil: TLoFP: longjmp
11:48 AM cehteh: dont need them
11:48 AM cehteh: just unroll the code
11:48 AM cehteh: less jumps and branches
11:48 AM Emil: TLoFP: what are you trying to achieve exactly
11:49 AM TLoFP: Emil: timing generator for signals
11:49 AM Emil: Doesn't tell me anything
11:49 AM cehteh: cant you use hardware pwm for that?
11:49 AM TLoFP: um
11:49 AM TLoFP: like a 3 channel function generator (TTL)
11:50 AM Emil: TLoFP: you want a signal generator?
11:50 AM TLoFP: cehteh: PWM doesn't work because it needs to run for 10 cycles and then resync
11:50 AM Emil: Or you want to generate edges on some conditions?
11:50 AM TLoFP: and synchronising the avr PWM is a nightmare (google it)
11:50 AM Emil: it's not, realy
11:50 AM cehteh: and your code is buggy in a few lines :D
11:50 AM Emil: there's a global start for the timers
11:51 AM Emil: If you want to use that
11:51 AM TLoFP: Emil: I know, and there is also a synchronize function
11:51 AM TLoFP: but trying to start and stop the PWM timers precesisly is very difficult. and they don't synchronize properly until one or two cycles have passed
11:52 AM TLoFP: now imagine you are driving a 90 amp LED
11:52 AM TLoFP: and you are suposed to generate a 10uS pulse... ten times with a duty cycle of 10%
11:52 AM Emil: eh?
11:52 AM TLoFP: you use the timer and resynchronize. and every now and then the timer gets stuck on
11:52 AM TLoFP: now your LED is fried
11:52 AM Emil: You want to drive leds?
11:52 AM Emil: how the fuck are you frying leds here
11:53 AM TLoFP: if you must know: A laser, a ImageIntensifier, and a CMOS
11:53 AM cehteh: TLoFP: thats rather bugs in your code
11:53 AM TLoFP: cehteh: do you mind telling me where? I did write the code in a hurry but don't see an obvious problem
11:53 AM cehteh: with hardware pwm and proper programming you sould be able to create exact pwm
11:54 AM TLoFP: cehteh: this isn't exact PWM... this is a finite pulse train
11:54 AM cehteh: OR you can do that in software on a dedicated microcontroller, where interrupts are disabled and you handcode every single step
11:54 AM TLoFP: where it an infinite pulse train you would be almost right, except for the need to re-sync
11:54 AM TLoFP: cehteh: it is the handcoding that I am attempting to avoid right now
11:55 AM cehteh: even a finite pulse train can be started / stopped more precisely when you take the strain from the µC
11:56 AM cehteh: one timer for the fast pwm one for the pulse train length
11:56 AM TLoFP: http://www.avrfreaks.net/forum/tut-synchronizing-timers
11:56 AM cehteh: or only one timer altogether
11:56 AM TLoFP: "there are other problems associated with mid-application changes to the timers, but i do not fully understand why they happen, so i dont have a good solution. for example, if one timer uses OCRA as top, and is active but not yet made its first compare match, it will not be able to be synchronized to any other timers using overflow mode. "
11:57 AM TLoFP: that dude sumerizes how to syncrhonize timers and the associated problems
11:57 AM TLoFP: I didn't post about it because I wouldn't be able to add to his post
11:57 AM cehteh: you dont even need them perfectly syncronized, you can mitigate that, as long they are started in deterministic order and kept spinning everything should be fine
11:58 AM TLoFP: cehteh: except the application calls for syncronized signals
11:58 AM TLoFP: and the deterministic order is broken, see above post
11:59 AM cehteh: tldr
11:59 AM TLoFP: TLDR: "there are other problems associated with mid-application changes to the timers, but i do not fully understand why they happen, so i dont have a good solution. for example, if one timer uses OCRA as top, and is active but not yet made its first compare match, it will not be able to be synchronized to any other timers using overflow mode."
11:59 AM cehteh: anyway when you have some risk to fry some expensive leds you want to add some external hardware to protect against errors
11:59 AM TLoFP: point is the PWM timers on the AVR don't work the way you think they should
12:00 PM cehteh: watchdog / AND gate ...
12:00 PM cehteh: how do you know what i think?
12:00 PM TLoFP: yea, all of that is true :D
12:00 PM TLoFP: was hoping to get a software solution today...
12:00 PM TLoFP: and it sounds like I am going to hardcode the timing
12:01 PM Emil: You have?
12:01 PM Emil: Just don't use ISR's where they are not meant to be used
12:01 PM cehteh: yes that might help
12:01 PM TLoFP: Emil: nice statement :-D
12:02 PM cehteh: but really one want to let the hardware to do as much as possible
12:02 PM cehteh: then you have a lot more cycles to do fancy stuff
12:02 PM Emil: Yup
12:02 PM cehteh: and less chances of a programming error frying your leds
12:02 PM Emil: Yup
12:04 PM cehteh: you can always do a pure software solution too, but that needs very static code, least possible branches, only prereserved (global) variables, preferably no function calls
12:04 PM cehteh: etc
12:04 PM cehteh: one error fries the shit
12:04 PM Emil: https://www.youtube.com/watch?v=ttAMZfXpjgw
12:04 PM Emil: Surprisingly catchy
12:04 PM Emil: cehteh: welll
12:04 PM Emil: cehteh: globals only are not really necessary
12:05 PM cehteh: not really
12:05 PM Emil: But for strict timings, yeah, no function calls, no unnecessary branching, ...
12:05 PM cehteh: but for such special purpose things they dont harm
01:33 PM day_ is now known as daey
01:49 PM day_ is now known as daey
02:09 PM Emil: https://www.youtube.com/watch?v=tG0UUdGI01o
02:09 PM Emil: Hooooly shiiit
02:12 PM Thrashbarg: Emil: heh wow
02:14 PM Emil: That was a full story
02:14 PM Emil: a movie
02:14 PM Emil: Like
02:14 PM Thrashbarg: yeah I saw it goes for an hour
02:14 PM Emil: It felt a lot longer than an houtr
02:14 PM Emil: in a GOOD way
02:14 PM Emil: It didn't feel rushed
02:14 PM Emil: it didn't feel like it had filler or unnecessary shit
02:15 PM Emil: it just werks
02:15 PM Thrashbarg: nice
02:56 PM BongoShaftsbury: my parts came in
03:13 PM remkooo1 is now known as remkooo
03:35 PM Emil: Hmm
03:35 PM Emil: I should order
03:36 PM Emil: instead of just waiting around :D
03:50 PM remkooo1 is now known as remkooo
04:06 PM polprog: yeah, i should order pcb and soldermask materials too
04:13 PM Emil: You're going to try that diy soldermask?
04:13 PM Emil: Do share the results
04:13 PM polprog: will probably make a vid
04:14 PM Emil: Nice
06:47 PM JanC is now known as Guest61147
06:47 PM JanC_ is now known as JanC
07:40 PM Chillum is now known as HighInBC
08:46 PM theBear: hehe, no hit wunderbah, i approve that message !
10:20 PM Thrashbarg_ is now known as Thrashbarg
11:39 PM Tachyon` is now known as Tachaway