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命令了,但是管道的支持倒并不怎么靠谱,所以还是要慎用。

相关文章

发表新评论