| 00:53.51 | *** join/#edev kergoth (n=kergoth@neutrino.joshua-colp.com) |
| 01:13.43 | *** join/#edev Redhatter (n=vk4fsjl@2001:388:f000:0:0:0:0:279) |
| 01:53.23 | *** join/#edev dijenerate_ (n=dijenera@72.51.69.246) |
| 02:22.02 | *** join/#edev ce_geek (n=ce_geek@c-66-31-5-98.hsd1.nh.comcast.net) |
| 02:22.16 | *** join/#edev Appleman1234 (n=Appleman@131.181.47.2) |
| 02:28.48 | *** join/#edev Appleman1234 (n=Appleman@131.181.47.2) |
| 02:41.54 | *** join/#edev landley (n=landley@CPE0018f8c121d2-CM00195ed9f32a.cpe.net.cable.rogers.com) |
| 02:41.54 | *** mode/#edev [+o landley] by ChanServ |
| 02:48.25 | *** join/#edev wmat_ (n=btraynor@gromit.mixdown.ca) |
| 04:04.19 | *** join/#edev DrZimmerman (n=theo@tbaumgartner.broker.freenet6.net) |
| 04:55.00 | *** join/#edev harpal (n=harpal@121.246.75.165) |
| 05:00.57 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 05:35.50 | *** join/#edev lyakh (n=lyakh@p57BD2949.dip0.t-ipconnect.de) |
| 06:09.14 | methril | morning |
| 06:15.41 | *** join/#edev drath_ (i=vmaster@p5B07EB4D.dip.t-dialin.net) |
| 06:51.10 | *** join/#edev Appleman1234 (n=Appleman@131.181.99.108) |
| 07:18.27 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 07:18.27 | *** join/#edev DrZimmerman (n=theo@tbaumgartner.broker.freenet6.net) [NETSPLIT VICTIM] |
| 07:18.27 | *** join/#edev chouimat|Zzzz (n=dieu@kde/developer/chouinard) [NETSPLIT VICTIM] |
| 07:18.27 | *** join/#edev Sascha (n=sisawess@cssun.rrze.uni-erlangen.de) |
| 07:18.27 | *** join/#edev mpk (i=mp@solute.xen-host.de) [NETSPLIT VICTIM] |
| 07:18.34 | *** join/#edev Appleman1234 (n=Appleman@131.181.99.108) [NETSPLIT VICTIM] |
| 07:18.35 | *** join/#edev Redhatter (n=vk4fsjl@gentoo/developer/redhatter) [NETSPLIT VICTIM] |
| 07:18.35 | *** join/#edev roxfan2 (n=dunno@145.60-136-217.adsl-dyn.isp.belgacom.be) [NETSPLIT VICTIM] |
| 07:26.35 | *** join/#edev [AD]Turbo (n=turbo@host250-0-dynamic.11-87-r.retail.telecomitalia.it) |
| 07:43.43 | [AD]Turbo | yo all |
| 07:48.36 | methril | yo |
| 08:28.13 | *** join/#edev hw__ (n=hw@p578b3905.dip0.t-ipconnect.de) |
| 08:37.00 | *** join/#edev anothermike (n=wittke@130.75.33.77) |
| 08:59.09 | *** join/#edev kees_ (n=kees@fluidwell.xs4all.nl) |
| 08:59.16 | *** join/#edev Mr_Bonga (n=Rui_Silv@194.65.138.120) |
| 09:17.29 | *** join/#edev shaz (i=shazkhan@116.58.110.156) |
| 09:17.37 | shaz | hi guys |
| 09:17.56 | shaz | need some help on makefiles and cross compilation |
| 09:33.24 | *** join/#edev chouimat (n=dieu@r2351064.cidc.net) |
| 10:13.48 | Mr_Bonga | hi |
| 10:14.11 | Mr_Bonga | anuone know a win32 development irc channel ?? |
| 11:56.31 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 11:57.33 | *** join/#edev Redhatter (n=vk4fsjl@gentoo/developer/redhatter) [NETSPLIT VICTIM] |
| 11:57.33 | *** join/#edev roxfan2 (n=dunno@145.60-136-217.adsl-dyn.isp.belgacom.be) [NETSPLIT VICTIM] |
| 12:11.58 | *** join/#edev g1powermac (n=g1powerm@unaffiliated/g1powermac) |
| 12:14.55 | *** join/#edev g1powermac_apl (i=g1powerm@CPE-76-177-156-202.natcky.res.rr.com) |
| 12:51.21 | *** join/#edev GPSFan (n=kenm@12.10.255.246) |
| 12:51.21 | *** mode/#edev [+o GPSFan] by ChanServ |
| 13:23.21 | *** join/#edev harpal_ (n=harpal@122.169.108.195) |
| 13:27.35 | *** join/#edev prpplague (n=dave@mail.americanmicrosystems.com) |
| 13:46.36 | *** join/#edev chouimat|work (n=dieu@209.217.106.98) |
| 14:00.23 | *** join/#edev T0mW (n=Tom@host-66-202-71-238.har.choiceone.net) |
| 14:02.07 | *** join/#edev gandhijee (i=akp@host-66-202-34-165.spr.choiceone.net) |
| 14:07.06 | *** join/#edev T0mW (n=Tom@host-66-202-71-238.har.choiceone.net) |
| 14:21.49 | *** join/#edev CosmicPenguin (n=nobody@163.181.251.103) |
| 14:21.49 | *** mode/#edev [+o CosmicPenguin] by ChanServ |
| 14:47.32 | gandhijee | hey can someone point me to something that can tell me how to query my video card for what vesa modes is supports? |
| 14:50.20 | prpplague | iirc fbset will give you some info |
| 14:50.59 | gandhijee | yeah, but its not enough info |
| 14:51.22 | gandhijee | is there some type vga/vesa register book you guys know about by any chance? |
| 14:51.50 | prpplague | you'd have to ask CosmicPenguin , he's the only one i know that does x86 dev |
| 15:00.08 | CosmicPenguin | http://john.fremlin.de/programs/linux/read-edid/ |
| 15:00.48 | *** join/#edev MothaWork (n=monmotha@mail.forwardengineering.com) |
| 15:05.14 | *** join/#edev Chocobo (n=swinchen@strongbad.eece.maine.edu) |
| 15:10.41 | *** join/#edev sunrunner20 (n=jamesdoe@pool-71-170-109-84.dllstx.fios.verizon.net) |
| 15:23.35 | *** join/#edev T0mW (n=Tom@host-66-202-71-238.har.choiceone.net) |
| 15:41.55 | *** join/#edev linac (n=lin@121.41.49.13) |
| 15:44.20 | *** join/#edev kergoth`work (n=clarson@65.200.49.156) |
| 15:44.47 | kergoth`work | morning |
| 15:45.30 | prpplague | kergoth`work: greetings earthling |
| 15:46.42 | chouimat|work | hi prpplague kergoth`work and the rest of you ladies :) |
| 15:47.17 | prpplague | chouimat|work: greetings |
| 15:47.50 | g1powermac_apl | morning prpplague |
| 15:47.58 | prpplague | g1powermac_apl: greetings |
| 15:48.13 | prpplague | nws - http://thewebsiteisdown.com/ |
| 15:48.25 | prpplague | _not_ work safe |
| 15:48.43 | prpplague | funny as all heck |
| 15:49.38 | chouimat|work | prpplague: yup ... |
| 16:02.08 | g1powermac_apl | prpplague, haha |
| 16:04.44 | g1powermac_apl | well, I wired up the led controller, now I need to write some software to use it :-) |
| 16:06.53 | GPSFan | g1powermac: hey... you get your z2 yet? |
| 16:07.08 | g1powermac_apl | not yet |
| 16:08.24 | GPSFan | ;>( must be going by slow boat... I got jtag working a bit better, I can run blob under openocd, and break into its execution at will. |
| 16:09.01 | g1powermac_apl | heh, more like slow truck from prpplague work |
| 16:09.28 | prpplague | g1powermac_apl: carrier pigeon |
| 16:09.36 | prpplague | g1powermac_apl: i'll check on it today |
| 16:09.42 | g1powermac_apl | alrighty |
| 16:10.34 | prpplague | GPSFan: nice |
| 16:11.34 | GPSFan | prpplague: I found out that if the processor puts itself into deep sleep, jtag don't work no more... all I had to do is not execute that instruction, and resume at the start of normal boot, and up came blob. |
| 16:11.52 | prpplague | ahh |
| 16:11.56 | prpplague | interesting |
| 16:12.37 | GPSFan | it went so far as loading the kernel, but when the kernel turned on the mmu & dcache, jtag flipped out again. but all I need is blob running |
| 16:19.11 | g1powermac_apl | hmm, I wonder if this is going to cause a problem |
| 16:19.43 | g1powermac_apl | the usart in my ds89c430 can do half duplex synchronous serial comms |
| 16:19.49 | *** join/#edev misham (n=mmanulis@207.7.103.130) |
| 16:19.50 | g1powermac_apl | which is what I need for the led controller |
| 16:20.16 | g1powermac_apl | however, the ds89c450 keeps the clock pin for the usart high when not in use |
| 16:20.32 | g1powermac_apl | but in the timing diagram for the led controller, it shows the clock pin low for not in use |
| 16:22.02 | g1powermac_apl | anyone know if that maybe a problem or am I just paranoid? |
| 16:25.15 | MothaWork | g1powermac: depends on the controller, unfortunately |
| 16:25.34 | MothaWork | some really don't care how you idle the clock line (especially SPI devices that are deselected), while others get confused |
| 16:25.59 | MothaWork | I had a hell of a fit dealing with a Playstation Dualshock controller before I discovered that it is very picky about how you idle the clock line |
| 16:26.18 | MothaWork | but at the same time, that is the ONLY SPI (ish) device I've ever dealt with that cared |
| 16:33.43 | g1powermac_PB | ahh, ok |
| 16:33.57 | g1powermac_PB | the device I'm using is the TLC5940 |
| 16:34.18 | g1powermac_PB | I don't see anything in the datasheet that it cares about the clock line, just the timing diagrams |
| 16:42.35 | g1powermac | only really annoying part of the whole thing is that the controller wants the serial data in Big endian form and my ds89c450 transmits the data in little endian |
| 16:50.21 | *** join/#edev dijenerate (n=dijenera@72.51.69.246) |
| 16:52.22 | *** join/#edev bbradley (n=bbradley@78-105-167-16.zone3.bethere.co.uk) |
| 16:54.58 | MothaWork | g1powermac: many SPI controllers have an option to clock data the other way |
| 16:55.00 | MothaWork | but most USARTs won't |
| 17:00.17 | g1powermac | well, the interesting thing is that the datasheet for the ds89c450 specifies that the data bit is placed on the transit pin right before the clock line is pulsed so the receiving device can also use the rising edge which is what I need for the led controller |
| 17:01.08 | g1powermac | so it just comes down to how the led controller behaves with the clock line high when not in use |
| 17:09.08 | *** join/#edev VK4FSJL (n=vk4fsjl@203.94.56.252) |
| 17:29.26 | *** part/#edev Mr_Bonga (n=Rui_Silv@194.65.138.120) |
| 17:56.42 | prpplague | ho ho hum |
| 17:56.52 | prpplague | my jffs2 image is giving me troubles :( |
| 18:17.21 | *** join/#edev dijenerate (n=dijenera@72.51.69.246) |
| 18:24.04 | *** join/#edev dijenerate (n=dijenera@72.51.69.246) |
| 18:37.23 | sunrunner20 | grr |
| 18:41.04 | prpplague | hmm, my hardware based ecc isn't working properly :( |
| 18:43.55 | MothaWork | prpplague: it never seems to |
| 18:44.08 | MothaWork | part of the problem is that there is no standard way of doing the ECC, so everybody invents their own |
| 18:44.14 | prpplague | indeed |
| 18:44.21 | MothaWork | there are some "common" methods, but nothing completely industry standard |
| 18:44.29 | MothaWork | we finally gave up and disabled the hardware ECC on our Atmel ARM |
| 18:44.38 | MothaWork | performance impact doesn't seem too terrible |
| 18:44.48 | MothaWork | JFFS2 (de)compression seems to take more time than ECC |
| 18:45.00 | prpplague | yea, pretty much what i'm seeing as well |
| 18:47.40 | prpplague | solar: ping |
| 18:48.39 | chouimat|work | bricked and fried 2 devices today ... |
| 18:49.40 | MothaWork | ouch |
| 18:49.57 | MothaWork | bricking not so bad since you can normally unbrick |
| 18:50.02 | MothaWork | frying not so good |
| 18:50.26 | chouimat|work | MothaWork: not a good day ... |
| 18:51.05 | chouimat|work | MothaWork: we just asked for a few more devices from the oem |
| 18:51.28 | MothaWork | hopefully the OEM has them |
| 18:51.44 | MothaWork | I've had things go through (and out of) here that are one of 2-4 in existence |
| 18:52.05 | MothaWork | some of my personal projects only have 3 in the world. I tell people who have them that if they break it, they aren't getting another one |
| 18:56.16 | sunrunner20 | MothaWork: interesting, you can fit a PS controler on a par port |
| 18:58.44 | MothaWork | yes |
| 18:58.49 | MothaWork | you just bit bang the serial interface |
| 18:58.53 | MothaWork | people have been doing it for years |
| 19:02.11 | CosmicPenguin | prpplague: ping |
| 19:02.20 | prpplague | CosmicPenguin: pong |
| 19:02.38 | CosmicPenguin | prpplague: on ARM, you can set up an alarm to wake from a suspend to ram, right? |
| 19:03.09 | prpplague | CosmicPenguin: on most arm devices yes, assuming that the RTC is still powered when suspended |
| 19:03.18 | CosmicPenguin | oh, so its RTC |
| 19:03.25 | CosmicPenguin | so you can't do sub-second alarms? |
| 19:04.26 | prpplague | CosmicPenguin: it varies from device to device but the alarm is controlled by the power to the rtc |
| 19:04.42 | MothaWork | if you're waking up and sleeping that fast, it may be just as effective to simply downclock the processor a bunch and turn off everything you can |
| 19:04.54 | prpplague | indeed |
| 19:05.32 | CosmicPenguin | the point is the granulatrity |
| 19:05.45 | MothaWork | depends on the RTC, then |
| 19:05.54 | MothaWork | some are sub-millisecond accurate, while some only count seconds |
| 19:06.04 | prpplague | CosmicPenguin: yea, depends on what features the RTC provides in a suspended state |
| 19:06.22 | MothaWork | in some cases, you may be able to modify the driver to increase accuracy |
| 19:06.28 | prpplague | CosmicPenguin: the s3c24xx only provide .1 second when in suspend |
| 19:06.46 | MothaWork | i.e. increment the counter every several ticks and adjust for when you come out of sleep to set system time properly, vs ticking once/second |
| 19:06.58 | MothaWork | depends on the divider options offered by the hardware |
| 19:07.32 | CosmicPenguin | .1 second sure sounds like sub-second to me |
| 19:07.32 | MothaWork | some are designed to work off of 32.768 or 1.024kHz crystals, so you could set it for the slower XTAL when running on the faster one to increase your resolution by a factor of 32 |
| 19:07.53 | prpplague | CosmicPenguin: thats just because the rtc provides it |
| 19:08.04 | MothaWork | some don't offer any real configuration and just run with the counter incrementing once/second |
| 19:08.10 | prpplague | CosmicPenguin: but not all arm's have rtc's that provide sub-second results |
| 19:08.16 | CosmicPenguin | I know that |
| 19:08.24 | CosmicPenguin | none of this is procesor specific |
| 19:08.52 | MothaWork | you just mean does the API allow one to specify sub-second sleeps? |
| 19:09.06 | prpplague | CosmicPenguin: in general, if the processor has an RTC, and it can be powered while in suspend, then you can use it for a wake up alarm |
| 19:09.07 | CosmicPenguin | The point is that one could find a system with better granularity then seconds |
| 19:09.14 | MothaWork | if it does (it may; I don't know), I certainly wouldn't rely on it being present |
| 19:09.14 | CosmicPenguin | if one looked |
| 19:09.16 | prpplague | CosmicPenguin: indeed |
| 19:09.49 | prpplague | CosmicPenguin: really if you needed that accuracy, my suggestion would be to use an external clock and just trigger a gpio eint for wakeup |
| 19:09.56 | MothaWork | if you need really precise wakeup, it may be worth considering using a separate timer from the RTC or external timer |
| 19:10.07 | prpplague | jinx jinx |
| 19:10.18 | MothaWork | many micros allow an asynchronous clock for a timer or allow you to keep the timers running with the CPU sleeping |
| 19:10.26 | MothaWork | set your options and do an interrupt on compare |
| 19:10.36 | CosmicPenguin | thats the optimal solution |
| 19:10.52 | MothaWork | would sacrifice some power usage to keep the timer on, of course |
| 19:11.02 | CosmicPenguin | but it requires additional hardware - certainly not something that is readily available on commodity hardware |
| 19:11.20 | CosmicPenguin | plus it burns a GPIO in the wakeup domain |
| 19:12.59 | prpplague | CosmicPenguin: i'd ask what you had in mind, but i figure it's an AMD secret |
| 19:15.19 | CosmicPenguin | Not at all |
| 19:15.32 | CosmicPenguin | on x86 we're limited to legacy RTC |
| 19:15.41 | CosmicPenguin | we can't do subsecond wakeups |
| 19:15.45 | CosmicPenguin | This harms OLPC greatly |
| 19:16.07 | prpplague | whys that? |
| 19:16.52 | prpplague | why do you need subsecond wakeups? |
| 19:17.08 | prpplague | or i should say |
| 19:17.23 | prpplague | under what conditions would subsecond wakeups be needed |
| 19:17.40 | MothaWork | CosmicPenguin: if you're on ARM, chances are you have some spare on-board timers with output compare and interrupt functionality |
| 19:17.46 | MothaWork | in most cases, those can be used for wakeup |
| 19:18.00 | MothaWork | only issue is if you can leave them powered when the CPU is sleeping, which you normally can these days |
| 19:18.36 | MothaWork | I'm guessing Linux doesn't support that, but the hardware would |
| 19:18.38 | CosmicPenguin | subsecond wakeups are the cornerstone of a system centered around suspend-to-ram |
| 19:18.52 | CosmicPenguin | cpuidle know how long its going to be until the next timer expires |
| 19:19.01 | CosmicPenguin | but that is never within second tolerances |
| 19:19.25 | MothaWork | I'm not sure I'd call that STR |
| 19:19.30 | MothaWork | certainly not in the PC/ACPI sense |
| 19:20.00 | MothaWork | STR in that sense generally involves freezing all processes due to a user requested long-term suspend with wakeup occuring due to a user event (such as a power button or lid event) |
| 19:20.24 | prpplague | thats my view of it as well |
| 19:20.27 | MothaWork | this sounds like you just want to power down the micro during times in which it would be idle while allowing the rest of the hardware to run normally |
| 19:20.38 | MothaWork | a legitimate thing to do, but I don't think I'd call it STR |
| 19:21.11 | prpplague | CosmicPenguin: most arm cores have an idle state for power management |
| 19:21.23 | prpplague | CosmicPenguin: which does have subsecond alarms |
| 19:21.30 | CosmicPenguin | We're talking far more deep then an idle state |
| 19:21.44 | CosmicPenguin | any time you put the ram into refresh, its suspend to ram |
| 19:21.56 | CosmicPenguin | it is a mistake to assume that suspend to ram needs to be such an in depth process |
| 19:22.08 | CosmicPenguin | a common mistake, but a mistake all the same |
| 19:22.27 | MothaWork | it's an issue of semantics |
| 19:22.29 | prpplague | CosmicPenguin: sorry, i'm not understanding |
| 19:22.54 | MothaWork | Suspend to RAM to 99% of people means freezing everything, dumping all you can to RAM, and powering down everything possible, leaving the RAM to refresh itself |
| 19:23.12 | prpplague | agrees with MothaWork |
| 19:23.17 | MothaWork | I'd argue that, given that, if you are not powering down most of the system for an extended "hold everything in RAM" state, it's not "Suspend to RAM" |
| 19:23.25 | MothaWork | it's simply "yet another agressive power saving mode" |
| 19:23.41 | MothaWork | I'm not saying what you propose isn't a valid thing to do |
| 19:24.06 | MothaWork | I'd just argue that calling it "Suspend to RAM" is possibly non-productive at minimum, and outright incorrect terminology at the worst, given existing usage |
| 19:24.20 | CosmicPenguin | How can it not be suspend to ram? |
| 19:24.22 | CosmicPenguin | thats what it is |
| 19:24.33 | CosmicPenguin | I don't give a damn for what some corporation may have corrupted it into |
| 19:24.51 | MothaWork | this isn't some corporation, this is a consortium of several corporations, I think including AMD |
| 19:24.58 | MothaWork | are you maintaining the state of the CPU registers? |
| 19:25.01 | CosmicPenguin | I can't call it anything less then what it is - turning off all active power rails and leaving the RAM in self refresh is suspend to ram |
| 19:25.05 | CosmicPenguin | thats the definition |
| 19:25.23 | prpplague | CosmicPenguin: agreed on that |
| 19:25.33 | MothaWork | that may be, but it's far from common usage |
| 19:25.40 | prpplague | CosmicPenguin: but what does having rtc alarms have to do with that? |
| 19:25.43 | CosmicPenguin | That sounds like a you problem |
| 19:26.08 | prpplague | CosmicPenguin: i think we are probably running into a x86 vs. arm way of doing things issue |
| 19:26.37 | CosmicPenguin | prpplague: RTC is the only wake timer we have on regular hardware |
| 19:26.57 | CosmicPenguin | actually, we might have the ACPI timer.... |
| 19:27.11 | prpplague | CosmicPenguin: right, but i'm not understanding what applications/events you'd need subsecond alarms for |
| 19:27.27 | MothaWork | prpplague: I see what he's trying to do |
| 19:27.34 | prpplague | MothaWork: explain it to me then |
| 19:27.46 | CosmicPenguin | actually not |
| 19:27.54 | MothaWork | the idea is that there's an "extended" (>1sec) period coming up during which the scheduler knows that, barring an interrupt, nothing is going to be scheduled |
| 19:28.41 | MothaWork | however, the scheduler knows that something will be scheduled some time from now, and it needs to schedule it to start with better than 1 sec accuracy |
| 19:28.41 | prpplague | and for that period it wants to suspend to ram and wake up when the next event needs to happen |
| 19:28.50 | MothaWork | he wants to shut off the CPU (or at least stop clocking it, possibly retaining registers) and have a timer wake the system back up when something is scheduled ot happen |
| 19:29.01 | MothaWork | prpplague: yes, I'm just not clear what he means by "suspend to ram" |
| 19:29.10 | CosmicPenguin | no, the processor has to go off |
| 19:29.14 | MothaWork | if he means doing it in the ACPI/PC sense, the STR process itself takes more than a single second |
| 19:29.15 | CosmicPenguin | That rail is just too expensive |
| 19:29.34 | MothaWork | CosmicPenguin: so you will be dumping all the registers into RAM during this process? |
| 19:29.40 | MothaWork | the CPU will be cold booting, as far as it is concerned? |
| 19:29.46 | CosmicPenguin | yes |
| 19:30.18 | MothaWork | I think you're going to find that for normal usage, the act of restoring all the registers, the MMU, all the peripheral states, and the loss of the cache will outweigh the benefits of turning the thing off for a couple seconds |
| 19:30.32 | prpplague | exactly |
| 19:30.34 | MothaWork | probably better to just stop clocking it (maintaining registers) and wake it up later |
| 19:30.39 | CosmicPenguin | testing has not shown that to be accurate |
| 19:30.48 | MothaWork | I'm, frankly, amazed at that |
| 19:30.49 | prpplague | CosmicPenguin: which is why most arm cores have two additional power modes, idle and slow |
| 19:30.57 | CosmicPenguin | with a 250ms resume, the value of suspending far outweighs a typical CPU halt |
| 19:31.08 | MothaWork | then I'd say your micro sucks :) |
| 19:31.13 | MothaWork | too much leakage |
| 19:31.28 | CosmicPenguin | of course it does, but I have to work with what is given me |
| 19:31.35 | MothaWork | that includes the effects of losing cache? |
| 19:31.56 | MothaWork | since that will result in a flurry of IO activity that could quite possibly have been prevented if the cache was maintained |
| 19:31.59 | MothaWork | IO sucks juice |
| 19:32.10 | CosmicPenguin | Most of the I/O wouldn't be cached anyway |
| 19:32.14 | prpplague | CosmicPenguin: "idle mode" is more of what you are descibing in the arm world |
| 19:32.25 | MothaWork | I'm talking IO to RAM, just toggling all those IO lines isn't cheap |
| 19:32.34 | CosmicPenguin | cpu halt is fine, but the rails are staying on |
| 19:32.34 | *** join/#edev flavioribeiro (n=flavio@services.mopa.tv) |
| 19:32.35 | MothaWork | yeah, I've never seen this done in the ARM world |
| 19:32.47 | prpplague | MothaWork: you've never used idle mode? |
| 19:32.50 | MothaWork | most ARMs are low enough leakage that people just stop the clock (entirely), holding static state |
| 19:32.56 | prpplague | we use it for alot of our data collectors |
| 19:33.02 | MothaWork | prpplague: no, I've never seen short power down/restore state from RAM done on an ARM |
| 19:33.10 | prpplague | MothaWork: oh, right |
| 19:33.33 | CosmicPenguin | And I think, regardless of leakage, STR can still be to your advantage |
| 19:33.45 | MothaWork | for really long suspends (several seconds or more), I could see that |
| 19:33.46 | CosmicPenguin | You might need to have a longer sleep period to see the benefits, but they will be there |
| 19:34.16 | prpplague | CosmicPenguin: yea, again, what you are describing is called "idle mode" for most arm SoC's |
| 19:34.20 | MothaWork | but for several seconds of suspend, the accuracy of the clock matters less: wake it up the nearest second early, do restore housekeeping, hold in idle mode until the process unblocks, then schedule normally |
| 19:34.33 | MothaWork | s/accuracy/precision/ |
| 19:34.39 | MothaWork | purl: shut up |
| 19:34.40 | purl | shutting up now, master mothawork |
| 19:35.08 | MothaWork | wow, does that actually work? |
| 19:35.11 | MothaWork | s/wow/woah/ |
| 19:35.14 | MothaWork | apparently not |
| 19:36.42 | chouimat|work | hehe |
| 19:38.04 | prpplague | CosmicPenguin: http://www.pastebin.ca/1082153 |
| 19:38.21 | prpplague | CosmicPenguin: thats a description of the 4 operating modes that are generally available on most arm SoC's |
| 19:38.57 | CosmicPenguin | yeah, idle is S1 |
| 19:41.55 | prpplague | CosmicPenguin: so in general for subsecond power savings, arm generally goes to either idle or slow modes, any longer than a couple seconds and we do a full sleep mode |
| 19:42.29 | MothaWork | you can couple full sleep mode with turning off everything and putting the DRAM into self refresh to get very close to the "STR" you described |
| 19:43.21 | MothaWork | in many micros, you can leave certain onboard peripherals (e.g. a Timer) running off some slow clock to serve as a wakeup source |
| 19:43.32 | MothaWork | full blown timers can have sub microsecond precision |
| 19:44.42 | MothaWork | at room temp, on the ARM9 I'm currently working with, at 500Hz (but still running), Icc(core) is 248uA |
| 19:44.47 | MothaWork | that's respectable |
| 19:44.47 | ds2 | or use an RTC source as the wake up then just into full coma |
| 19:45.16 | MothaWork | chuck it into shutdown mode (maintain state only) and you can drop it to 3.4uA for the whole micro (room temp) |
| 19:45.38 | MothaWork | (Shutdown == Sleep) |
| 19:46.03 | prpplague | MothaWork: 500Hz or 500mHz ? |
| 19:46.31 | MothaWork | 500Hz, according to the spec |
| 19:46.38 | MothaWork | "Quasi Static" operation |
| 19:46.43 | prpplague | ahh |
| 19:47.00 | MothaWork | so very slow, but enough to still run and react in software to things, rather than a full wakeup (with latency) from an interrupt |
| 19:47.13 | MothaWork | basically, you can lower the latency to come up and turn the PLLs back on |
| 19:47.28 | MothaWork | I only mention it because it's in my spec table |
| 19:47.32 | prpplague | MothaWork: yea we don't drop any lower that 12mhz since that is our primary clock |
| 19:47.57 | MothaWork | prpplague: you can go very low on this by clocking the micro with a divider off the "slow clock" (RTC clock) or by setting the divider on a PLL |
| 19:48.07 | MothaWork | of course, in the latter, you have to keep the PLL turned on |
| 19:49.49 | MothaWork | the maximum divider for slow clock operation (32.768kHz clock) is 64, giving a 512Hz CPU clock |
| 19:49.51 | MothaWork | that's slow :) |
| 19:50.59 | MothaWork | you can probably go slower by using a PLL, but I'm guessing the power the PLL sucks to do it outweighs the further savings on the micro |
| 20:06.23 | ds2 | just use an OMAP... they support an off mode 0Hz! |
| 20:13.16 | prpplague | is worn out today |
| 20:13.58 | prpplague | 18 work days of 10 hours with no lunch |
| 20:14.37 | Tom_itx | either self employed or way too dedicated |
| 20:15.59 | prpplague | the latter |
| 20:37.01 | MothaWork | ds2: I'm pretty sure this ARM allows static operation, they just don't characterize it |
| 20:38.07 | prpplague | lordy lordy lordy |
| 20:38.38 | prpplague | solar: ping |
| 21:28.28 | *** join/#edev ce_geek (n=ce_geek@c-66-31-5-98.hsd1.nh.comcast.net) |
| 21:28.42 | ce_geek | prpplague: Howdy. Any luck |
| 21:28.45 | ce_geek | prpplague: ? |
| 21:28.51 | prpplague | ce_geek: on what? |
| 21:28.58 | ce_geek | prpplague: The kit |
| 21:29.22 | prpplague | ce_geek: ahh sorry no, i've have been completely swampped and haven't seen or spoke with the boss for about a week |
| 21:29.28 | ce_geek | prpplague: ok |
| 21:29.30 | prpplague | ce_geek: i'll try to get to him as soon as i can |
| 21:29.39 | ce_geek | prpplague: Okie doke. |
| 21:30.01 | ce_geek | prpplague: Just let me know, email is best. Once I know that it's on its way I'll place the digikey order for the prototyping stuff I need to work with it. |
| 21:30.13 | prpplague | ce_geek: sorry but this 8050 is top priority, everything else is secondary for another 2-3 weeks |
| 21:30.28 | ce_geek | prpplague: That's okay, I understand |
| 21:31.16 | ce_geek | Well, off to Maine. Have a good weekend folks! |
| 21:32.11 | prpplague | ce_geek: later bud |
| 21:32.49 | g1powermac_apl | woot, woot, I got my ds89c450 to talk with the led controller |
| 21:33.01 | g1powermac_apl | forgot how much he loved doing this stuff |
| 21:33.23 | g1powermac_apl | its been about two years since I've done any actual microcontroller programming and circuitry |
| 21:47.03 | prpplague | ho ho hum |
| 21:58.18 | *** join/#edev CosmicPenguin (n=nobody@163.181.251.103) |
| 21:58.18 | *** mode/#edev [+o CosmicPenguin] by ChanServ |
| 23:24.51 | *** join/#edev prpplague (n=dave123_@ppp-70-244-80-20.dsl.rcsntx.swbell.net) |
| 23:24.56 | prpplague | solar ping |
| 23:26.37 | g1powermac_apl | ponders how he can switch endianess of bytes without individually accessing each bit. . . |
| 23:31.46 | CosmicPenguin | bswap.. |
| 23:31.55 | CosmicPenguin | runs |
| 23:32.52 | g1powermac_apl | heh |
| 23:33.07 | g1powermac_apl | the swap instruction only swaps nibbles on the 8051 |
| 23:39.59 | CosmicPenguin | hmmm - xch then? |
| 23:50.38 | CosmicPenguin | g1powermac_apl: this is a good page for ideas |
| 23:50.40 | CosmicPenguin | http://www.8052.com/codelib.phtml |
| 23:51.14 | g1powermac_apl | cool, thanks |