i8320更改Limo内核解决电量读不...- 往阿斯顿

当前位置: 编程技术>移动开发

本页文章导读:

▪i8320更改Limo内核解决电量读不出有关问题 i8320更改Limo内核解决电量读不出问题我的小i就是这样的情况，电池电量始终为0，所以不插电开不了机，进系统后立马报电量空自动关机了，所以自己编译了一个内核，使原来已经半砖状.........

▪ 往阿斯顿去阿斯顿爱上大叔爱上的阿斯达啊的阿斯达阿斯达敖德萨爱上撒 ......

▪ Tell， don't ask 准则 Tell， don't ask 原则 Tell， don't ask 原则 Source: http://www.aqee.net/tell-dont-ask/ 非常的明了。今天我又看到一个关于“Tell, Don’t Ask”原则的文章，里面提供了4个关于这个原则的例子，都很.........

[1]i8320更改Limo内核解决电量读不出有关问题

来源: 互联网发布时间: 2014-02-18

i8320更改Limo内核解决电量读不出问题
我的小i就是这样的情况，电池电量始终为0，所以不插电开不了机，进系统后立马报电量空自动关机了，所以自己编译了一个内核，使原来已经半砖状态的手机又起死回生了。

使用了飞人在这个帖子中的刷机模式（谢谢飞人的无私共享）：
http://www.limofans.com/forum.php?mod=viewthread&tid=44056

主要是修改了内核的引导参数，从TF卡第四个分区进行引导：

CONFIG_CMDLINE="root=/dev/mmcblk0p4 rootfstype=ext3 mem=256M rootwait console=ttyS0,38400"

另外修改了电池I2C驱动程序，使电量返回值始终为接近满电状态。修改了文件arch/arm/sleep_charger.c

int sleep_get_max17040_battery_soc(void)
{
    int soc = sleep_max17040_read(REG_SOC); 
    return 95;//soc; 
}

和modules/battery/i2c_drv.c

int get_max17040_battery_soc(void)
{
    int soc = max17040_read(REG_SOC); 
    return 95;//soc>>8; 
}
int get_max17040_battery_precision_soc(void)
{
    int soc = max17040_read(REG_SOC); 
    return 9500;//((soc>>8) *100) + (soc & 0xff)*4/10 ; 
}

还有，如果你进不去刷机模式了，可以尝试先按住三个键，再上电池，我的就只能这样进刷机模式。

那些16G没坏的可以看我这个帖子：
http://www.limofans.com/forum.php?mod=viewthread&tid=652274

另这次编译内核发现个方法，只要在Makefile中加这两句，就可以一次性编译过去，不会报任何错，也不用改代码：

export PRJROOT = ..
export LINUX_VERSION = 2.6.24.7

编译器用的CodeSourcery arm-2008q1-126-arm-none-linux-gnueabi，好像2008q1之后的版本改了什么东西，默认配置下编译都会报错

之前用的那种方式基本上很难进去刷机模式了，现在发现个更好的方法，就是直接装电池，然后很快地按住音量减+拍照+开机，在充电图标出来之前，这样基本上每次都能进去刷机模式了。

[2] 往阿斯顿

来源: 互联网发布时间: 2014-02-18

去阿斯顿
爱上大叔爱上的阿斯达啊的阿斯达阿斯达敖德萨爱上撒

[3] Tell， don't ask 准则

来源: 互联网发布时间: 2014-02-18

Tell， don't ask 原则

Tell， don't ask 原则 Source: http://www.aqee.net/tell-dont-ask/

前些时间我曾经翻译过一篇叫做《这里我说了算！》的文章，里面作者讲述了关于“命令，不要去询问(Tell, Don’t Ask)”原则：

我看到的最多被违反的原则是“命令，不要去询问(Tell, Don’t Ask)”原则。这个原则讲的是，一个对象应该命令其它对象该做什么，而不是去查询其它对象的状态来决定做什么(查询其它对象的状态来决定做什么也被称作‘功能嫉妒（Feature Envy）’)。

这篇文章里有个很生动的例子，我至今记忆犹新：

if (person.getAddress().getCountry() == “Australia”) {

这违反了得墨忒耳定律，因为这个调用者跟Person过于亲密。它知道Person里有一个Address，而Address里还有一个country。它实际上应该写成这样：

if (person.livesIn(“Australia”)) {

非常的明了。今天我又看到一个关于“Tell, Don’t Ask”原则的文章，里面提供了4个关于这个原则的例子，都很有价值。

例一

不好：

<% if current_user.admin? %>
  <%= current_user.admin_welcome_message %>
<% else %>
  <%= current_user.user_welcome_message %>

<% end %>

好：

<%= current_user.welcome_message %>

例二

不好：

def check_for_overheating(system_monitor)

  if system_monitor.temperature > 100
    system_monitor.sound_alarms
  end

end

好：

system_monitor.check_for_overheating

class SystemMonitor
  def check_for_overheating

    if temperature > 100
      sound_alarms
    end
  end

end

例三

不好：

class Post
  def send_to_feed

    if user.is_a?(TwitterUser)
      user.send_to_feed(contents)
    end

  end
end

好：

class Post
  def send_to_feed

    user.send_to_feed(contents)
  end
end

class TwitterUser
  def send_to_feed(contents)

    twitter_client.post_to_feed(contents)
  end
end

class EmailUser
  def send_to_feed(contents)

    # no-op.
  end
end

例四

不好：

def street_name(user)

  if user.address
    user.address.street_name
  else

    'No street name on file'
  end
end

好：

def street_name(user)

  user.address.street_name
end

class User
  def address

    @address || NullAddress.new
  end
end

class NullAddress

  def street_name
    'No street name on file'
  end
end

好的面向对象编程是告诉对象你要做什么，而不是询问对象的状态后根据状态做行动。数据和依赖这些数据的操作都应该属于同一个对象。

命令，不要去询问！