包含GO语言写刮削器的词条

【原创】树莓派3B开发Go语言（四）-自写库实现pwm输出

在前一小节中介绍了点亮第一个LED灯，这里我们准备进阶尝试下，输出第一段PWM波形。（PWM也就是脉宽调制，一种可调占空比的技术，得到的效果就是：如果用示波器测量引脚会发现有方波输出，而且高电平、低电平的时间是可调的。）

为平南等地区用户提供了全套网页设计制作服务，及平南网站建设行业解决方案。主营业务为网站设计制作、成都网站制作、平南网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！

这里爪爪熊准备写成一个golang的库，并开源到github上，后续更新将直接更新到github中，如果你有兴趣可以和我联系。 github.com/dpawsbear/bear_rpi_go

我在很多的教程中都看到说树莓派的PWM（硬件）只有一个GPIO能够输出，就是 GPIO1 。这可是不小的打击，因为我想使用至少四个 PWM ，还是不死心，想通过硬件手册上找寻蛛丝马迹，看看究竟怎么回事。

手册上找寻东西稍等下讲述，这里先提供一种方法测试 树莓派3B 的 PWM 方法：用指令控制硬件PWM。

这里通过指令的方式掌握了基本的pwm设置技巧，决定去翻一下手册看看到底PWM怎么回事，这里因为没有 BCM2837 的手册，根据之前文章引用官网所说， BCM2835 和 BCM2837 应该是一样的。这里我们直接翻阅 BCM2835 的手册，直接找到 PWM 章节。找到了如下图：

图中可以看到在博通的命名规则中 GPIO 12、13、18、19、40、41、45、52、53 均可以作为PWM输出。但是只有两路PWM0 PWM1。根据我之前所学知识，不出意外应该是PWM0 和 PWM1可以输出不一样的占空比，但是频率应该是一样的。因为没有示波器，暂时不好测试。先找到下面对应图：

根据以上两个图对比可以发现如下规律：

对照上面的表可以看出从 BCM2837 中印出来的能够使用在PWM上的就这几个了。

为了验证个人猜想是否正确，这里先直接使用指令的模式，模拟配置下是否能够正常输出。

通过上面一系列指令模拟发现，（GPIO1、GPIO26）、（GPIO23、GPIO24）是绑定在一起的，调节任意一个，另外一个也会发生变化。也即是PWM0、PWM1虽然输出了两路，可以理解成两路其实都是连在一个输出口上。这里由于没有示波器或者逻辑分析仪这类设备（仅有一个LED灯），所以测试很简陋，下一步是使用示波器这类东西对频率以及信号稳定性进行下测试。

小节：树莓派具有四路硬件输出PWM能力，但是四路中只能输出两个独立（占空比独立）的PWM，同时四路输出的频率均是恒定的。

上面大概了解清楚了树莓派3B的PWM结构，接下来就是探究如何使用Go语言进行设置。

因为拿到了手册，这里我想直接操作寄存器的方式进行设置，也是顺便学习下Go语言处理寄存器的过程。首先需要拿到pwm 系列寄存器的基地址，但是翻了一圈手册，发现只有偏移，没有找到基地址。

经过了一段时间的努力后，决定写一个 树莓派3B golang包开源放在github上，只需要写相关程序进行调用就可以了，以下是相关demo（pwm）（在GPIO.12 上输出PWM波，放上LED灯会有呼吸灯的效果，具体多少频率还没有进行测试）

以下是demo(pwm) 源码

听说Java不适合写外挂，那么go语言适合吗？？？为什么？

因为Java是以沙箱机制运行的，进程间隔离，要想用Java写外挂也不是完全不可以，只是先得用C/C++编写注入程序（通常是动态链接库），然后用JNI方式编写其Java扩展。

至于Go语言，不太了解。但是外挂主要是指ABI层次的，和语言无关，只要一种语言的调用约定符合你要注入的程序的调用约定（以Windows为例就是WindowsAPI）都可以的（Java就是和C语言的调用约定不同所以不能直接写外挂）。

关于注入的技巧，可以中搜这个文章

Three

Ways

to

Inject

Your

Code

into

Another

Process

或中文《注入代码的

3

种方法》

Go语言设计与实现（上）

基本设计思路：

类型转换、类型断言、动态派发。iface，eface。

反射对象具有的方法：

编译优化：

内部实现：

实现 Context 接口有以下几个类型（空实现就忽略了）：

互斥锁的控制逻辑：

设计思路：

（以上为写被读阻塞，下面是读被写阻塞）

总结，读写锁的设计还是非常巧妙的：

设计思路：

WaitGroup 有三个暴露的函数:

部件：

设计思路：

结构：

Once 只暴露了一个方法：

实现：

三个关键点：

细节：

让多协程任务的开始执行时间可控（按顺序或归一）。（Context 是控制结束时间）

设计思路： 通过一个锁和内置的 notifyList 队列实现，Wait() 会生成票据，并将等待协程信息加入链表中，等待控制协程中发送信号通知一个（Signal()）或所有（Boardcast()）等待者（内部实现是通过票据通知的）来控制协程解除阻塞。

暴露四个函数：

实现细节：

部件：

包： golang.org/x/sync/errgroup

作用：开启 func() error 函数签名的协程，在同 Group 下协程并发执行过程并收集首次 err 错误。通过 Context 的传入，还可以控制在首次 err 出现时就终止组内各协程。

设计思路：

结构：

暴露的方法：

实现细节：

注意问题：

包： "golang.org/x/sync/semaphore"

作用：排队借资源（如钱，有借有还）的一种场景。此包相当于对底层信号量的一种暴露。

设计思路：有一定数量的资源 Weight，每一个 waiter 携带一个 channel 和要借的数量 n。通过队列排队执行借贷。

结构：

暴露方法：

细节：

部件：

细节：

包： "golang.org/x/sync/singleflight"

作用：防击穿。瞬时的相同请求只调用一次，response 被所有相同请求共享。

设计思路：按请求的 key 分组（一个 *call 是一个组，用 map 映射存储组），每个组只进行一次访问，组内每个协程会获得对应结果的一个拷贝。

结构：

逻辑：

细节：

部件：

如有错误，请批评指正。

2021-05-12 GO 与C#代码行对比

最近在做一个内网穿透工具，是用C# Dotnet Core写的。 总担心性能不行，想参考下别人写的。 结果搜到很多GO语言的例子。 看了下Go语言的介绍，觉得确实是比较简单的语言。并且在并发上比较方便。于是，就开始学习Go语言，并用Go把内网穿透工具重新写了一下。

然后，又想用Go语言重写之前的DotnetCore的WebAPI，现在还在编写中，只是对比下两个语言差异。

然后看下 C#

实际上目前我也没有能力判断GO和C#哪个更好