Consider the below case:
A mobile phone is booted. At this moment it can be said that it is in run mode where the power consumption is more.
If no activity is done, after sometime the screen goes dim.
After further inactivity, the screen completely goes off.
Now my question is: can we say that the mobile phone was in standby mode and sleep mode in above steps 2 and 3 respectively?
Another question is, suppose we are playing some music and we leave the mobile like that for sometime. In this case also the mobile phone goes through 2 and 3 steps mentioned above. But the only difference to earlier scenario is that music is being played in the second scenario. In this case, can we say that mobile phone was in standby and sleep mode respectively in 2 & 3 steps when the music is being played.
If no activity is there for Linux, CPUIDLE threads gets scheduled by scheduler as it is the least priority process and it brings the CPU to various low power states, where as other peripheral are governed by various other concepts of OS.
If screen goes dim it can lead to two possibilities :
Partial wake load is help and system is down (some power save)
Linux suspend called (echo mem > /sys/power/stae) and full device is suspended, (huge power saves, as only ddr is active that to in self refreshing mode along with ALWAYS ON module)
So just by seeing you cant say its in sleep or suspend mode, but if say your touch or some activity other then register WAKE UP event brings the screen up, your device was in sleep mode not suspend mode.
WAKE UP events usually are "power on key", alarm, network packet (ie a call or message etc)
And for your second part of question, it belongs to low power audio concept, it varies alot with your device architecture.
Most common in android phones are putting the cpu in 'Low power state' and periodically waking them up to copy the music data to DMA, which can be played.
There are so many concepts used in the scenario you have used varies with OS and architecture and application, I have tried my best to give you a bird's eye view.
Related
What happens if I send an OTA Update and the device is in deep sleep mode? It wakes up immediately, waits for the next wake up and then runs automatically or it does not run at all on it?
Depends a lot on what your device is, how "deep sleep" and wakeup from it is implemented in this device and how it's connected to Internet.
Option 1: no. Most likely the networking hardware is switched off to save power and (if it's really deep sleep) the micro's core is also suspended (i.e. it doesn't execute code). In this state the device couldn't receive any messages from the network.
Option 2: depends on what the device does when it wakes up. If it connects to Internet and connects to AWS IoT and receives the command, then probably yes. This functionality is up to the developer of embedded firmware to design and implement. Otherwise no.
I'm currently working with an application that has branching logic depending on whether a specific USB drive is inserted into the system. It does this by polling all drive letters looking for a path on the root of each drive.
This works for the majority of machines, but often, this application runs on startup with the USB drive inserted. In addition, some machines are especially slow and take a good minute to load the USB drive once Windows boots. In these machines, the code reaches the check of whether this drive exists, it can't find the drive, and the wrong branch is executed.
It could be possible to wait a minute before checking for drives. I'd prefer to have the application wait for all USB devices (or simply only mass storage devices) to load before checking for the drives, or something even more intelligent.
Unfortunately, I am unfamiliar with the methods needed to wait for all USB devices to finish loading, and with the DDK in general. I can see that it's possible to register a window for device notifications with GUID_DEVINTERFACE_USB_DEVICE, possibly receiving messages like DBT_DEVICEARRIVAL, DBT_DEVNODES_CHANGED, and WM_DEVICECHANGE, the distinctions of which I do not know.
However, the USB drive will likely be already inserted and detected (but not having a drive letter) into the system before the program executes. So, registering for all device change notifications would not make sense. If it's possible to identify devices which are inserted but not loaded (possibly with SetupDiEnumDeviceInterfaces) and then register for "loaded" notifications on all of those devices, it might work. I don't have familiarity with any this, so pointers (or sample code) would be extremely helpful.
I don't think you can.
The problem is that you're tyring to distinguish two cases which are not actually distinct, that of plugging in a USB device during boot and plugging it in later.
You have to know that USB is a protocol which requires a non-trivial amount of intelligence in the USB slave devices. They exchange multiple messages with the USB host (i.e. your OS). This exchange isn't instant. For instance, your USB harddrive will need to ask for permission to draw more than 100mA power. To answer that, the power drivers of Windows must be up and running. The phsyical disk can only spin up when the answer arrives.
So, there's a whole message sequence going on, and the drive letter shows up only fairly late. Windows must know how many partitions exist. So during this exchange, new devices are being created all the time.
When you enumerate devices while devices are actively being added, you're really asking for troubles. The SetupDiEnumDeviceInterfaces API doesn't operate on a snapshot (which we know because there's no Close method); you're asking for the N'th device until you get an "no more devices" error an you know N was to big. But when devices are still actively being added, N changes. And I don't see a guarantee that the list order is by age; devices might be added in the middle as well.
I don't think that getting notifications about drivers being installed for newly plugged-in devices would help you much. When you plug in the same device repeatedly, the drivers are usually installed only the first time.
Also, an USB flash drive, although physically looks like one compact device, is represented by at least three PnP devices by Windows: an USB mass storage device (represents the USB endpoint), a disk device (represents the physical disk inside the flash drive) and one or multiple Volume devices (each represents one volume = partition in your case). Drive letters may be assigned to the Volume devices.
What you can possibly do is monitoring the arrival and removal of Volume devices (RegisterDeviceNotification for GUID_DEVINTERFACE_VOLUME) and examining each volume device that arrives (I believe that Setup API allows you to track its "parents" to the USB stack).
In my application a no. of devices (camera, A/D, D/A etc ) are communicating with a server. I have two options for saving power consumptions in a device as not all devices has to work always:
1- Do poling, i.e each device periodically keep on looking at a content of a file where it gets a value for wake or sleep. If it finds wake, then it wakes up and does its job.
In this case actually the device will be sleeping but the driver will be active and poling.
2- Using interrupts, I can awake a device when needed.
I am not able to decide which way to go and why. Can someone please enlighten me in this regard?
Platform: Windows 7, 32 bit, running on Intel Core2Duo
Polling is imprecise by its nature. The higher your target precision gets, the more wasteful the polling becomes. Ideally, you should consider polling only if you cannot do something with interrupts; otherwise, using an interrupt should be preferred.
One exception to this rule is if you would like to "throttle" something intentionally, for example, when you may get several events per second, but you would like to react to only one event per minute. In such cases you often use a combination of polling and interrupts, where an interrupt sets a flag, and polling does the real job, but only when the flag is set.
If your devices are to be woken up periodically, I would go for the polling with the appropriate frequency (which is always easier to setup because it's just looking at a bit). If the waking events are asynchronous, I would rather go for an interrupt-driven architecture, despite the code and electronic overhead.
Well it depends on your hardware and software atchitecture and complexity of software. It is alwasy better to choose interrupt mechanism over polling.
As in polling your controller will be busy continuously polling the hardware to check if desired value is available.
While using interrupt mechanism will free the controller to perform other tasks, and when interrupt arises your ISR can perform task for specific need.
I have a WPF program that communicates with a specialized USB stick that is collecting data (in fact an ANT USB dongle). I noticed that the data collection simply stopped after a few hours. The reason was evident in the windows logs (system) where at the exact time the program stopped getting data, I see:
The system is entering sleep
Sleep Reason: System Idle
Questions
How do I programmatically prevent Windows from going to sleep so that I can continue to gather data?
2. Stepping backwards for the big picuture view... What's going on? Why does the computer going to sleep affect my program? Or is it just affecting the USB stick? Is it necessary to prevent sleep or should I do something else instead?
Einstein's answer is tantalizingly close. I just can't seem to get SetThreadExecutionState working in my C#/WPF program and can't find a lot of examples or discussions of it. Does it need to be called more than once? If so how? Is there a event that I receive that tell me to call it or should I call it every so often (5 minutes?) as suggested in:http://stackoverflow.com/questions/5870280/setthreadexecutionstate-is-not-working-when-called-from-windows-service
For now, I'm just going into ctrl panel -> power options and preventing sleep but it would sure be nice to have an elegant solution. Even on my own computer, I don't want to mess with the sleep settings. It's too hard to remember to set them back again!
You can prevent the computer from entering low power modes (sleep/suspend) by using the SetThreadExecutionState function.
As far as why going into low power mode is interrupting your data collection - well Windows suspends all processes in these modes and USB ports enter low power mode which likely means your USB device will not have power either. It's by design. After all, the whole reason we want our computers to go to sleep is so that the battery is not drained.
You can apply the above responses, o simply you can go in Control Panel -> Power Options and modify the settings, so your system never goes to sleep.
To 1): You can use SystemParametersInfo with one of the power related values on Windows versions less than Vista to turn on/off power savings settings. Starting with Vista, you should register for one of the power events instead, and the OS will notify you when it needs to for the event you request.
To 2): If the OS shuts down, the hardware it's managing shuts down. What else would you expect to happen? If the OS runs the USB device driver, which runs the USB device, what would you think would happen if the OS goes to sleep? The USB device begins running itself instead without the driver?
I have C/Java knowledge but i never understand yet, how some hardwares show there own screens/graphics from poweron stage to user interface (where it never shows linux/unix boot screen nor it shows windows booting screens).
My question is, Compared to VCR/TV digicoders poweron till user interfaces, how its made? Do we use regular linux kernel or is there any special open source framework which allow us to develop such?
Thanks
Many embedded systems use u-boot as a boot loader. U-boot provides the ability to display a "splash" screen while the linux kernel is booting.
A device will start the bootloader right after the CPU comes out of reset (usually milliseconds after power-on at most). The bootloader code can initialize the display and show a splash screen if it wants (in the same way most modern non-embedded Linux distributions have a graphical grub splashscreen). The kernel can avoid changing the display configuration, and on an embedded device the kernel can boot pretty quickly to running userspace (at least an initramfs), which can take over the display and show whatever animation, progress bar, etc until the full UI is ready.
An operating systems such a Windows or Linux are both large and general purpose. They have to initialise themselves and the hardware, which includes interrogating all connected devices for "plug & play". The OS does not know in advance which such devices are connected; it has to "discover" the hardware every time it starts. The connected hardware may even have changed since it last booted.
Embedded systems do not usually have large operating systems (or often do not have an operating system at all), and they usually have very specific hardware known to the system a priori, so do not need to test and determine the correct configuration for such devices. Often also these devices are far simpler, and are often 'on-chip' peripherals.
That said, your PC is capable of instantly displaying a user interface (just not Windows). The BIOS boot process outputs text to the display almost immediately, and the BIOS console is an interactive user interface that starts on request during boot. Also last time I booted MS-DOS on a modern PC, it took only a few seconds to start.
Not all embedded systems start "instant-on", my digital TV PVR even has a progress bar while booting, but being application specific, it still starts far faster than a general purpose computer. My Network Attached Storage (NAS) device which is an embedded system running Linux on the other hand, takes considerable time to boot since among other things, it has to start the file-system, network, USB interfaces, print server, DNLA server, and web-server. In fact many of the things required for a general purpose computer (but it has no display, the UI is presented via the web-server)
Some embedded systems with large operating systems and complex hardware can achieve "instant-on" by never truly switching off, but rather going into a low power mode where the system state is retained in memory while all the high powered devices such as a screen, WiFi, Bluetooth etc. are switched off.