l********n
发帖数: 1038 | 1 完全没这方面的经验，这行似乎机会比较多，怎样才能入门 |
m****y
发帖数: 244 | 2 从哪里看出来多的？
【在 l********n 的大作中提到】
: 完全没这方面的经验，这行似乎机会比较多，怎样才能入门
|
l********n
发帖数: 1038 | |
d*******r
发帖数: 3299 | 4 同关注，总想业余玩玩。我的感觉是，抱着一本讲kernel的砖头看源码，基本没啥用. |
b***i
发帖数: 3043 | 5 进入任何领域必须实干，就是做项目，而不是看书。以项目为目的，看书为完成项目的
手段。
嵌入式，做一个控制喷水系统的web server，然后在机场能够用手机开关即可。
【在 d*******r 的大作中提到】
: 同关注，总想业余玩玩。我的感觉是，抱着一本讲kernel的砖头看源码，基本没啥用.
|
d****i
发帖数: 4809 | 6 你这个有点现代化的了，传统的嵌入式就是根据datasheet写driver和各种接口的通信
来控制硬件。
【在 b***i 的大作中提到】
: 进入任何领域必须实干，就是做项目，而不是看书。以项目为目的，看书为完成项目的
: 手段。
: 嵌入式，做一个控制喷水系统的web server，然后在机场能够用手机开关即可。
|
b***i
发帖数: 3043 | 7 近代技术可以用uC/OS，然后用例子里的web server就可以了。仍然要直接控制外设，
但是要semaphore/mutex什么的保护。这样比裸写好多了。
我最近搞到一个系统，可以发出噪音，主频100MHz，有网络口。非常满意。只是代码只
能写32k以内。
【在 d****i 的大作中提到】
: 你这个有点现代化的了，传统的嵌入式就是根据datasheet写driver和各种接口的通信
: 来控制硬件。
|
k**********g
发帖数: 989 | |
d*******r
发帖数: 3299 | 9 请问要玩 uC/OS 的话，推荐用什么tool set (比如build出来的image可以扔到 QEMU
上玩吗)，我之前胡乱搜些视频看了下，发现都是在windows下搞的？
还有，好像 uC/OS II 是开源的，III 好像不是的？ 请问你是玩的哪个版本呢。
【在 b***i 的大作中提到】
: 近代技术可以用uC/OS，然后用例子里的web server就可以了。仍然要直接控制外设，
: 但是要semaphore/mutex什么的保护。这样比裸写好多了。
: 我最近搞到一个系统，可以发出噪音，主频100MHz，有网络口。非常满意。只是代码只
: 能写32k以内。
|
b***i
发帖数: 3043 | 10 我用的iar试用版,所以有限制，但是不要钱啊。等有时间了转Eclipse试试。我直接RX
开发板上，听说很便宜，好像100块可以买到。
我现在用III，也是开源的。
【在 d*******r 的大作中提到】
: 请问要玩 uC/OS 的话，推荐用什么tool set (比如build出来的image可以扔到 QEMU
: 上玩吗)，我之前胡乱搜些视频看了下，发现都是在windows下搞的？
: 还有，好像 uC/OS II 是开源的，III 好像不是的？ 请问你是玩的哪个版本呢。
|
|
|
H**r
发帖数: 10015 | 11 为啥我觉得IAR不好用
RX
【在 b***i 的大作中提到】
: 我用的iar试用版,所以有限制，但是不要钱啊。等有时间了转Eclipse试试。我直接RX
: 开发板上，听说很便宜，好像100块可以买到。
: 我现在用III，也是开源的。
|
d*******r
发帖数: 3299 | 12 我想请教下，uC/OS 和 μClinux之类比起来，主要优缺点是什么？
我知道 uC/OS 的学习资料是非常好的.
RX
【在 b***i 的大作中提到】
: 我用的iar试用版,所以有限制，但是不要钱啊。等有时间了转Eclipse试试。我直接RX
: 开发板上，听说很便宜，好像100块可以买到。
: 我现在用III，也是开源的。
|
s********k
发帖数: 6180 | 13 uCOS 基本上算是一个RTOS，linux不算
【在 d*******r 的大作中提到】
: 我想请教下，uC/OS 和 μClinux之类比起来，主要优缺点是什么？
: 我知道 uC/OS 的学习资料是非常好的.
:
: RX
|
d****i
发帖数: 4809 | 14 en, Linux还是从desktop来的，太heavy-weight了，很多嵌入式上连RTOS都不用，就是
一个scheduler。
【在 s********k 的大作中提到】
: uCOS 基本上算是一个RTOS，linux不算
|
N*****m
发帖数: 42603 | 15 ucos有啥开发模拟器吗？
【在 d****i 的大作中提到】
: en, Linux还是从desktop来的，太heavy-weight了，很多嵌入式上连RTOS都不用，就是
: 一个scheduler。
|
d****i
发帖数: 4809 | 16 没有用过uC/OS，bihai用过，可以问问他。
【在 N*****m 的大作中提到】
: ucos有啥开发模拟器吗？
|
s********k
发帖数: 6180 | 17 开发嵌入式，最忌讳就是为了OS而OS,有点绕口，但是意思是嵌入式能简单就简单、不
要为了耍酷或者自己喜好非要上不必要feature
★ 发自iPhone App: ChineseWeb 7.8
【在 d*******r 的大作中提到】
: 我想请教下，uC/OS 和 μClinux之类比起来，主要优缺点是什么？
: 我知道 uC/OS 的学习资料是非常好的.
:
: RX
|
s********k
发帖数: 6180 | 18 能单线程绝对不多线程，能做poll 绝对不上int based,
★ 发自iPhone App: ChineseWeb 7.8
【在 d****i 的大作中提到】
: en, Linux还是从desktop来的，太heavy-weight了，很多嵌入式上连RTOS都不用，就是
: 一个scheduler。
|
w****w
发帖数: 521 | 19 写个pc的boot程序，做加减法，不用bios,自己控制硬件。
【在 l********n 的大作中提到】
: 完全没这方面的经验，这行似乎机会比较多，怎样才能入门
|
H**r
发帖数: 10015 | 20 以前很多行业是不跑RTOS的，现在有那么多现成的可以用，时代不同了
【在 d****i 的大作中提到】
: en, Linux还是从desktop来的，太heavy-weight了，很多嵌入式上连RTOS都不用，就是
: 一个scheduler。
|
|
|
c*******2
发帖数: 66 | 21 弄一块带Zigbee的8051,或者Zigbee连Arduino的板子，最好还通过DAC连机械驱动装置
的,先试试手. 玩起来再说。
【在 l********n 的大作中提到】
: 完全没这方面的经验，这行似乎机会比较多，怎样才能入门
|
x****u
发帖数: 44466 | 22 多核情况下千万别这么想。
【在 s********k 的大作中提到】
: 能单线程绝对不多线程，能做poll 绝对不上int based,
:
: ★ 发自iPhone App: ChineseWeb 7.8
|
x****u
发帖数: 44466 | 23 比起买一套连电脑乐高积木，也多学不了什么东西。其实嵌入式都是在厂家画好的框子
里自己发挥。
【在 c*******2 的大作中提到】
: 弄一块带Zigbee的8051,或者Zigbee连Arduino的板子，最好还通过DAC连机械驱动装置
: 的,先试试手. 玩起来再说。
|
s********k
发帖数: 6180 | 24 嵌入式范围太广，如果你把mobile phone之类的也算，那多核是需要考虑，我说的是大
多资源很有限的。
【在 x****u 的大作中提到】
: 多核情况下千万别这么想。
|
t*****s
发帖数: 416 | 25 很多时候线程不是为了效率。也不是为了fancy。而是为了降低编程难度。
有些routine过一段时间就要执行一次，如果不用线程或者进程，而直接参到主进程里
，会让程序构造变得很复杂的。
【在 s********k 的大作中提到】
: 嵌入式范围太广，如果你把mobile phone之类的也算，那多核是需要考虑，我说的是大
: 多资源很有限的。
|
x****u
发帖数: 44466 | 26 要基于体系结构啊，多线程有可能费电也可能省电。
【在 s********k 的大作中提到】
: 嵌入式范围太广，如果你把mobile phone之类的也算，那多核是需要考虑，我说的是大
: 多资源很有限的。
|
x****u
发帖数: 44466 | 27 你说的这个场景，用单线程配合中断一点压力也没有。
【在 t*****s 的大作中提到】
: 很多时候线程不是为了效率。也不是为了fancy。而是为了降低编程难度。
: 有些routine过一段时间就要执行一次，如果不用线程或者进程，而直接参到主进程里
: ，会让程序构造变得很复杂的。
|
t*****s
发帖数: 416 | 28 你又知道我说的什么场景了？
我说的如果是个随机间隔采样内存数据的routine怎么办？咱家开发板上没RTC。
【在 x****u 的大作中提到】
: 你说的这个场景，用单线程配合中断一点压力也没有。
|
x****u
发帖数: 44466 | 29 没有时间中断你怎么实现单CPU多任务？
【在 t*****s 的大作中提到】
: 你又知道我说的什么场景了？
: 我说的如果是个随机间隔采样内存数据的routine怎么办？咱家开发板上没RTC。
|
t*****s
发帖数: 416 | 30 RTC和时间中断是两码事好不好。
时间中断现在是CPU内部的counter，启动的时候init，依赖CPU的运行时钟，到一定值
就发IRQ。
你是不能program这个时间中断的。program了就真没有多任务了。
【在 x****u 的大作中提到】
: 没有时间中断你怎么实现单CPU多任务？
|
|
|
x****u
发帖数: 44466 | 31 能引发定时中断的东西就是RTC，你不是说没有RTC么？
当然可以把部分外设集成到CPU内，但在体系结构上这些东西还是外设。
如果这个时钟仅限于counter不可以编程，那还是没办法单核多任务啊，切换必须要靠
时钟中断，或者当前任务主动放弃执行权。
【在 t*****s 的大作中提到】
: RTC和时间中断是两码事好不好。
: 时间中断现在是CPU内部的counter，启动的时候init，依赖CPU的运行时钟，到一定值
: 就发IRQ。
: 你是不能program这个时间中断的。program了就真没有多任务了。
|
t*****s
发帖数: 416 | 32 唉。我真不想跟你争。
我好好的回别人一个帖子，结果你又跳出来要战，把人家好好的一个帖子毁了。
其实不用RTC也不是没解决办法的。结果你就真往坑里跳说counter-based时钟中断就是
RTC……
咱就当它是吧。问题这个时钟中断就一个，操作系统默认它触发scheduler。你用它触
发你的routine的话。scheduler怎么办？
【在 x****u 的大作中提到】
: 能引发定时中断的东西就是RTC，你不是说没有RTC么？
: 当然可以把部分外设集成到CPU内，但在体系结构上这些东西还是外设。
: 如果这个时钟仅限于counter不可以编程，那还是没办法单核多任务啊，切换必须要靠
: 时钟中断，或者当前任务主动放弃执行权。
|
x****u
发帖数: 44466 | 33 别说“咱就当它是吧”，等你介绍不用时钟中断的实现的单核多任务呢。
一个中断触发多个routine是从16位DOS时代就有的东西了，TSR都玩出花来了。
【在 t*****s 的大作中提到】
: 唉。我真不想跟你争。
: 我好好的回别人一个帖子，结果你又跳出来要战，把人家好好的一个帖子毁了。
: 其实不用RTC也不是没解决办法的。结果你就真往坑里跳说counter-based时钟中断就是
: RTC……
: 咱就当它是吧。问题这个时钟中断就一个，操作系统默认它触发scheduler。你用它触
: 发你的routine的话。scheduler怎么办？
|
t*****s
发帖数: 416 | 34 我没说过没有时钟中断啊。我只不过说时钟中断不等于RTC而已。你要让它相等咱们就
让它相等好了。
一个中断触发多个routine不是问题。可是时钟中断的间隔和我的routine想要的间隔不
一样怎么办呢？比如时钟中断间隔1ms，我的routine今天心情好要700us，明天心情不
好要300ns。
当然硬要搞也不是搞不出来。另外不要忘了，要以“和使用线程比起来不大幅增加编程
难度的方式”解决哦。
【在 x****u 的大作中提到】
: 别说“咱就当它是吧”，等你介绍不用时钟中断的实现的单核多任务呢。
: 一个中断触发多个routine是从16位DOS时代就有的东西了，TSR都玩出花来了。
|
x****u
发帖数: 44466 | 35 如果你的routine需要非常精确的定时，那么必须要专用外设配合，而且OS要做实时优
化。
大多数情况下系统并没有做的这么准确，时钟只是很粗略的实现。
【在 t*****s 的大作中提到】
: 我没说过没有时钟中断啊。我只不过说时钟中断不等于RTC而已。你要让它相等咱们就
: 让它相等好了。
: 一个中断触发多个routine不是问题。可是时钟中断的间隔和我的routine想要的间隔不
: 一样怎么办呢？比如时钟中断间隔1ms，我的routine今天心情好要700us，明天心情不
: 好要300ns。
: 当然硬要搞也不是搞不出来。另外不要忘了，要以“和使用线程比起来不大幅增加编程
: 难度的方式”解决哦。
|
t*****s
发帖数: 416 | 36 我不需要很精确啊。我要700us你给我800我也不会造反啊。嫌300ns太短我要300us好了
，只要别给到600us我也没很大意见嘛。
【在 x****u 的大作中提到】
: 如果你的routine需要非常精确的定时，那么必须要专用外设配合，而且OS要做实时优
: 化。
: 大多数情况下系统并没有做的这么准确，时钟只是很粗略的实现。
|
x****u
发帖数: 44466 | 37 纳秒级中断不是普通硬件系统应付的了的，微秒级中断也是代价非常大的。
【在 t*****s 的大作中提到】
: 我不需要很精确啊。我要700us你给我800我也不会造反啊。嫌300ns太短我要300us好了
: ，只要别给到600us我也没很大意见嘛。
|
t*****s
发帖数: 416 | 38 那咱么就说低端硬件好了。
系统时钟中断20ms，咱的routine今天想要27ms，明天想要53ms。
【在 x****u 的大作中提到】
: 纳秒级中断不是普通硬件系统应付的了的，微秒级中断也是代价非常大的。
|
x****u
发帖数: 44466 | 39 在单核普通系统上是做不到的，实时是以损失性能为代价的。
【在 t*****s 的大作中提到】
: 那咱么就说低端硬件好了。
: 系统时钟中断20ms，咱的routine今天想要27ms，明天想要53ms。
|
s********k
发帖数: 6180 | 40 非也，多线程再怎么也比poll based复杂，尤其考虑到各种同步的情况，消耗资源多数
情况下也比poll多。我看大多数资源有限情况下，一个BG的poll和FG的INT就可以了。
多线程用在极其成熟的RTOS，比如ucOS还可以
【在 t*****s 的大作中提到】
: 很多时候线程不是为了效率。也不是为了fancy。而是为了降低编程难度。
: 有些routine过一段时间就要执行一次，如果不用线程或者进程，而直接参到主进程里
: ，会让程序构造变得很复杂的。
|
|
|
x****u
发帖数: 44466 | 41 是啊，而且单核下搞多线程，结果是实时性更差，更无法满足要求。
这时候标准玩法就是中断外设，在指定毫秒发一个中断。
【在 s********k 的大作中提到】
: 非也，多线程再怎么也比poll based复杂，尤其考虑到各种同步的情况，消耗资源多数
: 情况下也比poll多。我看大多数资源有限情况下，一个BG的poll和FG的INT就可以了。
: 多线程用在极其成熟的RTOS，比如ucOS还可以
|
s********k
发帖数: 6180 | 42 对于过一段时间就要执行一次routine，放在poll不同的进程没有任何复杂度啊，这种
大多数都是event based，如果该进程没有event，直接跳过。
【在 t*****s 的大作中提到】
: 很多时候线程不是为了效率。也不是为了fancy。而是为了降低编程难度。
: 有些routine过一段时间就要执行一次，如果不用线程或者进程，而直接参到主进程里
: ，会让程序构造变得很复杂的。
|
c*******2
发帖数: 66 | 43 补充一点。嵌入式开发者的学习要从行业应用和生态环境入手，big picture, and top
down. 相反,对要创业的, 学习要刻意的Bottom up，仰卧起坐，直到两眼发直口吐白
沫。LoL
【在 c*******2 的大作中提到】
: 弄一块带Zigbee的8051,或者Zigbee连Arduino的板子，最好还通过DAC连机械驱动装置
: 的,先试试手. 玩起来再说。
|
h**i
发帖数: 712 | 44 我觉得你们说的不是同一个东西，有些arch自己带core timer可以定时中断，但不是
RTC。嵌入式RTC都是单独一个chip，极低功耗的可以集成用电池供电。
【在 x****u 的大作中提到】
: 能引发定时中断的东西就是RTC，你不是说没有RTC么？
: 当然可以把部分外设集成到CPU内，但在体系结构上这些东西还是外设。
: 如果这个时钟仅限于counter不可以编程，那还是没办法单核多任务啊，切换必须要靠
: 时钟中断，或者当前任务主动放弃执行权。
|
n******t
发帖数: 4406 | 45 这种事情就是看怎么定义这个嵌入式了。
微波炉那种，和Mp3 player之类的还是不一样的。
poll 最大的问题是稍微复杂一点的应用，就不好写了。
【在 s********k 的大作中提到】
: 非也，多线程再怎么也比poll based复杂，尤其考虑到各种同步的情况，消耗资源多数
: 情况下也比poll多。我看大多数资源有限情况下，一个BG的poll和FG的INT就可以了。
: 多线程用在极其成熟的RTOS，比如ucOS还可以
|
b***i
发帖数: 3043 | 46 就是，不同需求不同设计。现在有容易使用的OS为啥不用呢？我说不定还要上java。没
有条件就是创造条件也要上。
【在 n******t 的大作中提到】
: 这种事情就是看怎么定义这个嵌入式了。
: 微波炉那种，和Mp3 player之类的还是不一样的。
: poll 最大的问题是稍微复杂一点的应用，就不好写了。
|
t*****s
发帖数: 416 | 47 牺牲性能我同意。复杂就不一定了。比如不需要同步的情况下用线程一定是更方便的。
【在 s********k 的大作中提到】
: 非也，多线程再怎么也比poll based复杂，尤其考虑到各种同步的情况，消耗资源多数
: 情况下也比poll多。我看大多数资源有限情况下，一个BG的poll和FG的INT就可以了。
: 多线程用在极其成熟的RTOS，比如ucOS还可以
|
x****u
发帖数: 44466 | 48 线程是共享线性空间的，一个东西出了问题可能是别的线程引起的，调试起来非常麻烦。
【在 t*****s 的大作中提到】
: 牺牲性能我同意。复杂就不一定了。比如不需要同步的情况下用线程一定是更方便的。
|
t*****s
发帖数: 416 | 49 不需要同步的情况就不可能出现你说的问题。
烦。
【在 x****u 的大作中提到】
: 线程是共享线性空间的，一个东西出了问题可能是别的线程引起的，调试起来非常麻烦。
|
x****u
发帖数: 44466 | 50 线程啊亲，一个溢出了造成另一个崩溃是太常有的事情了。
【在 t*****s 的大作中提到】
: 不需要同步的情况就不可能出现你说的问题。
:
: 烦。
|
|
|
t*****s
发帖数: 416 | 51 这话一点意义都没。
你代码既然要溢出，你不用线程放一起跑就不崩溃了？
【在 x****u 的大作中提到】
: 线程啊亲，一个溢出了造成另一个崩溃是太常有的事情了。
|
x****u
发帖数: 44466 | 52 用多进程就不会有此问题
另外单线程加中断时，再现时也简单不少。
【在 t*****s 的大作中提到】
: 这话一点意义都没。
: 你代码既然要溢出，你不用线程放一起跑就不崩溃了？
|
t*****s
发帖数: 416 | 53 我开始说线程是针对他说能不用就不用说的。你搞个进程不是跑的更远么……
poll有方便的场景，中断也有。但是还是有场景确实就是线程最合适的。
【在 x****u 的大作中提到】
: 用多进程就不会有此问题
: 另外单线程加中断时，再现时也简单不少。
|
x****u
发帖数: 44466 | 54 当然有啊但你说的不是。
比如说webserver，用线程池处理io就既简单效率又高。
【在 t*****s 的大作中提到】
: 我开始说线程是针对他说能不用就不用说的。你搞个进程不是跑的更远么……
: poll有方便的场景，中断也有。但是还是有场景确实就是线程最合适的。
|
t*****s
发帖数: 416 | 55 唉。
不是就不是吧。让你得到点否定我的快感。
【在 x****u 的大作中提到】
: 当然有啊但你说的不是。
: 比如说webserver，用线程池处理io就既简单效率又高。
|
n******t
发帖数: 4406 | 56 webserver用线程池效率高？？？？
感觉你不靠谱啊。
【在 x****u 的大作中提到】
: 当然有啊但你说的不是。
: 比如说webserver，用线程池处理io就既简单效率又高。
|
x****u
发帖数: 44466 | 57 OS创建新线程时的开销你研究过么？是不是除了APUE上面的例子外你就没看过程序？
【在 n******t 的大作中提到】
: webserver用线程池效率高？？？？
: 感觉你不靠谱啊。
|
p*u
发帖数: 2454 | 58
epoll is much more scalable then thread pool
【在 x****u 的大作中提到】
: OS创建新线程时的开销你研究过么？是不是除了APUE上面的例子外你就没看过程序？
|
x****u
发帖数: 44466 | 59 两回事。这不就是Windows下早就有了的completion port么？多工作线程省不掉。
【在 p*u 的大作中提到】
:
: epoll is much more scalable then thread pool
|
