第二步:打开Application ->Accessories ->Terminal
第三步: 定位到CCS5.1.1.00033_linux完成解压的位置
第四部:使用chmod命令改变文件夹里ccs_setup_5.1.1.00033.bin的属性为可执行
(PS:
chmod命令格式:chmod [who][+|-|=][mode]文件名
[who]:该文件的属性更改是针对linux系统用户的范围
a all user 所有用户
u user 当前文件或目录的所有者
o other其他用户
g group当前文件或目录的所有者同组的所有用户
[+|-|=]
+ 添加“+”后面的属性
- 取消“-”后面的属性
= 给与“=”后面的属性并取消其他所有属性
[mode]
r read 可读
w write 可写
x excute 可执行
文件名
chmod所执行的文件或目录的主体名称
)
第五步:执行ccs_setup_5.1.1.00033.bin文件
./ccs_setup_5.1.1.00033.bin
root@ubuntu:/home/ktd007/Downloads# ls
CCS5.1.1.00033_linux VMwareTools-8.4.3-282343.tar.gz
root@ubuntu:/home/ktd007/Downloads# cd CCS5.1.1.00033_linux
root@ubuntu:/home/ktd007/Downloads/CCS5.1.1.00033_linux# ls
artifacts.jar ccs_setup_5.1.1.00033.bin features
baserepo content.jarREADME_FIRST.txt
binary featurerepotimestamp.txt
root@ubuntu:/home/ktd007/Downloads/CCS5.1.1.00033_linux# chmod a+x ccs_setup_5.1.1.00033.bin
root@ubuntu:/home/ktd007/Downloads/CCS5.1.1.00033_linux# ./ccs_setup_5.1.1.00033.bin
开始安装ccs5.1的图形化界面
接下来的安装过程和windows下的安装过程没有任何差别
1.DSP/BIOS应用程序调试(2009.10.20)在CCS2.0 的emulator写dsp/bios 的程序,编译链接无错误,而点击LOAD Program下载xxx.out完成时d出如下对话框:
RTDX target application does not match emulation protocol!
Loaded program was created with an rtdx library which does not match the target device
这将导致RTDX(实时数据交换)不能使用
分析:
RTXD可以在DSP/BIOS中使用,也可以脱离DSP/BIOS使用;目前CCS Simulator不支持RTDX,故RTDX必须在Emulator下使用,即还需要硬件仿真器和DSP目标板。
故这是由于下载BIOS/DSP程序时RTDX设置错误导致的;
问题解决如下:
把DSP/BIOS配置窗口中的input/output-->RTDX -real-Time Exchange settings的RTDX mode 改为JTAG(原来是simulator),重新编译后LOAD,上述警告消除,可以在模拟的情况下进行BIOS调试了。
PS:虽然simulator能编译运行DSP/BIOS程序,并能提供实时查询程序运行情况(主要是CPU负荷,时序,日志以及线程等)。但实际开发DSP/BIOS应用程序时为了真实的了解目标板的各种信息,仅有Simulator(软件仿真器)是不行的,还需要使用Emulator(硬件仿真器)和DSP/BIOS插件(安装时已装入)。
IT路边社
前言
与其它的编码规范一样,这里所讨论的不仅仅是编码格式美不美观的问题, 同时也讨论一些约定及编码标准。这份文档主要侧重于我们所普遍遵循的规则,对于那些不是明确强制要求的,我们尽量避免提供意见。
编码规范对于程序员而言尤为重要,有以下几个原因:
本文档中的准则致力于最大限度达到以下原则:
尽管本文档涵盖了许多基础知识,但应注意的是,没有编码规范可以为我们回答所有问题,开发人员始终需要再编写完代码后,对上述原则做出正确的判断。
注 :未明确指明的则默认为必须(Mandatory)
主要参考如下文档:
仅建议Shell用作相对简单的实用工具或者包装脚本。因此单个shell脚本内容不宜太过复杂。
在选择何时使用shell脚本时时应遵循以下原则:
可执行文件不建议有扩展名,库文件必须使用 .sh 作为扩展名,且应是不可执行的。
执行一个程序时,无需知道其编写语言,且shell脚本并不要求具有扩展名,所以更倾向可执行文件没有扩展名。
而库文件知道其编写语言十分重要,使用 .sh 作为特定语言后缀的扩展名,可以和其他语言编写的库文件加以区分。
文件名要求全部小写, 可以包含下划线 _ 或连字符 - , 建议可执行文件使用连字符,库文件使用下划线。
正例:
反例:
源文件编码格式为UTF-8。避免不同 *** 作系统对文件换行处理的方式不同,一律使用 LF 。
每行最多不超过120个字符。每行代码最大长度限制的根本原因是过长的行会导致阅读障碍,使得缩进失效。
除了以下两种情况例外:
如出现长度必须超过120个字符的字符串,应尽量使用here document或者嵌入的换行符等合适的方法使其变短。
示例:
除了在行结束使用换行符,空格是源文件中唯一允许出现的空白字符。
对从来没有用到的或者被注释的方法、变量等要坚决从代码中清理出去,避免过多垃圾造成干扰。
Bash 是唯一被允许使用的可执行脚本shell。
可执行文件必须以 #!/bin/bash 开始。请使用 set 来设置shell的选项,使得用 bash echo "Process $: Done making $$$."
# 示例7:命令参数及路径不需要引号 grep -li Hugo /dev/ "$1"
# 示例8:常规变量用双引号,ccs可能为空的特殊情况可不用引号 git send-email --to "${reviewers}" ${ccs:+"--cc" "${ccs}"}
# 示例9:正则用单引号,$1可能为空的特殊情况可不用引号 grep -cP '([Ss]pecial||?characters*) ${1:+"$1"}
# 示例10:位置参数传递推荐带引号的"$@",所有参数作为单字符串传递用带引号的"$*" # content of t.sh func_t { echo num: $# echo args: 1:$1 2:$2 3:$3 }
func_t "$@" func_t "$*" # 当执行 ./t.sh a b c 时输出如下: num: 3 args: 1:a 2:b 3:c num: 1 args: 1:a b c 2: 3:
使用 $(command) 而不是反引号。
因反引号如果要嵌套则要求用反斜杠转义内部的反引号。而 $(command) 形式的嵌套无需转义,且可读性更高。
正例:
反例:
条件测试
使用 [[ ... ]] ,而不是 [ , test , 和 /usr/bin/[ 。
因为在 [[ 和 ]] 之间不会出现路径扩展或单词切分,所以使用 [[ ... ]] 能够减少犯错。且 [[ ... ]] 支持正则表达式匹配,而 [ ... ] 不支持。参考以下示例:
尽可能使用变量引用,而非字符串过滤。
Bash可以很好的处理空字符串测试,请使用空/非空字符串测试方法,而不是过滤字符,让代码具有更高的可读性。正例:
反例:
正例:
反例:
正例:
反例:
文件名扩展
当进行文件名的通配符扩展时,请指定明确的路径。
当目录中有特殊文件名如以 - 开头的文件时,使用带路径的扩展通配符 ./* 比不带路径的 * 要安全很多。
应该避免使用eval。
Eval在用于分配变量时会修改输入内容,但设置变量的同时并不能检查这些变量是什么。反例:
请使用进程替换或者for循环,而不是通过管道连接while循环。
这是因为在管道之后的while循环中,命令是在一个子shell中运行的,因此对变量的修改是不能传递给父shell的。
这种管道连接while循环中的隐式子shell使得bug定位非常困难。反例:
如果你确定输入中不包含空格或者其他特殊符号(通常不是来自用户输入),则可以用for循环代替。例如:
使用进程替换可实现重定向输出,但是请将命令放入显式子 shell,而非 while 循环创建的隐式子 shell。例如:
总是检查返回值,且提供有用的返回值。
对于非管道命令,使用 $? 或直接通过 if 语句来检查以保持其简洁。
例如:
当内建命令可以完成相同的任务时,在shell内建命令和调用外部命令之间,应尽量选择内建命令。
因内建命令相比外部命令而言会产生更少的依赖,且多数情况调用内建命令比调用外部命令可以获得更好的性能(通常外部命令会产生额外的进程开销)。
正例:
反例:
加载外部库文件不建议用使用.,建议使用source,已提升可阅读性。正例:
反例:
除非必要情况,尽量使用单个命令及其参数组合来完成一项任务,而非多个命令加上管道的不必要组合。常见的不建议的用法例如:cat和grep连用过滤字符串cat和wc连用统计行数grep和wc连用统计行数等。
正例:
除特殊情况外,几乎所有函数都不应该使用exit直接退出脚本,而应该使用return进行返回,以便后续逻辑中可以对错误进行处理。正例:
反例:
推荐以下工具帮助我们进行代码的规范:
原文链接:http://itxx00.github.io/blog/2020/01/03/shell-standards/
获取更多的面试题、脚本等运维资料点击: 运维知识社区 获取
脚本之---短信轰炸机
脚本之---QQ微信轰炸机
ansible---一键搭建redis5.0.5集群
elk7.9真集群docker部署文档
全球最全loki部署及配置文档
最强安全加固脚本2.0
一键设置iptbales脚本
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)