#avr Logs

Oct 04 2017

12:12 AM rue_house: ooo nice formula
12:18 AM day__ is now known as daey
02:15 AM thardin: Emil_: uhm, the web existed back then too
02:16 AM thardin: but I read up a bit, and it seems there's some better methods for training than backpropagation that were invented quite recently
03:25 AM Emil: thardin: of course it did
03:25 AM Emil: But the state was different
03:26 AM thardin: perhaps toward the general public. within academia I'm not so sure
04:14 AM aarcane: Is there a good set of mutex instructions on AVR?
04:18 AM thardin: not sure if mutex is what you want. but you can use a volatile variable + cli()/sei() to achieve similar things when dealing with interrupts
04:19 AM thardin: unless you're using some OS like FreeRTOS or µC/OS
04:21 AM aarcane: thardin, yeah... what I *want* is for the interrupt to pause until the multi-byte read is completed, then resume... But I suppose I can just let the CPU fire the interrupt when I sei() at the end of the analogue read and that should work
04:23 AM thardin: just cli() until you're done
04:23 AM thardin: multi-byte read.. you're in the middle of say an SPI transfer?
04:24 AM aarcane: thardin, I have one part reading bits and baubles from various pins and ports, including but not limited to analogue reads, and another bit is doing SPI transfer via Interrupt.
04:26 AM thardin: k.. I presume the SPI stuff interferes. in which case temporarily disabling interrupts sounds like the way to go
04:27 AM thardin: of course fixing whatever the issue is might speed things up. letting the ADC and SPI work in paralllell say
04:28 AM aarcane: Just as long as the interrupt doesn't fire while I'm reading 2-3 bytes into my state buffer, leaving a corrupt half-state-1-half-state-2 state, I'm good. I just wish I could trivially wrap that state in a mutex and have it ork as I intend... but alas.
04:29 AM thardin: you can't double-buffer or something?
04:30 AM aarcane: thardin, not with ADC multibyte state.
04:30 AM aarcane: Even if I did double-buffer, whichever buffer I was working in might get corrupt when the in-progress conversion finishes mid-interrupt.
04:30 AM thardin: your ADC is on the SPI bus too?
04:32 AM aarcane: ADC is the internal 10bit/2byte ADC
04:33 AM thardin: hm.. is that one of those 16-bit register dealies? that may require cli/sei around yes
04:33 AM thardin: I forget tbh
04:33 AM aarcane: a pair of L/H registers, but yeah, that.
04:34 AM thardin: alright, then I get the issue. plus the ADC interrupt doesn't help you unless you also put a cli/sei in it to prevent it being preempted by the SPI interrupt
04:34 AM thardin: assuming SPI had higher prio
04:34 AM thardin: or any other interrupt really
04:36 AM thardin: this might actually explain one weird thing I had with one of the 16-bit timers behaving strangely
04:38 AM aarcane: thardin, lol, Have you taken any of the upper division CS courses? I got a lot of these concepts explained there... Concurrency is a big topic when you study algorithms and operating systems...
04:42 AM thardin: I have an MSc in CS so yes
04:43 AM thardin: and I enjoy coding asm for various platforms (6502 woo!). but it's always easy to get tripped up on platform intricasies
05:09 AM aarcane: thardin, fair enough. Congrats! I hope to have the time and money to finish a master's some time before too long
05:16 AM aarcane: I can't use an AVRISPMKII as a debug port in any reasonable way, can I?
05:26 AM Emil: You can if you update the driver
05:26 AM Emil: upgrade the firmware*
05:26 AM aarcane: Emil, got a link to a good example? my google-foo is coming up short.
05:27 AM Emil: No
09:49 AM rue_house: its ok, you can debug anything with an led and otherwise an oscilloscope
09:51 AM Emil: What do you use for mains clearance?
09:54 AM cehteh: iirc there are standards/regulations for that, but if in doubt, just use as much as possible
09:54 AM cehteh: you have a opto? distance of the dil case, one hot one cold side
09:57 AM Emil: standards calculation gives 1.25mm
09:57 AM polprog: that sounds right,
09:57 AM polprog: but yeah, giving more wont hurt
09:58 AM Emil: Whatcha use for connectors?
09:58 AM polprog: iirc terminal blocks have some high standard
09:58 AM polprog: but check that
09:59 AM cehteh: for mains terminal blocks are a good choice yes
09:59 AM cehteh: you come with some biggier wire anyway or?
10:00 AM polprog: mouser says 2.54 pin header has 250vac rating lol
10:00 AM polprog: im doubtful...
10:00 AM polprog: but what do i know
10:00 AM polprog: :P
10:00 AM cehteh: its also a bit about environment, creepage
10:00 AM polprog: yeah, humidity, etc
10:00 AM cehteh: dust, humidty
10:01 AM cehteh: i really prefer the dil case width
10:01 AM cehteh: that makes it clear and is commonly seen this way
10:01 AM polprog: yeah
10:01 AM cehteh: maybe with a PE trace inbetween
10:02 AM polprog: you can even add a cutuout for increased creepage
10:02 AM cehteh: yes
10:03 AM cehteh: note that you dont want to isolate against 230V but against transients
10:03 AM cehteh: which can be a magnitude or more higher
10:03 AM Emil: Yeah I just simulated
10:03 AM Emil: dem transients are pretty reking
10:04 AM Emil: I'm wondering how to protect against those
10:04 AM cehteh: on what side? protect against over arcing or protect the opamp?
10:05 AM cehteh: err opto
10:05 AM polprog: just put transils everywhere
10:05 AM cehteh: good old neon lamp works too
10:06 AM cehteh: and the hint about the PE trace inbetween should help against over-arcing
10:06 AM cehteh: if you have PE there
10:06 AM Emil: cehteh: I have a transformer that I control with relays
10:06 AM Emil: PE?
10:06 AM cehteh: Earth contact
10:06 AM cehteh: grounding whatever is it called english
10:06 AM polprog: do you pay for the components yourself? if not just put transils and varistors wherever possible :P
10:07 AM Emil: https://emil.fi/jako/kuvat/2017-10-04_17-35-41_UfQH5XfM.png
10:07 AM cehteh: high voltage rated caps can also swallow transients
10:07 AM cehteh: you still have the opamp and voltage divider?
10:07 AM cehteh: i thought you gone for my sugggestion
10:08 AM Emil: what was that
10:08 AM polprog: Emil: what exactly am i loking at?
10:08 AM cehteh: the capacitative power supply driving a optocoupler
10:08 AM Emil: polprog: automatic voltage selector for a certain toroidial transformer
10:08 AM polprog: oh
10:08 AM Emil: toroidal*
10:09 AM Emil: cehteh: you posted a falstad link, right?
10:09 AM cehteh: yes
10:10 AM Emil: hmm
10:10 AM Emil: I can't seem to find it
10:11 AM Emil: Was it a shortlink?
10:14 AM Emil: Ah
10:14 AM Emil: it was that rehosted one
10:15 AM Emil: cehteh: is http://lushprojects.com your own?
10:15 AM cehteh: no
10:16 AM Emil: http://lushprojects.com/circuitjs/circuitjs.html?cct=$+0+0.000005+42.05934401203833+50+5+50%0Av+176+384+176+224+0+1+50+230+0+0+0.5%0Ac+128+144+384+144+0+6.8e-8+-84.72575531404287%0Ar+176+384+384+384+0+1000%0Ar+384+144+384+384+0+10000%0Av+80+384+80+224+0+1+60+110+0+0+0.5%0AS+128+144+128+224+0+1+false+0+2%0Aw+144+224+176+224+0%0Aw+112+224+80+224+0%0Aw+176+384+80+384+0%0Ao+0+64+0+4099+320+0.00009765625+0+2+0+3%0Ao+
10:16 AM cehteh: http://tinyurl.com/y7qm4vyk
10:16 AM Emil: 2+64+0+4099+5+0.00625+0+2+2+3%0A
10:16 AM Emil: was it thi?
10:17 AM cehteh: before i sensed only the 50hz for the scope :D
10:17 AM cehteh: you see the phase shift
10:17 AM cehteh: the led on the right is of course the opto
10:18 AM cehteh: on the other side of the opto you can do some integration when you are only interested on the level and not on the phase
10:18 AM Jartza: I made something fun today
10:18 AM Jartza: i2c glitch injector from attiny85 :D
10:20 AM cehteh: the cap needs to be a MKP
10:21 AM cehteh: (or similar X2 rated or whatever thats called, self healing)
10:24 AM Emil: hmm
10:24 AM Emil: It's still annoyingly dropping quite a lot of mw
10:26 AM cehteh: no
10:26 AM cehteh: thats 'blindstrom' how is that called in english?
10:27 AM Emil: ?
10:27 AM cehteh: https://en.wikipedia.org/wiki/AC_power#Reactive_power
10:28 AM Emil: hmm, true
10:30 AM cehteh: such capacitaive power supplies are amazing for very small loads
10:30 AM cehteh: and they are current sources
10:30 AM cehteh: fits perfectly for opto
10:31 AM cehteh: and .. i already saied, you determine the current with the cap only
10:31 AM cehteh: the 220ohms are arbitary just for protection
10:31 AM cehteh: try to change then, you wont notice a change in current unless you choose extreme values
10:31 AM Emil: true
10:31 AM Emil: these seem really interesting
10:32 AM cehteh: but the lower one is important to limit transient spikes and it should blow when the cap goes short
10:32 AM cehteh: (you may/should add a fuse too )
10:33 AM Emil: Yeah there's a global fuse
10:33 AM cehteh: the zener rectifies and swallows excess currents, still it has no much load to handle
10:35 AM cehteh: note that such a power supply depens on sinusodial input .. the cap follows the wave and by that lets current pass
10:36 AM cehteh: so any distortion will generate excess current, you may need to filter the input
10:37 AM cehteh: for example change the inputs to triangle wave then you'll see
10:38 AM cehteh: works still :)
10:39 AM Emil: Hmm, I could add a bead inductor
10:40 AM cehteh: in practice i often seen that left out
10:40 AM cehteh: but wont hurt to add one
10:42 AM Emil: What do you recommend for output stage?
10:42 AM cehteh: no idea, whatever you need
10:42 AM Emil: Just a resistor to ground and read that with ADC?
10:43 AM cehteh: cap for integrating? depends on the opto you use too
10:43 AM cehteh: maybe opamp
10:43 AM cehteh: and / or read it with comparator not adc
10:44 AM cehteh: with some tricks you may even read it directly on digital in, maybe schmitt trigger in front, maybe some sample&hold
10:44 AM cehteh: do you even need a microcontroller? can be done without
10:44 AM cehteh: you configure the main transformer with relays?
10:46 AM Emil: yeah
10:46 AM Emil: well
10:46 AM Emil: I mean
10:46 AM Emil: I could do it without
10:48 AM Emil: There's an appnote about doing just that
10:48 AM cehteh: link?
10:49 AM Emil: https://www.onsemi.com/pub/Collateral/AND8005-D.PDF
10:50 AM cehteh: with transformer :D
10:55 AM cehteh: and dont forget those snubbers, your triacs, relays, SSRs whatever will thank you
04:17 PM polprog: anyone has experience with switching power sources on-the-fly? how do atmegas tolerate that? we're talking about switching Vcc from 3V to 5V and back
04:17 PM polprog: any crucial components etc?
04:26 PM LeoNerd: I expect the ADC won't be too happy in the short term, and if it's one of the chips with a PLL that'll lose lock, but aside that it'll probably be fine
04:26 PM polprog: not using adc really.. ill have to look at the pll, but that thing's not doing any time critical work too
04:27 PM polprog: PLL loosing lock will just introduce jitter on the clock or can it crash the whol mcu?
04:28 PM LeoNerd: Well, what chip and what PLL? E.g. the tiny85 just uses it on one of the timer modules
04:29 PM polprog: m8
04:29 PM polprog: im reading through it's datasheet now
04:29 PM LeoNerd: I don't think that even -has- a PLL
04:29 PM polprog: i dont see that either ;)
04:29 PM LeoNerd: Should be fine then
04:29 PM polprog: allrigght
04:29 PM polprog: thanks ;)
04:31 PM polprog: now if only i had a signal gen i could carry a test of 1000 or so cycles
04:31 PM polprog: i should look around for one - even analog
04:31 PM LeoNerd: Could make one on another AVR
04:31 PM polprog: yeah... but that would be the case of the avr ebay scopes
04:31 PM polprog: lot of mork and miserable effect
04:31 PM LeoNerd: Mmm
04:32 PM polprog: im more for building a small box with a know and a bunch of opapms when i learn the abcs of analog electronics than trying to make a DDS one with AVR :)
04:32 PM polprog: s/know/knob
04:32 PM polprog: that would be cool
04:33 PM polprog: the avr could probably be used there for frequency or parameter display. so a hybrid device with fully analog synthesis and manual or digital pots for adjustment and a small display for freq, offset and vpp readings
04:34 PM polprog: yeah i think i could design one
04:34 PM polprog: say, up to 50 or so mhz
04:34 PM polprog: maybe less
05:13 PM eth3: could anyone please help me with general directions on how to debug randomly hanging atmega?
05:14 PM polprog: any idea why it hangs?
05:14 PM polprog: more debug
05:14 PM Emil: eth3: write data out of uart
05:14 PM polprog: ^^
05:14 PM Emil: in every conditional loop
05:16 PM enh: blink a led
05:16 PM eth3: it's an existing firmware i am using, so i'm not really familiar with all of it
05:16 PM eth3: just investigating
05:16 PM eth3: i have one of those small 128x64 oleds connected to it
05:16 PM eth3: it's a QMK keyboard firmware
05:17 PM eth3: it works fine when on usb, but when i try bluetooth
05:17 PM eth3: it hangs after around 10 keypresses
05:17 PM eth3: sometimes 8, sometimes 21
05:17 PM polprog: i bet it's filling it's buffer
05:17 PM eth3: i'm not typing fast
05:17 PM eth3: just slow single keystrokes
05:18 PM eth3: ah
05:18 PM eth3: also
05:18 PM polprog: doesnt matter, it doesnt send data over BT so the buffer fills
05:18 PM eth3: it hangs when on battery
05:18 PM eth3: works when connected to usb
05:18 PM eth3: (but connected to bluetooth)
05:18 PM eth3: could it be power issues?
05:18 PM eth3: i constantly print out battery voltage to the screen
05:19 PM eth3: so i immediately see when it hangs, as the printout stops fluctuating
05:19 PM Emil: In 99,999999999% of cases where code hangs the issue is pebkac
05:19 PM polprog: try printing the contents of the BT send buffer
05:20 PM eth3: if that's buffer, why would it work when getting power from usb, but not from battery?
05:20 PM Emil: uart is better than led because you get a lot more information out of it quicker compared to leds
05:20 PM polprog: i think it sends via usb? no idea
05:20 PM polprog: yeah uart is just a serial termina;
05:21 PM polprog: terminal*
05:21 PM polprog: you can implement a small printf func and use it as it was a normal C code
05:21 PM eth3: no it sends to bluetooth
05:21 PM polprog: aha
05:21 PM eth3: when connected to usb power
05:21 PM polprog: well, keep diging. print stuff over uart
05:21 PM eth3: but when on battery - it hangs after some time
05:22 PM eth3: yeah i will keep printing, just wanted to know what to do if that's a power issue
05:22 PM polprog: add a cap and filtering
05:23 PM eth3: you mean that could be unstable output from the battery?
05:23 PM enh: no
05:23 PM polprog: i think that the power usage jumps around. a battery cant really have noisy output :P
05:23 PM eth3: than what could the cap/filtering do?
05:23 PM eth3: than=then
05:24 PM enh: when usb is connected it may be using a usb buffer. when on battery it may use another buffer
05:24 PM polprog: short explanation. a battery can be "lagging" if you have peaks in power usage. a cap smooths out the voltage drops
05:24 PM polprog: but im not sure about that
05:25 PM polprog: anyway, a baterry output should not jump around. do you have a meter you can check if it really is?
05:25 PM eth3: it's connected to analog pin, and i constantly print the value out. shows 3.91-3.92V all the time
05:25 PM polprog: that's not bad
05:26 PM polprog: it's ADC's quantization error imo
05:26 PM eth3: don't see any big jumps
05:26 PM polprog: the battery voltage probably is constant
05:26 PM enh: unless he is drainning too much current
05:26 PM eth3: i also saw it slowly going down over time (which is expected), so i believe it's working
05:27 PM enh: which battery is that?
05:27 PM polprog: yeah, but .01 V noise never killed anything, and even if it really is there the decoupling should cancel it
05:27 PM eth3: 2500mah 4.2v lipo
05:30 PM eth3: i think i'll try connecting it to a power bank with usb, no to the computer
05:30 PM eth3: to rule out the buffer thing
05:30 PM eth3: does that make sense?
05:30 PM polprog: no
05:30 PM enh: eth3: I have a blinker code. When debugging i comment most of the code, until the hanging stops. Then I start uncommenting part by part, until the led stops blinking.
05:31 PM enh: extremely boring, but works on many cases
05:32 PM eth3: i think i will resort to that this time, but could anyone enlighten me a bit on what jtag debugging is?
05:32 PM eth3: and what would be the cheapest jtag debugger?
05:32 PM polprog: jtag is a standard of communicating with chips
05:32 PM enh: cheapest usually means bad.
05:33 PM polprog: it defines a very low level protocol
05:33 PM eth3: cheapest not bad?;o)
05:33 PM polprog: on which different vendors build their very own and very different protocols
05:33 PM enh: better use a led
05:33 PM polprog: so the cheapest jtag debugger will be useless
05:34 PM polprog: you need a dedicated debugger for a certain serie of chips
05:34 PM enh: if atmel, try atmel ice with avr studio
05:34 PM enh: if mac, than forget that
05:34 PM polprog: yes. it's better with a led. or a moderate quality usb-uart converter
05:35 PM polprog: i suggest getting one usb-uart, it's very useful
05:35 PM eth3: unfortunately i think the uart is occupied with something else on the board
05:35 PM polprog: as most modern things running embedded os have uart on board
05:35 PM polprog: i dont know the board, it's general advice time now !
05:35 PM eth3: i literally have only 1 pin left free there
05:35 PM eth3: i understand
05:35 PM eth3: but this is why i used the oled screen
05:36 PM polprog: well, bed time.
05:36 PM polprog: good luck
05:36 PM polprog: try to understand what's going on inside
05:36 PM enh: https://pastebin.com/sp3CBsNm
05:37 PM eth3: i will try, thanks and good night
05:37 PM enh: this code works for me
05:37 PM enh: you can say the number of times it should blink
05:38 PM enh: you can place blinking commands all over your code and the number of blinks will tell you where the problem is
05:39 PM eth3: thanks, will try that if the screen approach fails
05:39 PM enh: good luck
05:40 PM eth3: will keep trying once i get back home. thanks everyone!
06:15 PM enh: I 'm getting good attitude data when using only the accelerometer. But when I try to integrate gyroscope data using the direction cosine matrix, everything goes wrong. Not simple.
06:24 PM enh: Is there an easy way to measure a time interval in atmega328p?
06:25 PM Casper: how precise?
06:25 PM enh: As much as possible
06:26 PM enh: ms should be enough
06:26 PM Casper: make an RTC
06:26 PM Casper: use a timer with no prescaller
06:26 PM Casper: each overflow would be 256 cycles
06:27 PM enh: ok. good
06:27 PM Casper: add that to a variable
06:27 PM Casper: each F_CPU cycles is 1 second
06:27 PM enh: thanks, Casper
06:28 PM enh: This way I can keep dt updated
06:28 PM Casper: remember, the biggest variable on avr is an unsigned int 32 bits
06:28 PM enh: ok
06:28 PM Casper: btw, use the prescaller to reduce the cpu usage
06:28 PM LeoNerd: Uhm, I've used uint64_t all the time
06:28 PM Casper: LeoNerd: uint64_t is defined as uint32_t
06:29 PM enh: reaally?
06:29 PM LeoNerd: Uhm I expect it isn't because my code actually works :)
06:30 PM Casper: LeoNerd: using gcc?
06:30 PM enh: Well... I only go upt to uint32_t
06:31 PM LeoNerd: avr-gcc yup
06:32 PM Casper: hmmm
06:32 PM Casper: weird I see it defined...
06:32 PM Casper: I'll have to recheck
06:32 PM LeoNerd: In particular, this line of code: int32_t uV = ((int64_t)value * 40960000) >> 28;
06:33 PM LeoNerd: Could not possibly work as it does for me, if int64_t had only 32 bits, because that would leave only 4 bits of significance after the shift. And I can assure you I get more than 4 bits of resolution out of it :)
06:35 PM Casper: I will check it up
06:35 PM Casper: and if it does work, I'll try it in my ADC routine
06:37 PM Lambda_Aurigae: I think that might have been changed for the better a couple years back...as I recall the uint64_t didn't used to work correctly but was updated to work as it should.
06:38 PM Emil: Casper: was it you who foolishly said that uint64_t was just a alias for uint32_t
06:40 PM LeoNerd: It seems to work just fine for me currently anyway
06:42 PM enh: Not foolish. Just based on not updated information
06:44 PM enh: I believe the correct term is outdated
06:45 PM enh: My english teacher must be turning around in her tomb
06:45 PM Lambda_Aurigae: spinning in her grave
06:45 PM Lambda_Aurigae: that's how we are powering the world these days.
06:46 PM Lambda_Aurigae: Hook a dynamo to dead english teachers and play twitter feeds to them.
06:48 PM enh: Thanks, Lambda_Aurigae
06:49 PM enh: I'll try to find her grave and extract some joules from there.
06:52 PM Lambda_Aurigae: I know my grandmother cringes at my IRC communications.
06:52 PM Lambda_Aurigae: Every time I don't start a sentence with a capital letter or misuse/abuse ...
06:53 PM Lambda_Aurigae: She was a high school English teacher for 35 years.
06:53 PM Lambda_Aurigae: She even corrected and graded my letters to her when I was a little kid.
06:53 PM enh: :)
06:54 PM enh: Grandmas are amazing.
06:54 PM enh: I hope I live enough to see my grandsons
06:54 PM Lambda_Aurigae: I get my grammar-nazi tendencies from her,,,and her ruler.
06:55 PM Lambda_Aurigae: Between the ruler and yardstick I learned a lot.
06:55 PM Lambda_Aurigae: and I would bet lunch on the fact that she never measured anything with either of them.
06:59 PM enh: I had a British english teacher for two years. She taught me more during those years than during all the english course. She gave us *all* possible exercises that were available for our level, made us read a book every week and write about it. It was total hell.
07:15 PM enh: I'm getting around 22msec between information updates on the navigation module.
07:16 PM enh: Is this good enough to fly a slow quadcopter?
07:17 PM enh: cehteh, are you around?
07:18 PM cehteh: enh: yes
07:19 PM cehteh: 22ms ~50hz ..
07:19 PM enh: yep
07:19 PM cehteh: i'd say you want it 20 times faster :D
07:19 PM cehteh: but for a bigger one it may barely work
07:20 PM cehteh: not nice
07:21 PM enh: Communications module efficiency must be improved then
07:21 PM cehteh: the bigger the copter the slower the control loop can be more inertia
07:21 PM Emil: enh: just a guestion
07:21 PM Emil: Have you done any resource analysis on this?
07:21 PM cehteh: learning by doing
07:21 PM enh: Can you please define resource analysis?
07:22 PM cehteh: like backwards riding :)
07:22 PM Emil: cycle budget/time constraints/...
07:22 PM enh: probably not
07:23 PM cehteh: you should put things in different classes with utter priority to keep the damn thing in the air
07:23 PM Emil: It's the first thing anyone should do
07:23 PM cehteh: that is sensors, control loop, accutators
07:23 PM enh: There is space for that, cehteh
07:23 PM enh: I'll work on that
07:23 PM cehteh: everything else (inputs, telemetry, etc) comes 2nd
07:24 PM Emil: Because
07:24 PM Emil: the topology you have
07:24 PM enh: That order of states can be esily configured
07:24 PM Emil: It's not suitable for slow moving things like avrs :D
07:24 PM Emil: Bus designs are not efficient
07:24 PM Emil: Not when externally addressed
07:24 PM cehteh: there where controllers which worked with a single AVR years ago
07:24 PM enh: yep
07:25 PM enh: the current constraint is not on the bus, though
07:25 PM cehteh: but ... yor design is somewhat bloated *cough*
07:25 PM Emil: Correction: bus designs are not efficient relative to your topology and main processing unit
07:26 PM enh: I do not have a main processing unit
07:26 PM enh: processing is distributed
07:26 PM cehteh: having multiple mpus could improve it .. but only if they dont block each other and latencys sum up
07:26 PM enh: well, they do not block each other
07:26 PM cehteh: turn arounds?
07:27 PM cehteh: also communication makes a significant overhead
07:27 PM enh: but only one of them manages bus communications. That is probably what you are talking about
07:27 PM cehteh: i dont know the details, but somewhat it looks like you doing a lot things very inefficient
07:28 PM enh: I'm sure I am
07:28 PM cehteh: remember when i shown you how to optimize stuff
07:28 PM enh: There is a lot of room for improvement
07:28 PM cehteh: with avr's you need to do that on every end just to make it barely useable
07:29 PM enh: I agree, but first I must put the system to work and produce results. Only then I can optimize it efficiently
07:29 PM cehteh: prolly you want different busses .. one communication bus and then dedicated realtime busses ..
07:29 PM enh: I have a limited mind
07:29 PM cehteh: and still make everything as simple as possible
07:30 PM cehteh: usually yes, first make it work, then optimize
07:30 PM enh: I try...
07:30 PM enh: But there is always a lot to learn
07:30 PM enh: I went a long way to reach this point
07:30 PM cehteh: but .. it with hard realtime stuff things just dont work when they dont fit in the timing contraints
07:31 PM enh: see, cehteh. The navigation code is updating 15000 times per second. But it is receiving new info only at 50Hz.
07:32 PM cehteh: navigation does what?
07:32 PM enh: attitude
07:32 PM cehteh: so not navigation but just stabilization
07:32 PM enh: I thought that too, but wikipedia says stabilization is navigation
07:32 PM cehteh: huh?
07:32 PM enh: wait...
07:33 PM cehteh: navigation is waypoint to waypoint etc
07:33 PM cehteh: coordinated flight
07:33 PM cehteh: anyway
07:33 PM enh: https://en.wikipedia.org/wiki/Guidance,_navigation,_and_control
07:33 PM cehteh: stabilization has already multiple components, 3 axis, maybe altitude .. and then inner/outer control loop
07:34 PM cehteh: get these basics working first
07:34 PM cehteh: and you want sensors/control loop/acutators run a) steady and b) fast
07:35 PM cehteh: not as fast as possible, having steady timing is more important
07:35 PM cehteh: like 500hz or 1khz
07:35 PM cehteh: or maybe 400hz, thats what the old ESC's/servos talk
07:35 PM enh: I'm working on attitude calculation, from sensor data. Using this https://www.sparkfun.com/tutorial/news/DCMDraft2.pdf
07:36 PM cehteh: important is that things are in sync and you dont get aliasing errors
07:36 PM cehteh: forget about complex math and such
07:36 PM cehteh: just inner loop to stabilize the thing first
07:36 PM enh: I will probably update servo information at around 50Hz if the communications module stays like this
07:37 PM cehteh: as in when you start the copter from a flat surface it will not wobble
07:37 PM enh: ok
07:37 PM cehteh: 50 hz is way to slow for small copters
07:37 PM cehteh: you need 400hz at least
07:37 PM cehteh: very least
07:37 PM cehteh: 1khz should be better
07:38 PM enh: I'll fix that, including priorities as you suggested
07:38 PM cehteh: and first thing is just the inner loop .. stabilization PID even without attitude/complementary filter/kalman .. only gyro sensor data
07:38 PM cehteh: get that working
07:39 PM cehteh: then you can build on top of that
07:39 PM enh: the only gyro sensor that is the part I'm working on now
07:40 PM enh: integrating gyro data to eliminate drifts is not easy
07:40 PM cehteh: note that sensor/pid/output rate should somehow match (because of aliasing)
07:40 PM cehteh: it doesnt help you when your sensors run at 500hz and your output at 400hz
07:41 PM enh: The paper I linked above describes how to do it with direction cosines matrix
07:41 PM enh: I implemented that, but finding the right parametes for integration and feedback is not easy.
07:41 PM cehteh: of course
07:42 PM cehteh: and that looks like its for a plane
07:42 PM cehteh: copters are more agile and need faster control loops
07:42 PM enh: They tested on a plane, but the matrix is the same
07:42 PM enh: for copters
07:42 PM cehteh: that paper already looks way to complicated for AVR's
07:42 PM enh: the part that changes is the curve compensation feedback
07:43 PM enh: that is what I said before. This code is running at 15000 hz on the avr
07:43 PM enh: using floats...
07:44 PM enh: that module only does that. Calculates this stuff, plus the stabilization stuff and sends servo info out
07:44 PM cehteh: well get the thing flying and see
07:44 PM enh: thanks
07:45 PM enh: And about this link: https://en.wikipedia.org/wiki/Guidance,_navigation,_and_control
07:45 PM enh: I was surprised to learn the definition of navigation there too
09:22 PM Lambda_Aurigae: I wouldn't use an avr for hot feedback aircraft guidance these days. I would go with pic32 myself...or even arm.
09:30 PM absynth is now known as dan2wik
09:37 PM enh: If you do all the work on one mcu, no doubt about it
09:37 PM enh: But in my case, work is distributed
09:38 PM enh: Next gen modules will be stm32f303cc
09:40 PM enh: I have three classes of objects now: bus, modules and submodules. Modules drive submodules. One of the modules controls the bus. The topology is star shaped, communications module in the center.
09:41 PM enh: Each module does a small number of functions, usually related.
09:41 PM enh: I can upgrade any object without affecting the oters
09:41 PM enh: others
09:42 PM enh: No monolithical system permits that, or runs with a simpler code.
09:43 PM enh: Each of my code classes deals with a single problem. They can be debugged in a much simpler way than a complete code would.
09:45 PM enh: But that is my point of view. I built this from zero, HW and SW, they way I believe it should be done.
09:45 PM enh: Making all modules ARM based would be overshooting, for sure
09:50 PM enh: Submodules are designed for specific functions. I have one for all sensors and another for the servo PWM generator. If I wish a different set of sensors, I place them on a submodule, plug them on a module and plug the module on the bus. Communications module will call it, identify whatever the new module is carrying and deal with it.
09:51 PM enh: No other commercial controller is capable of that. Any upgrade on them needs a new HW.