Back
[06:26:06] <carabia> i heard german -- eins zwei polizei, drei vier grenadier, fünf sechs alte hex, sieben acht gute nacht!
[06:33:29] <liwakura> carabia: sollen du kerren nocht?
[06:45:51] <Lambda_Aurigae> alle alle ackbar.
[07:31:18] <eszett> hi
[07:31:57] <eszett> I have a question about soldering tips. How are the tips called that have a little cavity in the middle, where the solder can accumulate?
[07:33:48] <LeoNerd> Possibly "bucket" is a word?
[07:38:37] <Tom_itx> worn out
[07:40:23] <twnqx> eszett: "Hohlkehle", und ich finde sie sinnlos
[07:40:43] <Haohmaru> und wat o_O
[07:41:07] <twnqx> ich habe damit auch nicht mehr erfolg als normal
[07:41:23] <Haohmaru> guys, what do you kinda do when you need to talk to a computer over encrypted tcp socket?
[07:41:50] <twnqx> -lopenssl , -llibresssl, -lgnutls, ...
[07:42:01] <twnqx> after all, NOT use some 8bit micro
[07:42:14] <Haohmaru> i've seen some ethernet modules, just one of them has encryption, and that thing costs a quite a fraction of a kidney
[07:43:08] <twnqx> so... use an arm with embedded ethernet controller that's cheaper than most AVRs?
[07:43:23] <Haohmaru> so you basically move your application from 8bit to full 32bit arm or so?
[07:43:51] <twnqx> with the way AVR/Microchip handle pricing, for sure
[07:44:20] <Haohmaru> that's also the answer i came up with so far, but it's quite a huge jump from 8bit to arm x_x
[07:45:46] <Haohmaru> and i'm not sure about the gnu part of that.. isn't that gpl'ed?
[07:46:54] <Haohmaru> i found a apache-licensed ssl/tls lib suitable for arm (embedTLS), but it still needs the missing parts, like.. tcp ip, and the hardware
[07:47:48] <Haohmaru> i'm currently using xmega plus a module with wiznet w5500 (tcp ip stack with SPI)
[07:48:23] <Tom_itx> avr32 is a lost cause imo
[07:48:41] <LeoNerd> Yah; it's all going ARM at that level
[07:49:07] <Tom_itx> xmega was too late to the game too
[07:49:28] <LeoNerd> xmega has lots of tricks I wish turned up more in the ATmega/ATtiny area though
[07:49:48] <LeoNerd> Like having set/clear registers for ports, or the more orthogonal and neater-mapped hardware
[07:49:53] <Haohmaru> LeoNerd why not use xmega then?
[07:50:08] <LeoNerd> The way that peripheral modules have a base address and parts within that, instead of all being a huge jumbled mess like ATmega
[07:50:10] <Haohmaru> it's very nais ;]
[07:50:43] <LeoNerd> Haohmaru: even the smallest Xmegas are waaaaay larger than most of the stuff I do with tiny chips
[07:51:08] <LeoNerd> E.g. I was just using a tiny85 to drive three LED PWM channels to make a flickering candle effect
[07:51:10] <Haohmaru> something like xmega16a4?
[07:52:09] <LeoNerd> Hmm.. 44pin, so that's comparable to some of the larger ATmegas I might use - like the 328PB or 16U4
[07:53:18] <LeoNerd> Wow, somewhat more analog components too... 12bit ADC, 2 channel 12bit DAC, 2 anacomps
[07:53:39] <LeoNerd> Whothefuck needs *five* UARTs?
[07:53:45] <Haohmaru> i do
[07:54:01] <LeoNerd> And *seven* seriouslyseven SPI controllers?
[07:54:09] <LeoNerd> .. possibly 5 of those 7 are the UART modules
[07:54:17] <Haohmaru> well
[07:54:25] <LeoNerd> Do these have the IO crossbar matrix on them?
[07:54:33] <Haohmaru> port C, D, E..
[07:54:45] <Haohmaru> are digital ports, and they all look pretty much exactly identical
[07:54:59] <LeoNerd> Mm?
[07:55:12] <LeoNerd> I mean, the PIC24-style peripheral<-->GPIO pin switching matrix
[07:55:22] <Haohmaru> you got two UARTs (one on the lower 4 pins, and one on the higher 4 pins) and an SPI module
[07:55:24] <LeoNerd> Where any peripheral function can be mapped to any pin. Rather than begin fixed
[07:55:34] <Haohmaru> each UART can operate in SPI master mode
[07:55:59] <LeoNerd> Ah.. so they're giving you more port modules so hopefully you can find *a* free one somewhere
[07:56:09] <LeoNerd> Yeah; I'd muuuuch prefer a crossbar matrix setup. I hate that Atmel don't do one :(
[07:56:35] <LeoNerd> It's much more flexible and you can do a lot more creative things, like linking periphal units together directly without code
[07:57:05] <Haohmaru> i'm using synchronous uart between two xmegas so i can push the bitrate a lot ;P~
[07:57:53] <LeoNerd> At what point do you decide to use sync. serial instead of SPI though?
[07:58:15] <Haohmaru> i havent done SPI slave, so no idea about that
[07:58:31] <Haohmaru> nor interrupt-based and buffered SPI
[07:58:49] <Haohmaru> yet i already have codez for fully interrupt-driven UART with FIFOs
[07:58:57] * LeoNerd nod
[07:59:54] <Haohmaru> iirc i'm using a bitrate of 460800 or so
[08:00:03] <Haohmaru> no bytes broken ;]
[08:00:16] <LeoNerd> 460k? Meh.. that's slow in SPI terms
[08:00:30] <LeoNerd> It's rare I SPI slower than 2Mbit
[08:00:43] <Haohmaru> yes, but it's currently sent between the two breadboards via a silly long cable
[08:00:48] <LeoNerd> Ah.. :)
[08:00:56] <LeoNerd> Yes, SPI is really best when it doesn't leave the board
[08:01:05] <Haohmaru> yup
[08:01:25] <LeoNerd> I talk SPI to an offboard nRF radio module, but that's only over about 15cm of jumber cable, so that's fine
[08:01:31] <Haohmaru> i wish more chips had synchronous uart like this
[08:03:11] <Haohmaru> actually, one of the best things for the xmega is the datasheet is structured in a different way
[08:03:26] <Haohmaru> a bit confusing at first, but then it's very easy
[08:03:59] <LeoNerd> To be honest, your main noise source in SPI is the capacitive crosstalk from other highspeed digital lines in the area, especially on long parallel cross-board runs
[08:04:15] <LeoNerd> A dedicated jumper cable that comes tangentially off the board can help that a lot
[08:04:29] <Haohmaru> there is one datasheet for the whole bunch of xmegas, explaining the actual peripherals which are common to all chips, and then there is a datasheet for your specific xmega which doesn't explain the modules but only the stuff specific to that chip
[08:04:36] <LeoNerd> Yah
[08:04:42] <LeoNerd> I like that approach. Again I wish the ATmegas did that more
[08:05:00] <LeoNerd> ATmega UARTs, ADCs, SPI/I²C units etc... are all really similar. They coudl save a lot of pages on that
[08:05:05] <LeoNerd> The timers though... eugh :/
[08:05:14] <Haohmaru> i wish too, since i also got a few atmegas and there everything is in random places in one huge datasheet
[08:05:46] <Haohmaru> it's not as bad as microchip datasheets tho ;P~
[08:06:43] <LeoNerd> The trouble I find is that while the other periphs are identical across chips (to the point that they just copypaste the docs, typoes and all), the timers are *so* different between chips, and there's no real summary explaining it
[08:06:57] <LeoNerd> The timer units remain my number one barrier to better code portability between chips
[08:07:17] <LeoNerd> So much so, I made myself a handy little reference chart;
http://go.leonerd.org.uk/avr-timers
[08:09:35] <Haohmaru> well, the other nice thing about xmegas, when you pick say xmega64a4, you can simply recompile your finished code for xmega16a4 and it'll work, the pins and everything is the same, just less flash and RAM
[08:10:38] <Haohmaru> i'm using xmega32a4 and xmega128a3 myself, and they are on the same datasheet regarding modules, so it's the same kinds of timers and stuff
[08:11:22] <Haohmaru> i even made one of my projects (in codeblocks) with targets for those two chips, i can simply change the target and rebuild it for any of those two o_O
[08:11:41] <twnqx> Haohmaru: gnutls -> lgpl
[08:11:58] <twnqx> openssl -> bsd with attribution ("contains traces of openssl")
[08:12:09] <Haohmaru> the only thing that i have to #ifdef is the pin initialization
[08:12:45] <Haohmaru> twnqx how about embedTLS?
[08:13:44] <Haohmaru> ehm, it's actually "mbedTLS"
[08:14:10] <twnqx> no idea
[08:15:40] <Haohmaru> still need an actual tcpip stack and the rest of the "ethernet" x_x
[08:16:05] <Haohmaru> one option is to continue using the wiznet w5500 thing for that
[08:29:57] <eszett> hi twnqx
[08:30:30] <eszett> hat das geklappt mit der bestellung?
[08:35:31] <liwakura> psst
[08:37:03] <bss36504> kre10s__: howdy
[08:37:12] <kre10s__> sup.
[08:37:26] <bss36504> Just read your message from yesterday. Doubles, nice :P
[08:39:31] <bss36504> I was planning to characterize the oven before hand anyway. You can get a pretty good idea of what your PID constants need to be based on the response.
[08:48:59] <cehteh> bss36504: i got best results from cascading pids, keeping temperature in range of a few centigrades
[08:50:46] <bss36504> Hmm. From a controls point of view, why would cascaded PIDs be better than an appropriately tuned single PID?
[08:51:25] * twnqx wonders if cehteh is really working for c't
[08:54:08] <cehteh> because you have different reaction times
[08:54:13] <bss36504> oh wait, did you do something like this?
http://blog.west-cs.com/blog/how-does-cascade-control-work
[08:54:16] <cehteh> moment
[08:54:31] <bss36504> I never learned cascaded controls in school
[08:55:10] <cehteh> twnqx: nope, my initials :D
[08:55:21] <cehteh> bss36504: its quite simple
[08:55:37] <cehteh> you place one temperature sensor at your heating element (or very close)
[08:55:44] <cehteh> and one into the oven
[08:56:22] <cehteh> the pid in the oven regulates the setpoint (temperature) you want at the heating element, which in turn controls the power (pwm)
[08:57:34] <cehteh> because the heating element is considerably fast compared to the oven, its hard to regulate it only with a single control loop
[08:58:01] <bss36504> Ah, that makes sense. How do you tune such a system? I could see how it might be tricky to isolate the individual controllers' responses enough to set your constants.
[08:59:47] <cehteh> yes tuning is a bit tricky, basically you short-circruit the outer loop (or turn it off) and first tune the inner loop (heating element) to get a good response on then manual input changes
[09:00:02] <cehteh> after that you tune the outer control loop
[09:00:19] <cehteh> what kind of oven is that you are planning?
[09:01:10] <cehteh> i only used a PI controller w/o D .. D is only needed when you expect some disturbances (someone opens the door, or you have some phase changes in the material in the oven etc)
[09:02:02] <cehteh> feedforward helps a bit to keep the I term in check, i am planning to extend that too
[09:07:45] <bss36504> Ok, cool. I'll try that. I was going to try and compute the Kp and Ki terms based on the response of the oven, then manually tune it in if need be. So I guess I'd just run with only the heating elements first, get those tuned in then switch on the other controller. Did you feed forward to the input of the heater controller, or directly to the heat
[09:07:45] <bss36504> ing element?
[09:08:35] <cehteh> i have only manual tuning, no math .. and feedforward on both
[09:09:12] <bss36504> I got an inexpensive convection toaster oven. I figured the fan would help evenly spread the heat. Got some nice (read: expensive) insulating pads and tape to seal it up really well. I happened to aquire 6 240VAC 5A SSRs a while back, and now I have a project for them. Granted, I'll probably only use 2.
[09:09:14] <kre10s__> yea. that's what I did. I did do a quick check to ballpark the values though.
[09:09:15] <cehteh> feedforward is autotuing slowly by using the I sum (trying to reduce the I)
[09:09:58] <cehteh> i made a oven for curing epoxy. using a cheap ceramic heater/fan
[09:10:13] <cehteh> needs to run predefined temperature curves
[09:10:24] <cehteh> but 80°C at most
[09:10:34] <bss36504> Oh interesting.
[09:10:51] <cehteh> for ramping the curves i want to add some feedforward someday
[09:11:09] <cehteh> not necessary, but more a excercise to learn about it
[09:11:26] <bss36504> I read somewhere that instead of trying to control DT/dt, it's easier to make a controller that can hold a temperature and then just step the setpoint at the correct rate.
[09:11:58] <cehteh> dunno, just schoolbook PID is somewhat simple enough
[09:12:28] <cehteh> i want to play with some extensions around PID someday, having logarithmic and exponential (or maybe polynormal) factors
[09:12:56] <cehteh> well my first try was w/o cascading which was very hard to tune, reacted slow, overswung etc
[09:13:16] <cehteh> as soon i added the cascade it became much much better
[09:13:38] <cehteh> almost on the first try it kept temperatures betwenn 0.3°C
[09:14:21] <kre10s__> It's much easier to get the oven to heat up than to cool down. so control is always asymetric
[09:14:31] <cehteh> depends
[09:14:43] <cehteh> i condidered to add a servo for venting
[09:14:50] <bss36504> I was thinking the same
[09:14:50] <cehteh> but turned out to be unneccesary
[09:15:20] <cehteh> the asymetric side is less a problem than you think
[09:15:54] <cehteh> i made a cutoff at 40°C when cooling down, the closer you get to ambient the harde it gets to cool down
[09:16:33] <cehteh> but on higher temperatures when you only regulate a fixed or slow moving setpoint just normal PID works well
[09:16:43] <bss36504> Might be an issue if you are trying to match a specific reflow profile. I plan to reflow LEDs and the lenses do not appreciate being too hot for too long. So if necessary, I'll add the door servo.
[09:18:55] <cehteh> just tune the oven not to swing over, then cooling isnt a issue
[09:19:36] <kre10s__> I had the same idea with a vent or forces cooling but also concluded it to be unnecessary. Once you get a feel for how the oven behaves you know what power pulse to apply to achieve the temp spike in the reflow profile.
[09:20:13] <cehteh> i think adding a door servo might complicate things a lot more because that servo likely needs its own PID because it has completely different characteristics than the heater
[09:20:29] <cehteh> if you can, try to avoid that
[09:20:55] <cehteh> at worst you get different control loops fighting each other
[09:21:48] <cehteh> maybe a small, constant airflow with fans helps .. unregulated or manual regulated (just enough to ensure the cooldown speed)
[09:23:53] <kre10s__> lol. I have a door on the oven I open when the control says so.
[09:25:33] <cehteh> lol
[09:28:42] <rue_house> hah, the human is part of the loop
[09:28:57] <bss36504> haha
[09:30:23] <bss36504> I'm very excited that I actually found a use for these SSRs. I tend to collect a lot of random crap with the "I'm sure i can use this for something!" attitude and in this case, it will legitimately save me $30/relay (the one's I have go for $50, but ones I probably would have bought are $30)
[09:32:23] <bss36504> I'm thinking it will be best to just run the convection fan all the time. Does that seem right? I want to "blend the temperature" as best as possible
[09:33:51] <cehteh> http://public.pipapo.org/IMAG0113.JPG powered by tupper :D
[09:34:34] <bss36504> Haha I like it!
[09:35:05] <cehteh> http://public.pipapo.org/IMAG0115.JPG
[09:35:29] <bss36504> I assume thats the controller?
[09:35:35] <cehteh> it has a 3 color led for showing the mode, rotary encoder for standalone operation, and usb console
[09:35:38] <cehteh> yes
[09:35:48] <cehteh> arduino nano and some ssr's
[09:36:20] <cehteh> https://www.amazon.de/gp/product/B003Q9JZHG/ref=oh_aui_search_detailpage?ie=UTF8&psc=1
[09:36:25] <cehteh> using that heater, pimped
[09:37:12] <cehteh> the heating element there are actually 2x 250W .. so i contol each independently with very slow pwm
[09:37:15] <bss36504> Heres what I got:
http://www.walmart.com/ip/Oster-Designed-for-Life-Convection-Toaster-Oven/35609013
[09:37:38] <cehteh> (10seconds cycle, 20ms (mains frequnecy) step)
[09:38:49] <bss36504> I'll chop out the controls and replace them with a small graphical LCD and a rotary encoder and some buttons. I want it to be programmable over USB (send it a list of set points or something) and also programmable on the unit for standalone operation.
[09:39:14] <cehteh> yes i made a small commandline interface
[09:39:29] <cehteh> the rotary encoder is ok for selecting a program and start/stop it
[09:39:38] <cehteh> but for more control one needs to rely on usb
[09:39:50] <cehteh> no lcd .. not necessary
[09:39:58] <cehteh> but a lot blink codes for the RGB led
[09:40:58] <cehteh> i made that program with arduino libs .. my plan is to port it to my own os someday
[09:41:23] <cehteh> http://git.pipapo.org/?p=dinoheat;a=blob;f=Dino.h
[09:42:08] <bss36504> I realize the LCD is pretty unnecessary, but I've been wanting to use one for a legitimate reason. This sort of fits the bill. It would be cool, at the end of reflow, to display the actual temperature overlayed on the programmed profile, to see how well it matched.
[09:43:22] <cehteh> in the long run i want to make a cli with completion and some syntax descriptions which then can be used by the rotary encoder
[09:43:37] <cehteh> then using a lcd makes sense
[09:43:48] <cehteh> building commandline with rotary encoder basically
[09:43:52] <bss36504> For the rotary encoder interface, I was going to get it into a mode where you are programming a profile. Starts in the time axis, turn to the desired number of seconds, click, scroll to desired temperature, and so on until all points have been entered.
[09:43:58] <bss36504> Oh nifty.
[09:44:27] <cehteh> then lcd will make fun
[09:44:39] <bss36504> Overall I prefer standalone operation as opposed to being tethered to a computer. In all likelyhood I'll run one profile frequently, and almost never need anythig different.
[09:44:52] <bss36504> Although a CLI is pretty badass.
[09:45:05] <cehteh> yes, standalone is mandatory for such, but only for basic tasks
[09:45:54] <cehteh> maybe entering a temperature profile .. but things like tuning the pids are prolly better done with laptop attached
[09:46:19] <cehteh> there i have a monitor mode which prints the state every few seconds and lets change all values dynamically and watch
[09:46:43] <bss36504> Oh that is handy
[09:46:53] <bss36504> hmm...I should consider something similar
[09:47:25] <bss36504> It would not be difficult to make a very simple CLI. nothing like what youre planning, but at least something to send data back and forth
[09:51:11] <cehteh> http://muos.pipapo.org/
[09:51:13] <cehteh> btw
[09:51:28] <cehteh> will continue soon on it, very work in progress
[09:57:43] <bss36504> Interesting. Is it real time?
[10:00:59] <cehteh> 'userland' not, drivers should be. for some definitions of realtime
[10:01:07] <cehteh> its not really an OS, more a scheduler
[10:01:16] <cehteh> very lightweight
[10:01:41] <bss36504> Ok, so in order for other tasks to run, the running task must yield?
[10:02:18] <cehteh> there are no tasks
[10:02:45] <cehteh> it schedules functioncalls from queues, this functions are interruptible (usually)
[10:02:49] <cehteh> but dont yield
[10:02:56] <bss36504> Oh ok I see
[10:03:07] <cehteh> there is limited support for yield and wait
[10:03:20] <cehteh> but thats rather discouraged
[10:04:08] <cehteh> if one wants to handle things in realtime he has to add some driver/interrupt code to do the important work, and then queue any processing which is not that important on the work queues
[10:04:35] <cehteh> not having threads is light on memory, it runs in tinys with only 64byte ram
[10:04:36] <bss36504> So how does the user control what functions are being put into the queue? Obviously if a "task" function is running in the one CPU "thread", you cannot simultaneously add new function calls to the queue.
[10:04:49] <bss36504> I use those terms generically
[10:05:08] <bss36504> I realize you didnt actually write the OS with tasks and threads.
[10:05:11] <cehteh> you can always add functions to the queues
[10:05:24] <bss36504> ok gotcha
[10:05:44] <cehteh> and as soon your function returns it schedules the next one (from timer queue or one of the work queues)
[10:06:08] <cehteh> and if no function is pending it puts the mpu into sleep
[10:06:42] <bss36504> That's an odd programming paradigm. Not sure how I'd use that. You're doing some process in your current function, and you can defer subordinate actions until later, by placing the function calls in the queue as opposed to calling them directly
[10:07:03] <cehteh> yes
[10:07:06] <bss36504> Nifty
[10:07:12] <cehteh> event based programming
[10:07:27] <cehteh> one stack to rule them all
[10:08:01] <Haohmaru> the lord of the stacks
[10:08:05] <cehteh> also drivers may put callbacks on the queue, like lineedit on serial, whenever the user completed a line it gets a callback pushed
[10:08:30] <LeoNerd> I don't like a queue. A queue suggests dynamic size.. which doesn't play well on an MCU
[10:08:46] <LeoNerd> I keep a per-task "pending" flag, and that's it. If the task wants more finegrained state within it, it can use static variables
[10:09:03] <LeoNerd> A lot of my tasks end up being TaskRet task_foo(void) { static enum { ... } state; switch(state) { .... } }
[10:10:41] <cehteh> LeoNerd: static queues
[10:11:33] <cehteh> in most cases one would define them very small, 4-8 entries are often enouhg sometimes even less
[10:14:37] <kre10s__> LeoNerd, that is much like a coroutine.
[10:17:17] <cehteh> bbl
[10:29:31] <LeoNerd> kre10s__: mhm
[10:32:32] <kre10s__> In C a method for implementing coroutines is with a state variable and a switch. usually packed into #defines like CR_INT() CR_END() and CR_YIELD()
[10:33:31] <kre10s__> http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
[10:33:40] <kre10s__> It's called a duffs device.
[10:34:44] <kre10s__> I use them to implement user interface routines... blink this led wait for input etc...
[14:25:54] <superware> I need to capture six PWM channels (servo signals, signal between 1ms and 2ms, 400Hz), is there a way to accomplish this accurately with a single AVR?
[14:26:39] <bss36504> Accuracy is relative...
[14:27:11] <bss36504> What do you need to do once you capture the channels?
[14:28:17] <superware> bss36504: please see
http://www.castlecreations.com/support/documents/castle_serial_link_v1.3.pdf
[14:30:45] <superware> bss36504: sorry sorry sorry, wrong link! try
http://www.castlecreations.com/support/documents/castle_link_live_2.0.pdf
[14:32:10] <superware> basically, per channel, detect a primary signal (1-2ms long), measure the time between the end of the primary signal to a very short "tick" pulse that follows.
[14:33:32] <bss36504> So what would be your necessary resolution on the pulse width? You'd basically need 6 pin change interrupts with a free running timer. But at worst case where you got 6 interrupts queued simultaneously, you'd probably be pushing a 1ms lag before servicing the last one.
[14:33:42] <bss36504> And thats not even considering doing anything else.
[14:35:44] <lowin> They could check the status of other pins while servicing first signal, perhaps?
[14:36:29] <bss36504> Good thought. At least then you'd have a constant servicing time.
[14:36:38] <superware> there is plenty of "free" time, problem is handling "worst case" scenarios.
[14:37:14] <bss36504> well lowin had a good thought there. Some hand optimized assembly might be fast enough
[14:38:04] <Jartza> yeah
[14:38:15] <Jartza> just use pin change interrupt for certain port
[14:38:29] <Jartza> they usually share the pin change interrupt routine
[14:38:52] <Jartza> then you can do some port-register magic to capture all port states simultaneously
[14:38:53] <superware> yeah, but what about several changes at once?
[14:39:02] <Jartza> well, PORT is one register
[14:39:14] <Jartza> if you make sure all the captures are in same port, just read one register
[14:39:29] <Jartza> different pins are just bits in that 8-bit value
[14:40:59] <superware> yeah, that's part is simple. so what's minimally needed per channel? storing current_time - start_time?
[14:41:26] <superware> that*
[14:41:45] <bss36504> Sounds about right yeah
[14:41:59] <Jartza> and storing current port-register :)
[14:42:22] <Jartza> then on next pin change you can just xor the new value with old to get changed pins
[14:42:35] <Jartza> pretty straightforward
[14:42:45] <superware> the first thing to do in the interrupt is storing the port-register, so any following changes will trigger the interrupt again...
[14:42:53] <bss36504> You could store the "time stamp" of the interrupt and the new register status in the ISR, then just process it in your free time.
[14:43:09] <Jartza> indeed
[14:43:17] <Jartza> store port-register and timestamp
[14:43:50] <bss36504> That would be a very fast ISR. I assume the time inside it would be shorter than the time getting to it, so that's about as good as you can do I think.
[14:44:00] <superware> the six channels aren't synced...
[14:44:33] <superware> so basically they can all arrive at very short intervals (one after the other)
[14:44:55] <bss36504> What is this god forsaken comm protocol :P
[14:45:06] <Jartza> :D
[14:45:09] <superware> so it will be necessary to store the time_stamp per channel (array)
[14:45:17] <superware> heh
[14:45:38] <superware> ask Castle Creations
[14:45:57] <Jartza> assle creatures
[14:46:05] <bss36504> I used to be a test engineer for a company that made a lot of automotive sensor ICs. All of the test guys hated working on the digital PWM parts, it was such a pain to calculate the value
[14:46:10] <bss36504> Jartza: lolol
[14:46:56] <bss36504> Apparently the auto companies like talking digital over PWM. I think they actually just low pass filtered it, but that is besides the point...
[14:47:53] <bss36504> We actually ended up using on-DIB time measurement chips to accurately measure the PWM timings, though that was more because we were required to test much more accurately than the customers would ever care about. Datasheet specs, ya know?
[14:48:23] <Jartza> I like PDM more than PWM :)
[14:49:32] <superware> how much clocks will it in the interrupt to store time_stamp in an array per relevent pin (should be in a loop...)
[14:49:57] <superware> blah, I hope it's possible to understand :)
[14:51:55] <kre10s__> What does this castle thing do? like what is it used for? why do you need it at all?
[14:53:21] <superware> they sell brushless ESC (Electronic Speed Control)
[14:53:59] <superware> I have six of these, and want all available telemetry, this is their only way.
[14:56:45] <superware> actually the measured time is 5ms which sounds pretty large in order to get a decent resolution...
[14:57:28] <bss36504> Could you just LP filter the PWMs and use the ADC? How often does the "Value" of the PWM signal actually change?
[14:58:12] <superware> not possible, there are actually two PWM signals there, the second one comes 0.5ms after the primary one finish.
[14:59:50] <lowin> I used to have a code that worked. I changed it and now It doesn't :'(
[15:00:32] <superware> if running at 20Mhz and the interrupt takes 40 clocks then the maximum "error" is 2us out of 5ms, which is a resolution of 2500, right?
[15:00:55] <superware> lowin: sounds like the third rule of programming
[15:01:07] <lowin> superware, What's the second?
[15:01:16] <bss36504> "Doctor, it hurts when i do this"
[15:01:36] <superware> yeah, that too
[15:01:52] <superware> although no doctor will help here
[15:02:00] <bss36504> Good point
[15:02:01] <lowin> There was no way the old code could have worked. I swear to god
[15:02:04] <superware> is my calculation right?
[15:02:17] <bss36504> I believe so
[15:03:06] <superware> what's left is to implement the interrupt in 40 clocks...
[15:03:38] <bss36504> Eh, that probably wont be too hard. Write some assembly
[15:03:43] <superware> loop 1-6 channels, for each check state etc..
[15:03:58] <superware> assembly? optimized c works?
[15:04:49] <kre10s__> you can do it in optimized C. you could probably even do it with naked interrupts.
[15:04:52] <Jartza> remember there is also latency to fire the interrup
[15:05:04] <superware> 40/6 is about 6 clocks per channel
[15:05:43] <superware> Jartza: every following latency should cancel each other out, right?
[15:05:44] <bss36504> Well like was suggested, you can read the whole port at once, gain a couple clocks back per channel
[15:05:51] <Jartza> superware: no
[15:05:53] <lowin> You can also forgo using interrupts and just poll the ports
[15:06:00] <Jartza> every interrupt firing has latency
[15:06:08] <lowin> since your mcu won't be doing anything else
[15:06:13] <Jartza> first, the current instruction is ran to finish
[15:06:17] <superware> Jartza: yeah, but the same letency.. ?
[15:06:22] <Jartza> that'll be 1-3 clock cycles
[15:07:10] <Jartza> jumping to interrupt of course takes time too
[15:07:22] <superware> lowin: it should do some other stuff too, like sending the data out (!)
[15:07:51] <superware> probably serial or i2c..
[15:08:06] <lowin> I thought you send it during service routine
[15:08:20] <Jartza> it takes 3 cycles to execute interrupt vector, which is usually rjmp, another 3 clocks
[15:08:37] <superware> but you said pulling
[15:08:47] <Jartza> and usually pcint has some sync latency also, maybe 2 clocks
[15:09:04] <Jartza> so. when pin change happens, pessimistic case is 11 clock cycles before you're in your interrupt vector
[15:09:17] <superware> we said resolution of 2500, I will settle for 250 :)
[15:09:44] <Jartza> and whatever you do you most probably want to save at least SREG in your vector
[15:09:54] <Jartza> AND the return from interrupt vector takes time too
[15:10:48] <superware> wait, to get a resolution of 250, I can have 400 clocks per interrupt!
[15:10:50] <Jartza> reti is 4 cycles (5 on bigger avrs)
[15:11:43] <superware> I think even Visual Basic will be able to do all this in 400 clocks
[15:11:50] <Jartza> superware: well.. you don't want to do anything with the data, do you? :D
[15:12:20] <Jartza> if your interrupt fires 250 times a second and takes 400 cycles, then you'll be only gathering data but have no time to do anything with it
[15:12:32] <superware> like I said, I need to send it out somehow, very slow I guess...
[15:13:02] <superware> I said 400 max, will take less of course
[15:13:22] <Jartza> yeah. but just to remember that interrupt doesn't really fire "immediately"
[15:13:30] <superware> yeah
[15:15:03] <superware> if the measurement per channel is for 5ms with a reslution of 250, it leaves 20*20 cycles
[15:15:06] <Jartza> heh. datasheet says clock synchronization takes 2 clock cycles plus whatever is left of current clock cycle, but not 3 clock cycles
[15:19:14] <superware> f**k, I don't think this protocol works in 400Hz, there's not enough time for 5ms secondary-pulses (!)
[15:19:47] <lowin> damn me. I always thought sbi was 1 clock pulse only
[15:21:08] <Jartza> only on xmega
[15:21:33] <Jartza> oh, sbi... on tinies too, I think
[15:22:22] <Jartza> ahh nope. had to check it. only on "reduced core" tinies
[15:22:28] <Jartza> so attiny 4/5/9/10
[15:23:32] <lowin> Well quick ctrl-f revealed I didn't use it in my time critical section
[15:24:08] <Jartza> heh
[15:24:10] <lowin> Still brings me back to why my code isn't working... i traced it on gdb 2 times even.
[15:24:38] <Jartza> talking about timing critical, ever tried creating vga-picture out of avr? :)
[15:24:52] <lowin> No but It was on my list
[15:25:10] <Jartza> I have, from attiny85
[15:25:30] <Jartza> 32 x 16 characters on screen with UART input @9600bps + parsing subset of ansi-escapes :)
[15:25:31] <lowin> I went with implementing a hardware encryption lock.
[15:26:28] <Jartza> it was fun exercise
[15:26:40] <Jartza> btw. 32*16=512 ;)
[15:27:06] <Jartza> so, using "full sram" for screen buffer
[15:27:43] <lowin> You could try using an sdcard as ram
[15:28:01] <Jartza> too slow
[15:28:26] <lowin> ddr ram?
[15:28:31] <lowin> yeah that's too fast
[15:28:39] <Jartza> heh
[15:29:04] <Jartza> but because VGA itself wasn't timing critical enough, I synced three of attiny85s to create 8-color VGA :)
[15:29:17] <Jartza> each attiny draws it's own color, red, green and blue
[15:29:23] <lowin> cool
[15:30:36] <Jartza> https://www.youtube.com/watch?v=G1QWNDck0yU
[15:30:40] <Jartza> this is what comes out :)
[15:32:37] <Jartza> added bonus: graphics mode (64x56 pixels)
[15:36:35] <lowin> Well firefox wants me to update flash
[15:36:41] <lowin> so I can't see the video
[15:41:36] <bss36504> Oh bastard, that pipe demo :)
[15:45:52] <bss36504> Hey do I need a resistor in series with the SSR control voltage?
[15:57:04] <superware> is there a small hall-effect sensor I can mount around a cable to measure current?
[15:57:38] <bss36504> You'll need a core as well, or you ccan use an integrated current bus sensor.
[15:57:46] <bss36504> How much current are you measuring?
[15:58:07] <twnqx> 100A
[15:58:09] <twnqx> :D
[15:58:18] <bss36504> FWIW I was a test engineer for hall effect current sensors.
[15:58:19] <superware> 50A max
[15:58:27] <bss36504> Check out A758
[15:58:28] <superware> wow
[15:58:36] <bss36504> Allegro Microsystems.
[15:58:55] * twnqx has a few allegros around
[15:59:15] <bss36504> Sorry, that would probably be ACS758
[15:59:41] <bss36504> Uni directional or bidirectional current?
[15:59:52] <superware> something like
https://en.wikipedia.org/wiki/Hall_effect#/media/File:HallEffCurrentSense.jpg ?
[16:00:03] <superware> Uni
[16:00:23] <bss36504> Cores are for squares :P Unless you actually cant break the circuit to insert the sensor.
[16:00:30] <superware> what if I need it around the wire, not through it :)
[16:00:54] <superware> I need a fast patch solution
[16:01:10] <bss36504> Well thats not really how it works...the field doesnt couple that way very well
[16:01:40] <superware> I don't need it that exact, I mean 1-2A resolution would be fine
[16:01:43] <bss36504> so they use concentrator cores like in your link, but you have to loop the wire around the core, not just slip the wire through
[16:02:10] <superware> what do you mean?
[16:02:38] <bss36504> The wire has to be wound around the core in order for the sensor to work. You cant just stick the wire through the core axially
[16:02:53] <bss36504> Not a lot of windings mind you, but at least one.
[16:03:27] <superware> oh I see
[16:03:31] <bss36504> And then you have to characterize the system. Really, honestly, I'd use one with an integrated current bus and not use the core kind.
[16:03:42] <superware> Ok
[16:03:53] <bss36504> the ACS758 would be really easy to solder to, and should support the heat no problem. Downside is it's gigantic.
[16:04:04] <bss36504> (Relatively speaking for integrated circuits)
[16:04:32] <bss36504> If i threw one at you it would hurt haha
[16:05:27] <superware> is it temperature sensitive?
[16:06:11] <bss36504> yeah, if memory serves the 758 is like 3.5% over temp, which is -40-150C
[16:07:51] <superware> so an ATmega328P will be able to measure 6 of these and send the data via it's UART with ease...
[16:08:04] <bss36504> Oh for sure
[16:08:20] <bss36504> They're all analog output
[16:09:02] <superware> what's the maximum current that can go through? I guess it's much more then the measurement max
[16:09:26] <bss36504> 758 is good to 150A. they sell different sensitivities though
[16:09:42] <bss36504> basically 50, 100, 150A, Uni and Bi flavors
[16:09:51] <superware> I see "Overcurrent" is 600-1200 A
[16:10:20] <bss36504> You could also look at the ACS730, which has a 50AB flavor that would be fine to run Uni, you just lose a bit of ADC range (sensitivity goes down)
[16:10:26] <bss36504> yeah those things are mean.
[16:10:56] <bss36504> I think technically we tested them higher, just for funsies in the lab, but they dont explode till like 1500A haha
[16:11:09] <superware> I think sensitivity is important only if you need to integrate current over time
[16:11:11] <bss36504> ATE testing was nowhere near that
[16:12:08] <bss36504> I mean, it all comes down to how much resolution you want. the output is some mv/A so pick what you need. A bidir 5V 150A sensor is going to be 13.33mv/A.
[16:12:46] <bss36504> But if you use a bidirectional sensor and only use half of the rated range, you're cutting your ADC resolution in half, effectively.
[16:12:59] <superware> yeah
[16:13:35] <superware> what's the ADC rate I can expect from atm328p?
[16:13:52] <bss36504> I think it's 14 clocks per conversion.
[16:14:04] <bss36504> plus a little bit extra per to change the channel mux
[16:14:05] <superware> 76.9kSPS
[16:14:57] <superware> 15kSPS at max res, will this be enough to integrate the current over time and have an accurate accumulation?
[16:15:48] <bss36504> I would assume so, but that depends on what you want your total system accuracy to be.
[16:17:07] <superware> ok bss36504, thank you for all the help
[16:17:48] <bss36504> So if youre making 6 samples at a total BW of 15ksps, you get 2.5ksps per channel, which is 1 conversion every 333us. Unless you have some exceptionally fast transients youre trying to catch, you'll probably be fine. and if you are, then a 328 and a 758 are not the best choice
[16:17:53] <bss36504> not a problem
[16:19:16] <superware> bye
[16:22:22] <bss36504> Time to clock out folks, see you later
