| 00:44.12 | *** join/#edev kaio (~kaio@27-33-161-52.static.tpgi.com.au) |
| 00:44.12 | *** join/#edev kaio (~kaio@fedora/kaio) |
| 01:31.10 | *** join/#edev RobotGuy (~n7pkt@c-24-21-60-205.hsd1.or.comcast.net) |
| 01:34.27 | *** join/#edev Mirell (~mmiller@cpe-72-177-94-129.austin.res.rr.com) |
| 01:34.27 | *** mode/#edev [+o Mirell] by ChanServ |
| 01:42.20 | *** join/#edev ZeZu (null@c-98-227-57-88.hsd1.in.comcast.net) |
| 01:42.56 | Pada---- | ciao |
| 01:51.16 | Mirell | I see. |
| 02:37.48 | *** join/#edev MonMotha (~monmotha@2002:6c47:d23b:1:224:7eff:fedc:893e) |
| 02:49.37 | *** join/#edev yermandu (~yermandu@unaffiliated/yermandu) |
| 02:51.39 | *** join/#edev djerome (~djerome@ip24-251-138-141.ph.ph.cox.net) |
| 03:04.03 | *** join/#edev edboogie2011 (~Edward_Ki@pool-108-41-60-162.nycmny.fios.verizon.net) |
| 03:04.18 | edboogie2011 | anybody have experience using a real time operating system? |
| 03:05.00 | edboogie2011 | generally speaking, how do you set priorities for critical subroutines, like drivers involving bit banging, that require all processor time, basicly I DON'T want task/thread scheduling to happen during execution of a section of code |
| 03:05.16 | MonMotha | edboogie2011: use a timer and a lock of some kind |
| 03:05.48 | MonMotha | block the process until the timer expires, then unblock it and force it to run (e.g. force a context switch and ensure it's the highest priority unblocked process) from the ISR |
| 03:06.17 | MonMotha | many systems actually have one timer that's fairly high resolution managed by a process that schedules completion handlers into it |
| 03:06.57 | MonMotha | that process will usually mask the ISR when nothing is scheduled and/or dynamically adjust the frequency of the timer to minimize CPU overhead while providing the necessary precision |
| 03:07.09 | edboogie2011 | MonMotha: is there some keyword or chapter I should read up in my real time operating system's manual that you can recommend? |
| 03:07.21 | edboogie2011 | I am new at this.. and I forgot to take a OS class in college |
| 03:07.39 | MonMotha | edboogie2011: well, do you understand the concept of blocking/locks and interrupts? |
| 03:07.53 | edboogie2011 | blocking locks, you mean semaphores, mutexes? |
| 03:07.58 | MonMotha | yeah things like that |
| 03:08.05 | edboogie2011 | yes i use them to lock resources for my threads |
| 03:08.15 | edboogie2011 | i don't use interrupts much |
| 03:08.29 | edboogie2011 | I am using a cortex m3 LPC1768 philips |
| 03:08.32 | edboogie2011 | ARM |
| 03:08.45 | edboogie2011 | with a KEIL RL-ARM OS |
| 03:09.22 | MonMotha | you'll have to read up on how your OS and hardware handle interrupt service routines |
| 03:09.43 | edboogie2011 | what kind of hardware timer were you referring to, is there a special name for it? |
| 03:10.11 | MonMotha | basically, what you'll do is start your action, schedule a hardware timer to expire when you want the next action to occur, then cause the process to block itself (e.g. down a semaphore that's at zero). The ISR will then unblock the process when the timer expires. |
| 03:10.50 | MonMotha | edboogie2011: most ARM MCUs contain several timers as IO peripherals. They're not part of the CPU core itself but rather some integrated peripheral (a peripheral that's on chip) wired up to the ARM's IRQ line. |
| 03:11.16 | MonMotha | unfortunately, they call them different things. Some just call them "timers" |
| 03:12.42 | MonMotha | they're also often used for PWM generation |
| 03:13.16 | edboogie2011 | is this technique you describe the only way to do it, or the common technique programmers do? |
| 03:13.45 | edboogie2011 | I understand the technique though.. just want to see what I am getting myself into before I flesh it out |
| 03:13.54 | MonMotha | there are other ways to do it, but this seems like a common thing |
| 03:14.21 | MonMotha | especially if you have pre-emptive scheduling with support for blocked processes |
| 03:14.39 | edboogie2011 | what does it mean for a process to be blocked? |
| 03:14.42 | MonMotha | if your OS doesn't support blocking a process, then you have to do other things like make the "process" re-entrant |
| 03:15.16 | MonMotha | a blocked process is waiting on some other "thing" to happen before it's elegible to be scheduled. E.g. it's waiting on file IO, a signal, lock (mutex or semaphore), etc. |
| 03:15.17 | edboogie2011 | danm I gotta read my OS book, I need to do some research |
| 03:15.33 | edboogie2011 | ahh okay, yeah i am familiar with that |
| 03:15.34 | MonMotha | looks like your LPC probably has something called a "repetitive interval timer", which may be useful for this, btw |
| 03:15.43 | edboogie2011 | ahh yes it does |
| 03:16.12 | MonMotha | your CPU may also have an OS "tick" timer that you can leverage for this, but it's probably used by your OS's scheduler and may be difficult to futz with |
| 03:16.40 | edboogie2011 | the "system tick" timer right? |
| 03:16.46 | MonMotha | that appears to be what they call it, yes |
| 03:17.29 | MonMotha | also, you'd use this timer for things you actually need to time out (bit banging would be a good example). If you're waiting on something in hardware to complete (e.g. a SPI or UART transfer), you should use the completion interrupt for that hardware |
| 03:17.37 | MonMotha | you might also look into DMA for those examples |
| 03:17.57 | MonMotha | getting high performance out of modern microcontrollers pretty much requires extensive use of DMA and timer interrupts |
| 03:18.04 | MonMotha | especially if you want low power consumption |
| 03:18.16 | edboogie2011 | ahh yes I would agree with that |
| 03:18.37 | MonMotha | most modern high performance MCUs can actually completely halt the CPU core while allowing (several!) DMA transfers to proceed |
| 03:18.40 | edboogie2011 | my APP is a wired ethernet device so I avoided interrupt use with more processes/threads |
| 03:19.44 | *** join/#edev Mirell (~mmiller@cpe-72-177-94-129.austin.res.rr.com) |
| 03:19.52 | *** mode/#edev [+o Mirell] by ChanServ |
| 03:20.00 | edboogie2011 | MonMotha: how does that work? how is memory access continued while the CPU is halted? |
| 03:21.34 | MonMotha | edboogie2011: most modern ARMs and similar have a multilayer switch in them to grant access between memory, peripherals, and the CPU. The peripherals can DMA directly to/from memory without intervention of the CPU. |
| 03:21.57 | MonMotha | and, due to the multi-layer switch, several such DMA transfers can potentially be going on at the same time |
| 03:22.21 | MonMotha | a lot of these CPUs have like 2-4 separate RAMs just to provide multiple targets for simultaneous DMA |
| 03:22.27 | edboogie2011 | well yeah because each peripheral probably has its own little core |
| 03:22.56 | MonMotha | the peripherals don't have CPUs on them, but they have a simple little DMA controller that knows how to move data to/from the peripheral and RAM |
| 03:23.21 | MonMotha | it's basically just a handshake on the "done" line from the peripheral to a counter and state machine that cycles access to/from the RAM |
| 04:08.04 | *** join/#edev n17ikh (~n17ikh@c-174-56-150-44.hsd1.sc.comcast.net) |
| 05:49.36 | *** join/#edev edboogie2011 (~Edward_Ki@pool-108-41-60-162.nycmny.fios.verizon.net) |
| 05:51.15 | *** join/#edev mbuf (~user@nat/redhat/x-edotqvdivbcemjjf) |
| 06:17.23 | *** join/#edev edboogie2011 (~Edward_Ki@pool-108-41-60-162.nycmny.fios.verizon.net) |
| 06:32.23 | *** join/#edev spk_ (~tomas@ip-86-49-117-106.net.upcbroadband.cz) |
| 07:07.59 | *** join/#edev Mirell (~mmiller@cpe-72-177-94-129.austin.res.rr.com) |
| 07:07.59 | *** mode/#edev [+o Mirell] by ChanServ |
| 07:23.39 | *** join/#edev jevin (~jevin@ec2-174-129-222-35.compute-1.amazonaws.com) |
| 07:28.30 | *** join/#edev kaio (~kaio@fedora/kaio) |
| 07:30.41 | *** join/#edev risca (~risca@h241n2-n-a31.ias.bredband.telia.com) |
| 07:37.06 | *** join/#edev kirabo (~kirabo@LCaen-156-54-47-233.w80-11.abo.wanadoo.fr) |
| 07:39.30 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 07:54.07 | *** join/#edev vanner[work] (~vannerwor@nat.rnd.stcnet.ru) |
| 07:54.46 | *** part/#edev Guest64034 (~vannerwor@nat.rnd.stcnet.ru) |
| 08:05.58 | *** join/#edev vanner_ (~vannerwor@195.208.175.17) |
| 08:06.49 | *** join/#edev scanlime (~scanlime@adsl-76-254-37-10.dsl.pltn13.sbcglobal.net) |
| 08:44.42 | *** join/#edev florian_kc (~fuchs@port-217-146-132-69.static.qsc.de) |
| 08:44.47 | *** join/#edev florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 10:29.19 | *** join/#edev edboogie2011 (~Edward_Ki@pool-108-41-60-162.nycmny.fios.verizon.net) |
| 10:47.46 | *** join/#edev vanner (~vannerwor@nat.rnd.stcnet.ru) |
| 11:13.04 | *** join/#edev risca (~risca@norr-133-207.eduroam.liu.se) |
| 11:53.33 | *** join/#edev bsdfox (~h36sa@unaffiliated/bsdfox) |
| 12:14.55 | *** join/#edev gigigi (~gigigi@212-198-248-35.rev.numericable.fr) |
| 12:42.52 | *** join/#edev dijenerate (~dijenerat@66.54.118.89) |
| 12:46.04 | *** join/#edev dijenerate (~dijenerat@66.54.118.89) |
| 13:14.28 | *** join/#edev MonMotha (~monmotha@2002:6c47:d23b:1:224:7eff:fedc:893e) |
| 13:21.05 | *** join/#edev bsdfox (~h36sa@c-98-238-207-83.hsd1.ca.comcast.net) |
| 13:21.05 | *** join/#edev bsdfox (~h36sa@unaffiliated/bsdfox) |
| 13:40.08 | *** join/#edev dijenerate (~dijenerat@173.225.251.175) |
| 13:51.17 | *** join/#edev kirabo (~kirabo@LCaen-156-54-47-233.w80-11.abo.wanadoo.fr) |
| 14:01.26 | *** join/#edev kergoth (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 14:02.36 | *** join/#edev kergoth (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 14:16.00 | *** join/#edev sndcrb (~sndcrb@dsl-hkibrasgw2-fef8de00-126.dhcp.inet.fi) |
| 14:17.09 | *** join/#edev jevin (~jevin@ec2-174-129-222-35.compute-1.amazonaws.com) |
| 14:24.49 | *** join/#edev CosmicPenguin (~nobody@soa.codeaurora.org) |
| 14:24.49 | *** mode/#edev [+o CosmicPenguin] by ChanServ |
| 15:08.08 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 15:24.44 | *** join/#edev bsdfox (~h36sa@c-98-238-207-83.hsd1.ca.comcast.net) |
| 15:24.47 | *** join/#edev bsdfox (~h36sa@unaffiliated/bsdfox) |
| 15:42.53 | *** join/#edev prpplague (~danders@nat/ti/x-ajxbztdewenxnebe) |
| 16:03.04 | *** join/#edev vanner (~vanner@195.91.241.19) |
| 16:34.42 | *** join/#edev landley (~landley@140.242.26.81) |
| 16:34.47 | *** mode/#edev [+o landley] by ChanServ |
| 16:35.11 | landley | Morning. |
| 16:35.54 | *** join/#edev dijenerate (~dijenerat@173.225.251.175) |
| 16:40.36 | *** join/#edev kergoth (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 16:53.31 | *** join/#edev kergoth (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 17:32.16 | *** join/#edev ZeZu (~null@c-98-227-57-88.hsd1.in.comcast.net) |
| 17:45.30 | *** join/#edev wing0 (~trowa@187.39.190.167) |
| 17:54.58 | *** join/#edev dijenerate (~dijenerat@173.225.251.175) |
| 17:58.05 | *** join/#edev Mirell (~mmiller@64.245.52.2) |
| 17:58.05 | *** mode/#edev [+o Mirell] by ChanServ |
| 18:11.56 | *** join/#edev miltonm (~miltonm@32.97.110.51) |
| 18:18.27 | Mirell | http://yfrog.com/gyp1wvbj |
| 18:21.34 | roxfan | ? |
| 18:29.58 | *** join/#edev edboogie2011 (~Edward_Ki@pool-108-41-60-162.nycmny.fios.verizon.net) |
| 18:32.28 | Mirell | MARU |
| 18:32.32 | Mirell | IN BOOK FORM |
| 18:36.48 | roxfan | and what's maru? (beside that cat) |
| 18:38.58 | *** join/#edev florian (~fuchs@sign-4db6b559.pool.mediaWays.net) |
| 18:38.58 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 18:41.06 | Mirell | ... |
| 18:41.13 | Mirell | http://sisinmaru.blog17.fc2.com/ |
| 18:42.44 | roxfan | ok so it is a cat |
| 18:44.28 | Mirell | Yep. |
| 19:13.38 | *** join/#edev Nu^253r (~LessIsMor@unaffiliated/nu253r/x-0655220) |
| 19:29.20 | *** join/#edev miltonm (~miltonm@32.97.110.51) |
| 19:41.21 | *** join/#edev Mirell (~mmiller@64.245.52.2) |
| 19:41.22 | *** mode/#edev [+o Mirell] by ChanServ |
| 19:47.43 | *** join/#edev risca (~risca@130.236.226.181) |
| 19:47.57 | *** mode/#edev [+o prpplague] by ChanServ |
| 20:15.54 | *** join/#edev kergoth (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 20:21.43 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 20:57.43 | *** join/#edev dijenerate (~dijenerat@173.225.251.175) |
| 21:19.05 | *** join/#edev miltonm (~miltonm@32.97.110.51) |
| 22:07.23 | *** join/#edev itdnhr (~itdnhr@rrcs-184-74-86-235.nys.biz.rr.com) |
| 22:07.34 | *** join/#edev itdnhr (~itdnhr@rrcs-184-74-86-235.nys.biz.rr.com) |
| 22:36.33 | *** join/#edev wing0 (~trowa@187.39.190.167) |
| 23:14.50 | *** join/#edev kergoth_ (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 23:30.53 | *** join/#edev miltonm (~miltonm@32.97.110.51) |