Windows命令行呀，想说爱你不容易
最近依然还是在搞内个HAPS FPGA，在准备ROM更新FPGA bit文件相关工具的时候，碰到了一个非常奇怪的问题。我们先来看看问题是什么样子的。
问题描述
在更新FPGA bit中ROM的程序的时候，我们一般不能直接用elf文件，因为elf文件中会有一些我们无法用到的偏移信息，所以我们需要用一个自定义的脚本产生相应的mem文件，然后通过这个mem文件更新我们的FPGA bit文件。mem文件其实就是一个包含可读十六进制数据的一个文件，为了避免引入数据偏移，我写了一个Python的脚本，这个脚本可以直接把ROM程序的bin文件转换为mem文件，因为bin文件默认是没有偏移的，所以刚好可以满足我们的需要。
这里用到的Python文件如下：
#!/usr/bin/env python3
# -*- coding=utf8 -*-
import sys
import struct
with open(sys.argv[1], "rb") as f:
byte = f.read(1)
d.write("@00000000\n")
i = 0
while byte:
d.write("{:0>2X} ".format(struct.unpack('B', byte)[0]))
byte = f.read(1)
if (i % 32 == 31):
d.write("\n")
i += 1脚本非常简单，使用的时候一般通过管道将结果输出到文件：
python bin2mem.py rom.bin > rom.mem这里为了方便就直接使用了管道，将输出结果直接生成到文件，程序运行下来，产生的mem文件看起来没啥问题。不过奇怪的是updatemem这个工具不认生成的mem文件。具体原因呢？
原因分析
数据对比什么的也没什么问题，难道是mem文件有啥问题导致？偶然间我发现生成的mem文件似乎有点大，难道是格式有问题？没啥思路，难不成是powershell中管道的输出格式不正常？应该会有ASCII和UTF的问题，为了验证这个问题，我在bash中又运行了类似的测试，结果发现bash中生成的mem是可以正常使用的。看来真的是编码的问题，真是巨坑呀。
脚本更新
既然是管道之后数据格式有问题，索性就直接不用管道了，这里我们对原来的脚本进行了修改，新的脚本可以正常产生mem文件。
#!/usr/bin/env python3
# -*- coding=utf8 -*-
import sys
import struct
with open(sys.argv[1], "rb") as f:
with open(sys.argv[2], "w") as d:
byte = f.read(1)
d.write("@00000000\n")
i = 0
while byte:
d.write("{:0>2X} ".format(struct.unpack('B', byte)[0]))
byte = f.read(1)
if (i % 32 == 31):
d.write("\n")
i += 1新的脚本直接写目标文件，绕开了管道，结果看起来就没啥问题了。
总结
微软的东西现在看起来还是有挺大的问题呀，虽然powershell可以支持很多Linux命令了，但是管道的支持倒并不怎么靠谱，所以还是要慎用。
最后更新于 2019-11-22 15:00:00 并被添加「FPGA Windows 命令行」标签，已有 2483 位童鞋阅读过。
本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。