精华内容
下载资源
问答
  • MSP430远程升级解决方案

    千次阅读 2019-01-06 20:59:06
    有没有普通用户就可操作的固件升级方案呢?就像BootLoader,可通过命令选择启动方式,甚至实现远程升级?答案是有的。其原理就是通过FLASH操作,将新的固件刷到FLASH中去,然后转到固件起始地址运行。 MSP430串口...

    MSP430系列单片机常用的程序下载方式为JTAG、BSL,实际产品应用中会用到固件的升级,如果是异地设备,则给升级带来不少麻烦。有没有普通用户就可操作的固件升级方案呢?就像BootLoader,可通过命令选择启动方式,甚至实现远程升级?答案是有的。其原理就是通过FLASH操作,将新的固件刷到FLASH中去,然后转到固件起始地址运行。

    MSP430串口升级程序

    MSP430 FLASH ROM

    1. 如下图所示, 如下图所示, 如下图所示, FLASH ROM为 32K 字节(FLASH大小要根据你用的具体型号做调整),分为 64 个段,每个段分为512字节,512字节又细分为 8个块 ,每块64字节。
    2. MSP430F247每次最小可擦除1个段的空间,除操作是向该写满 0XFF。
    3. 32K字节的 FLASH ROM起始地址为 0X0FFFF –0X080000,对应Segment0 – Segment63.
    4. RST复位中断向量地址为0x0FFFE,其由编译器自动写入跳转到main()函数的指令。

    中断向量

    当有外部复位、软件复位等,都会触发名为Reset的不可屏蔽中断,此时MCU会自动将中断向量0xFFFE装入PC指针,从而引导程序运行。

    除了Reset中断,还有其它例如UART、SPI、TIMER等中断,中断向量记录了中断子程序的入口地址,中断向量表如下:

    存储空间划分

    增加串口升级功能需要有该部分程序支撑,因此FLASH ROM被划分成两部分:引导分区、应用分区,引导分区运行bootloader,当需更新代码时,该部分程序会读取串口发送的程序文件,并将其下载到应用分区;应用分区用于存放应用程序。

    具体分区见下图:

     

    这里系统分区占了1.5KB的空间,其中包括了bootloader代码分区和中断向量分区。应用程序分区也包括代码区和中断向量区两部分,但这里的中断向量却是虚拟中断向量,原因:中断向量表不能重新映射。

    具体实现

    程序更新步骤:1、设备上电; 2、运行bootloader程序; 3、延时等待远程升级命令;4、收到更新命令进入升级功能;5、将应用分区擦除;6、将接收的程序写入应用分区;7、跳转PC指针到应用程序的复位地址;8、运行新的应用程序。

    程序运行的步骤: 1、设备上电; 2、运行bootloader程序; 3、延时等待远程升级命令;4、接收命令超时;5、判断应用分区是否有可运行的程序;6、跳转PC指针到应用程序的复位地址;7、运行应用程序。(如果没有可运行的程序、则一直停留在bootloader)

    关键技术:

    1、通过移动PC指针实现了bootloader到应用程序的切换、同时也实现了虚拟中断向量表。

    2、通过FLASH ROM的读写操作实现应用程序的更新

    总结

    顺利实现MSP430的远程升级,这里我要感谢梁先生的网络资料。其实,只要单片机有FLASH的读写接口,就能根据此原理实现bootloader,同时接口也不局限与串口,只要有机制获取新程序,就可以通过这种方式实现对MCU的升级。

    如果需要技术合作可联系 QQ:1174316744

     

     

    展开全文
  • 在物联网开发中,OTA升级(firmware update Over The Air)是模组必备的功能,本文将以RTL8711、乐鑫8266 、庆科3186 wifi模块为例介绍几种的常见的... RTL8711 ota升级方案 方案简介 8711flash分区如下图:  ...

    在物联网开发中,OTA升级(firmware update Over The Air)是模组必备的功能,本文将以RTL8711、乐鑫8266 、庆科3186 wifi模块为例介绍几种的常见的ota方案,并进行对比总结。

     

                                           RTL8711 ota升级方案

    方案简介

    8711flash分区如下图:

                                                

     

    RTL 8711AF flash分为bootloader、校验信息区、系统信息区、默认固件区,可升级固件区,用户区,默认固件区存放通过烧录方式更新的固件,可升级固件区存放通过ota升级方式更新的固件。这两个区只有可升级固件区是可以用于ota升级的。ota固件升级其实就是IAP(In ApplicationProgramming)应用编程,一般包含两个程序:Bootloader程序和APP程序。以RTL8711AF为例,芯片上电后固定从Bootloader启动。

     

    Bootloader主要负责:

    (1)读取每个区应用程序签名信息;

    (2)判断应用程序该从哪个区启动;

    (3)把对应的falsh区的应用程序拷贝到SRAM,跳转到SRAM运行应用程序。

    APP程序负责:

    (1)定期发送http请求向服务器获取最新固件信息;

    (2)和当前固件对比,确定是否需要更新,如果需要更新从服务器下载最新固件到用于ota的flash区;

    (3)更新flash区签名,软件复位。

     

    固件下载的过程中会对固件进行校验检查以确认下载的固件是完整正确的包。

     

    8711 bootloader 程序流程如下图,从系统参数中获取到两个存固件的flash区的地址后,去读取这两个区的签名,在看哪个区的签名是“81958711”便从哪个区启动。

                                             

     

    8711 ota APP程序流程图下图,从系统参数获取了可升级区的地址后,去擦除该区,再从服务器下载新的固件写到flash去,最后对该区签名进行更新,并把另一区的签名也更新。

                                               

                                    

     

    8711  ota方案优缺点

    8711ota方案把flash分成两个区,一个区固定用于烧录,一个区用于ota升级,比较简单,容易实现;缺点是产品出厂后,若某次ota升级过程断电或断网升级失败flash被破坏,再次上电只能跑另一个烧录区固件,即出厂时烧录的第一个固件版本,无法跑上一个版本。

     

    那能不能两个区都用于ota升级,这次升级A区下次升级B区,交替升级,当升级失败跑另一个区?此时就是上一个版本了。可以,需要重新设计整个方案。

     

    固定一个区烧录一个区ota升级这样实现起来简单,若设计成两个区交替升级是否可以?比较复杂,原因是:

    1、不同区的固件编译条件是不同的,编译时要设置相应flash区的起始地址和大小,所以生成的固件也不同,发布版本时需要发布两个固件。       

    2、如果要设计成两个区都可ota升级,需要有系统信息记录目前程序跑的分区,ota升级时先获取目前程序跑在哪个区,再从服务器下载另一个区对应的固件,bootloader启动时也需要知道应该从哪个区去启动,比较繁琐。

                                      

     

                                        乐鑫ESP8266 ota方案

    方案简介

    乐鑫方案采用的就是上文说的双区交替升级方案,下图为乐鑫8266 flash分区图,分区1和分区2都是可以进行ota升级的。

                                          

     

    系统参数区存储了一个标志位,标识系统起来后应该去跑哪个区(即图中user1.bin或user2.bin)。系统启动时先去运行boot,boot读取该标志位,然后再到对应的区去读取固件运行。

     

    举个例子,初始状态运行版本V0.1的user1.bin,系统参数区标志位为使用user1.bin。当需要升级时,上传V0.2版本的固件suer1.bin和user2.bin到云端服务器,ESP8266 wifi板执行升级时,先读取系统标志位,确定当前用的是user1.bin,然后从服务器端下载user2.bin存储到分区2,如果user2.bin是正确无误的固件,且下载成功,修改系统参数区标志位为分区2然后重启。重启后首先去读取该标志位,读到是分区2,然后从分区2启动。

     

     如果下载固件过程中断网或断电造成下载失败,则系统再次启动时,分区标志位为使用user1.bin,此时跑的就是上一个版本,而不是出厂时的第一个版本。

     

    乐鑫方案优缺点

    乐鑫方案的优点是可以实现升级失败时回到上一个版本,而不是回到第一个版本。缺点就是每次发布版本要同时发布两个升级文件,有点繁琐,万一发布错了,user1.bin和user2.bin搞反了,导致某次升级下载的升级文件与分区不匹配,那wifi板就直接变砖头了没有挽救的余地。

                                      

     

                                                   庆科EMW3165方案

    方案简介

    庆科方案不但解决了升级失败时无法回到上一版本的问题,还很简单。跟上述一样分为bootloader和app程序,不一样的是固件启动运行时步骤稍有不同。

     

    同样在APP程序中发起HTTP请求查询服务器是否有新的固件版本并进行下载,并固定存储到片外的flash区、修改固件的参数信息、重启。重启后做的第一件事是去检查固件参数信息,是否有新的固件?若有将片外flash区的固件搬运到片内flash区,跳转到那里运行。

     

    庆科3165的flash区域规划如下图:

     

                                    

     

    Bootloader放置在片内Flash的0x08000000地址,大小为64K,设备上电后首先跳到这里执行;

    Application放置在片内Flash的0x08010000地址;PARAMETER_1和PARAMETER_2(备份用)记录固件参数信息的区域,它们放在片外Flash;

    OTA_TEMP区域为OTA固件存储区域,放在片外Flash,Application从网络下载bin文件然后写到该区域,而Bootloader从这个区域搬运固件到Application区域。

    升级过程:

    (1)Application查询服务器是否有新的固件需要下载,若有下载到OTA_TEMP区;

    (2)修改PARAMETER_1参数,记录固件信息;

    (3)重启

    (4)Bootloader读取PARAMETER_1参数,判断OTA_TEMP区是否有新固件需要更新;

    (5)若有把OTA_TEMP区的固件搬运到内置flash区;

    (6)跳转到Application程序去执行。

     

    庆科方案优缺点

    优点很明显了,这种方式既保证了升级过程失败再次上电跑的是上一版本,又很简单,发版本时只需发一个固件就好不像乐鑫那么复杂。

    聪明之处在于分开两个flash区,一个专门用于下载存储固件,另一个专门运行程序。这样就避免了发版本时要发两个固件,又避免了上电启动需要判断从哪个区去启动。下载固件过程若断电下载失败,再次启动先去读取固件参数,发现没有新版本,那此时跑原来片内flash的固件即上一版本固件。

    缺点暂时没有发现,可能是上电后需要去搬运固件时间会稍微长一点?古北的模块用的也是这种方案,从使用体验上来看并没有明显感觉时间长。

                                                                                

    如果你觉得本篇不错,如上图,转起来~

    展开全文
  • 基于WiFi和云端的无线远程升级方案

    千次阅读 2018-08-15 00:07:30
    基于WiFi和云端完成无线远程对产品WiFi固件和MCU固件分别进行升级刷新,当产品售出后需要维护时,该方法具有较强实际意义。  总体方案 利用机智云云端OTA技术+产品主控MCU(STM32)的IAP功能来实现。  具体实现...

    关键词:OTA,IAP

      方案目标

    基于WiFi和云端完成无线远程对产品WiFi固件MCU固件分别进行升级刷新,当产品售出后需要维护时,该方法具有较强实际意义。

      总体方案

    利用机智云云端OTA技术+产品主控MCU(STM32)的IAP功能来实现。

      具体实现

    1、WiFi固件升级

    包含:添加固件、验证固件、添加规则、开始推送、推送完成。首先产品连上云端,在云端产品操作界面选择固件升级(OTA)——WiFi,添加固件(下载官方最新的,采用SOC方案可以自己更改固件内容),填好信息,然后进行固件验证,查询MAC后输入进行验证和推送直到成功刷新固件,然后产品会自动重连云端正常工作,用户端无需任何操作。若选择静默升级则自动进行全部过程,手动升级需要APP端点击确认。

    注意:

    1、该固件软件版本号要比目前产品WiFi固件版本号高才能升级;

    2、推送固件过程中要保证网络稳定通畅,设备连接稳定,正常情况下推送还是挺快的。

    2、MCU固件升级

    云端OTA操作同1,选择固件升级(OTA)——MCU即可;

    MCU(STM32)上采用IAP(在应用编程)方式实现功能。先通过板子上的boot引脚将其设置为IAP启动模式,然后进行程序上的修改,添加远程升级功能。

    思路:将MCU(STM32)的flash分成四个区域,地址由小到大分别为:bootloader、flag、app、app_bak四个区域。(具体分区大小由板子flash大小决定)

    bootloader:存储bootloader固件,MCU 上电后首先运行该固件。

    flag:存储有关升级的相关标志位,bootloader和app分区都需要操作该区域。

    app :存储用户程序固件。

    app_bak :临时存储云端下发的新固件,升级固件的一个过渡存储区。

    按思路,编写bootloader和app两部分工程程序.

    bootloader 的主要职能是在有升级任务(无升级任务时运行目前app区域里的程序)的时候将app_bak 分区里面的固件拷贝到 app 区域.这期间需要做很多工作,比如升级失败的容错等等。需要注意的是,在校验 MD5 正确后开始搬运固件数据期间,MCU 出现故障(包括突然断电),MCU 应发生复位操作(flag区域数据未破坏),复位后重新开始执行 bootloader,从而避免 MCU 刷成板砖。

    bootloader工程配置,需要配置好下载到flash哪部分区域,(和预先分配的分区|程序里写的一致)要使flash烧写有效,然后使用link(J|STlink)先将bootloader部分烧写到MCU里。

    app部分,在要添加远程升级功能的工程程序里,添加接收云端新固件功能的部分程序即可。具体需要添加flash区域配置、MD5校验、OTA功能代码(在原product、protocol相关文件里添加OTA有关代码)等。

    注意:

    1、STM32中断向量地址偏移默认0x00,需要根据app实际分配地址进行修改,否则bootloader运行后无法跳转到实际的app处运行主体程序;

    2、实际分区以及数据、环形缓冲区等的大小,要根据固件(bin文件)和MCU的flash实际大小进行合理分配。

    app工程配置,同bootloader,配置好实际下载的flash区域,同时通过配置生成bin文件,然后通过link把app部分程序也烧录到MCU里。重启MCU可以看到程序正常运行。

    接下来更改app部分程序,生成最新的bin文件,上传到云端进行OTA,更新后产品端同样自动重连云端正常工作,执行更新后的功能程序,即实现了远程升级。(OTA过程注意事项同WiFi固件升级)

    验证结果

    1、    按上述方案编写bootloader和app工程并生成可执行文件;

    2、    将bootloader和app的可执行文件烧录到MCU中;

    3、    仅用移动电源对MCU(及WiFi)进行供电,即与PC机无任何有线连接,通过上述方案进行无线远程升级,可以通过云端或移动端APP监察到WiFi固件和MCU固件版本号发生更新改变,观察到产品具体功能改变(改进),说明升级成功。

     

    GitHub:

                OTA:https://github.com/666DZY666/OTA

                 IOT :https://github.com/666DZY666/Internet-of-Things-IOT

    公众号:https://mp.weixin.qq.com/s/iJK5W-Xg6Kr5XG-fkjUUiw

    展开全文
  • 自动增量升级方案的设计及实现

    千次阅读 2014-11-27 21:19:35
    除了文件同步外,能否自定义某些脚本,在升级时自动执行。 如果发现升级后的版本有问题,能否快速回滚到原来的版本。 写作目的: 以SVN为例子,学会基于版本库的自动增量升级。 无需依赖任何文件同步工具,只需...

    文档转载自:http://tech.uc.cn/?p=1621


    问题背景:

    1. 能否以某种简便甚至自动化的方式,将修改过的文件以增量的方式同步到线上而不影响应用的正常运行。
    2. 除了文件同步外,能否自定义某些脚本,在升级时自动执行。
    3. 如果发现升级后的版本有问题,能否快速回滚到原来的版本。

    写作目的:

    1. 以SVN为例子,学会基于版本库的自动增量升级。
    2. 无需依赖任何文件同步工具,只需简单的几个shell脚本便可完成从自动增量打包到自动增量升级的整个过程。

    适合阅读对象:

    1. 想从繁琐乏味的升级工作中解放出来的运维人员。
    2. 担心因修改文件数目多而可能导致升级遗漏的开发人员(尤其是web项目开发者)。
    3. 想了解自动增量升级设计思想的人员。

    不涉及的内容:

    1. 暂未包含基于hg或git版本库的增量升级的实现,但思路与SVN是类似的。
    2. 本文侧重业务应用的增量升级,不涉及个人软件或者系统软件的增量升级,尽管这两者存在一些相似的地方。

    脚本下载地址:

    https://github.com/joerong666/auto_patch.git


    正文:

    增量升级这个名词相信已经不是什么新鲜事物了,甚至我们每天在不经意间也已经做了该事。比如windows的自动更新,就是增量更新的一种。先撇开系统软件的升级不说,作为一个业务应用开发者,笔者这里就自己所了解,介绍一下业务应用在做增量升级方面都采用哪些方法。

    升级方法比较

    方法一:逐个文件拷贝覆盖

    这个是最原始的增量升级方式,虽然简单,但繁琐且易漏易错,相信稍有点规模的应用都不会采用这种方式。想想如果有分布在不同子目录中的上百个文件被修改过了,你得执行拷贝覆盖多少次,更悲催的是,你花了九牛二虎之力才把文件拷贝好,结果却发现覆盖错了。

    方法二:使用类似rsync的文件同步服务器

    相对来说,使用rsync可以确保文件不会被误覆盖,也能保持目录结构的一致性。但个人觉得这只是一种文件同步,跟升级还是有一定的区别,如果我们的升级仅仅是涉及文件的覆盖或删除,或许采用rsync是一个不错的选择。但如果想在升级的同时自动执行某些定制的程序或脚本,那么rsync就显得有点爱莫能助了。另外rsync的引入,也需要额外的成本去搭建和监控它,自然也就需要额外的维护成本。而且rsync与版本库的无缝结合也是个值得考验的问题,能否由rsync直接从版本库中获取增量的部分,还是得额外写个脚本将增量部分写到rsync的同步目录中,再由rsync客户端来获取?

    方法三:由开发人员手工编写升级脚本

    一般来说,采用这种方法,首先需要开发人员记录下哪些文件涉及改动,当然可通过查看版本历史的方式来判断哪些文件需要做更新;然后再针对这些文件,逐条编写相应的用于覆盖或删除线上应用的copy或rm语句;最后将包含这些语句的脚本随增量文件一起打包给运维人员,让运维人员到线上执行。从可靠性的方面考虑,这种方式还不如第二种方法,但相对来说,这种方式的可控性比较灵活,可以灵活自定义升级脚本,而不是简单的同步文件。比如可以定义在升级的同时执行某个特定的程序,最常见的就是在升级的同时重启原来的某些服务。

    方法四:自动增量升级

    该方法是对方法三的一种增强,一方面是升级脚本是根据版本历史自动生成的,不再需要人工编写;另一方面,支持自定义升级扩展,也就说除了生成简单的增量覆盖升级脚本外,还支持以可插拔式的方式将自定制的程序让升级脚本自动执行。这是笔者选择的升级方法,也是本文的讲述重点。下面针对这种方法具体展开描述。


    自动增量升级

    下面先从流程方面来大概介绍一下自动增量升级的整个思路,然后再从程序的角度解释一下本文中所涉及的脚本的作用。

    升级流程分两个阶段,第一阶段为增量打包操作,一般由开发人员执行;第二阶段为升级操作,可由运维人员执行。

    增量打包流程

    流程描述:更新版本库 ===> 生成增量清单文件 ===> 检查并修剪清单文件(以及编写自定义升级程序) ===> 生成增量补丁包

    对应命令或脚本:svn update ===> gen_manifest.sh(需将结果重定向到PATCH_MANIFEST清单文件) ===> 添加或删除清单文件(PATCH_MANIFEST)中无需做更新的记录(同时根据需要编写想让升级程序自动执行的脚本,如demo_custom_script.sh) ===> gen_patch.sh

    升级流程

    流程描述:获取增量包 ===> 执行升级操作并生成增量包的回滚备份包

    对应命令或脚本:可通过wget获取增量包 ===> patch.sh(执行完后会生成增量回滚包,如patch_recover_20130626113450)

    程序解释

    生成清单文件gen_manifest.sh

    该脚本用于生成增量清单文件,既然是增量,就需要有一个相对版本,所以至少需要传入revision1这个版本参数,其值为上次程序发布时的版本库版本号加1。默认情况,该脚本会生成当前目录及其所有子目录下(递归)的增量清单,如果只需要针对某个子目录,则可指定sub_dir。因一般情况下该脚本生成出来的清单都需做一定的修剪,为了可直接供管道使用,这里并没有让它输出到文件,而是直接输出到标准输出,使用者可根据需要直接重定向到PATCH_MANIFEST(这个文件名是gen_patch.sh脚本约定好使用的,不能为其它名字)文件。

    清单文件PATCH_MANIFEST

    大体如下:

    这里分几点来解释一下这个清单文件:

    1. 行首带#号的为注释行,gen_patch.sh不会解析。由于有些配置文件(如这里的config.conf)我们在版本库上虽做了修改,但我们不能更新到线上应用去,毕竟配置不一样,故直接把相应的行注释掉即可(注意记得把相应的目录也注释掉,如这里的”#r2197:A:sub_dir/conf“行)。

    2. 第一行是一个样例,标识每行记录需遵守的格式,一行最多只有4项,每项用冒号分隔。revision为版本号;A/D/C分别表示为“添加或修改(Add)/删除(Delete)/自定义命令(Comand)“;src_file为涉及文件在版本库中的目录结构;dest_dir(这里是目录,而不是文件)为src_file在发布包中的目录结构,如果没指定则表示涉及的文件在版本库和发布包中的目录结构一样。

    3. 后面的版本号为xxxxx的行是一些自定义操作行,这些操作并没有或者无法在版本库中体现。如
      xxxxx:A:sub_dir/db/patch.sql ===> patch.sql文件在指定的版本号范围内并没有相应的更改历史,也许它根本就不在版本库内,但我们又想让它随本次的增量包拷贝到线上应用去,所以采用这种定制的方式委婉的将它纳入增量包中。

    4. 值得注意的是操作为”C”的行,如这里的最后一行:
      xxxxx:C:patch_script/demo_custom_script.sh:sub_dir/autoscript ===>C操作的行并非简单的表示将src_file拷贝到dest_dir,事实上它并没有被拷贝到线上应用中去,而只是仅仅打进增量包中,然后作为一种自动化的程序,在运维人员执行升级(patch.sh)操作时被自动执行的程序,有点被回调的味道。该程序一般需要开发人员根据实际需要编写,一般是一些执行服务的操作,如重启某些服务。如这里提到的demo_custom_script.sh。

    自定义升级脚本demo_custom_script.sh

    生成增量包gen_patch.sh

    gen_patch.sh的功能很简单,就是根据之前生成的清单文件PATCH_MANIFEST生成增量包,所以前提是确保清单文件是准确的,当然也可以通过查看生成后的增量包是否符合实际要求来进一步确认。

    执行升级操作patch.sh

    顾名思义,该脚本的作用就是用于给当前的应用打上补丁,一般由线上的运维人员执行。该脚本应该在程序第一次发布的时候包含进去,且应该与放置应用代码的根目录同级。如下

    其中的app-patch20130624.tar.gz即为前面通过gen_patch.sh生成的增量升级包,而patch_recover_20130613182709目录是执行升级前自动生成的增量备份,如果发现升级有误的话,可立即通过将该备份目录下的内容拷回原来的位置,即可完成回滚。


    结束

    虽然前面洋洋洒洒写了好多,感觉好像很复杂的样子,其实想要表达意思的很简单,就下面三个步骤:

    • 生成增量包
      $ ./gen_manifest.sh 2061 >PATCH_MANIFEST
      $ ./gen_patch.sh app ===>生成app-patch20130624.tar.gz

    • 执行升级
      $ ./patch.sh app-patch20130624.tar.gz

    展开全文
  • [升级] 数据库升级到11g的应急方案

    千次阅读 2013-11-25 17:12:01
    数据库升级应急方案 通过对数据库初始化参数进行调整来对出现的故障或者性能问题进行处理。 _subquery_pruning_enabled 参数:_subquery_pruning_enabled 默认值:true 推荐值:false 动态修改:推荐在...
  • Android 数据库升级完整解决方案

    千次阅读 2016-11-24 12:55:19
    数据库升级的意义 我们在开发Android应用的时候,不可避免地要使用数据库。而数据库的结构在第一版的时候定下来,之后发布功能更新,或增加业务逻辑,原来的数据库结构可能就不适用了。而如果数据库的结构与之前...
  • 为了方便维护人员在现场升级产品,我们做这个升级产品。不用拆装设备,实现远程升级产品。 需求分析 所谓远程空中升级,就是利用无线网络给指定MCU更新程序。在这里的无线设备我使用的是蓝牙(CC2541芯片或者CC2542...
  • 如何撰写sms产品方案

    千次阅读 2005-01-25 02:36:00
    如何撰写sms产品方案 简单写写对于撰写sms产品方案的一些想法,本文中含有一些对于业界发展的一些考虑的东西,包括对于业务拓展的一些思考。不过主要内容是如果完成一份产品方案,纯属个人的工作习惯。SMS产品方案...
  • 最全的 netcore 3.0 升级实战方案

    千次阅读 2019-09-18 09:38:40
    1、哈喽大家中秋节(后)好呀!感觉已经好久没有文章了,但是也没有偷懒哟,我的视频教程《系列一、NetCore 视频教程(Blog.Core)》也已经录制八期了,还在每周...
  • 最近对产品升级的思考

    千次阅读 2006-05-30 23:37:00
    看来每天一篇BLOG还是有点意思的,呵呵这两天一直在思考产品升级和更进一步的产品化。当然现在已经产品化的东西,再想大幅度升级已经非常困难了,现在需要评估Spring2.0和Hibernate3.0能够为项目带来什么,升级...
  • 软件自动升级解决方案(一)

    万次阅读 2006-10-31 22:31:00
    感觉它功能强大,基本上满足所有的CS或者BS的软件升级功能. 在闲余时间把它整理出来.提供给大家在软件升级方面一个参考.软件源代码地址: http://www.gvhsoftware.org/products/Default.aspx使用说明: A: 服务器配置...
  • 【android】数据库升级完整解决方案

    千次阅读 2014-08-23 14:19:33
    作者:飞翔的猫咪 原创作品,允许转载,转载时请务必以...数据库升级的意义 我们在开发Android应用的时候,不可避免地要使用数据库。而数据库的结构在第一版的时候定下来,之后发布功能更新,或增加业务逻辑,
  • 电子产品如何使用IAP方式升级程序

    千次阅读 2020-11-29 23:13:55
    2、IAP升级程序的原理 通常一块MCU芯片的Code(代码)区内只有一个用户程序,而IAP方案则是将代码区划分为两部分,两部分区域各存放一个程序,一个为BootLoader(引导加载程序),另一个为User Application(用户应用...
  • 一直没时间博客了,一直在专研产品设计与技术解决方案。多年的积累与项目实战发现项目业务几乎每个程序员都能,但是解决方案却不一定每个人能解决掉。我所认知的一个项目由于时间跟业务的爆发都会遇到两个最大的...
  • 你希望自己花了大量人力物力用.net开发出来的产品被竞争对手轻易获取核心代码吗?这是一篇比较详尽地介绍如何保护自己的.net源代码的文章,如混淆、加密和强名称等,出于保护原作者的角度,所以本人没有掐头去尾作为...
  • 但是很多做APP推广人并不是都能在这些优秀的公司或者产品体系里面成长,他们更多的是小众的,创业的,或者是刚起步的,所以我想再次记录自己的工作的成长过程,把自己工作中遇到的困难或者心得分享
  • 2014年 底,他过一篇《中国移动应用设计趋势》,引起了大家的广泛关注,时隔一年多,他根据中国当今的移动 App UI 趋势,加上自己的新想法,总结出这篇新文章,希望能给移动世界带来一些新进步。▌本文作者:Dan ...
  • 产品:飞算全自动软件工程平台上拖拉拽搞一下SQL就好了,不用Java,我又不会... 开发:飞算全自动软件工程平台是什么鬼?来抢我饭碗吗?我这是要凉了吗? 产品:额,你竟然还不知道? 开发:... 这是最近发生在某...
  • Android组件化方案

    万次阅读 多人点赞 2017-02-15 19:01:52
    试想,我们经常在代码的时候定义静态常量,那么定义静态常量的目的什么呢?当一个常量需要被好几处代码引用的时候,把这个常量定义为静态常量的好处是当这个常量的值需要改变时我们只需要改变静态常量的值,其他...
  • 吐槽升级-rpm方式升级的一些经历

    千次阅读 2017-02-01 13:34:45
    升级在很多人眼里非常的普通。...鄙人工作内容跟产品升级有关,因此也关注了不少升级相关内容。在此跟大伙吐槽一下,当然更希望能抛砖引玉,吸引有经验同行讨论,共同进步。 1、rpm管理 升级是个很宽的概
  • 编译一下,用贵公司的名义打个一模一样的包,升级为 1.2 试用版,然后放到 ftp  或  shareware site  上供人试用下载。试想一下,不久您就会接到用户的投诉,甚至是起诉。 再比方说:要离开公司的员工,对公司...
  • 给欲从事产品工作的应届毕业生

    千次阅读 2011-01-25 18:08:00
     给欲从事产品工作的应届毕业生     当前正在热烈上演的各高校2011校园招聘会上,“产品经理”、“产品专员”、“产品工程师”、“产品助理”、“产品运营经理”等之类的职位频频出现,很多...
  • 笔记本升级--老华硕的升级之路

    千次阅读 2020-06-09 13:09:01
    2.升级方案选择; 3.其间可能遇到的问题:①系统方案选择,我用的是优启通pe工具重装; ②进入bios模式热键,华硕win10,需要shift关机后再f2开机; ③初次重装必须熟悉操作步骤后再动手!!! 学生
  • 锋影email:174176320@qq.com嵌入式 Linux 系统在线升级策略对于运行 Linux 系统的嵌入式产品,很多时候我们发现了当前版本内核、驱动、或者应用程序的 bug 并对之修复之后,或者研发出了功能更丰富、性能更突出的...
  • 数码相框解决方案深度分析

    千次阅读 2017-10-13 09:49:27
    数码相框从最初的概念型产品进入市场,至今已有五、六年时间。早期的数码相框解决方案,多数是移植DVD播放器的平台,也有部分使用的是多媒体应用平台(如PMP),数码相框的专业平台极少。如今,数码相框市场正在经历...
  • 智慧农业技术解决方案

    千次阅读 2020-06-23 16:03:24
    技术方案 设计思路 构建一体化业务支撑平台,形成农业产业体系 国家“十二五”规划中明确提出,将完善现代农业产业体系作为“十二五”的重点建设任务,因此,智慧农业的建设也应以建设一体化的农业产业...
  • 文章目录项目概述要求Bootloader介绍原理设计功能设计硬件设计软件设计主机主机流程Xmodem协议代码从机从机流程升级方案区域划分Boot链接文件修改APP A链接文件修改APP B链接文件修改代码传感器程序设计SPI读芯片...
  • 这些报告既有关于新产品规划的,又有老产品迭代升级的。作为一个阶段性的总结,我认为有必要将自己的心得体会记录下来,方便同仁之间交流,也方便日后的反思与进步。 首先,需求报告(或者产品报告)与科技论文有...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 75,912
精华内容 30,364
关键字:

产品升级方案怎么写