The end address of SlicingBlockDevice

Hi,

I ran into some issues when using SlicingBlockDevice, wonder if the problem was caused by the wrong end_addr I passed into the constructor. Suppose I have a 256 byte underlining BlcokDevice, and want to create two SlicingBlockDevice each which has 128 byte. Should I pass 128, 256 or 127, 255?

BlockDevice bd; // Total size of 256B
SlicingBlcokDevice sBd1(&bd, 0, 128/* or 127*/);
SlicingBlockDevice sBd2(&bd, 128,  256/* or 255*/);

The documentation quoted below and example code doesn’t seem clear to me on this.

End block address to mark the end of the block device, this block is not mapped, negative addresses are calculated from the end of the underlying block device. The default stops at end of the underlying block device.

Please advise.
ZL

Looking at this function:

bool SlicingBlockDevice::is_valid_read(bd_addr_t addr, bd_size_t size) const
{
    return _bd->is_valid_read(_start + addr, size) && _start + addr + size <= _stop;
}

since it’s using <=, that implies that the stop address is non-inclusive. Since in your example, it would be comparing 0 + addr + size <= 128, and we would want a 1-byte read at address 127 to be allowed.

So it should be

SlicingBlockDevice sBd1(&bd, 0, 128);
SlicingBlockDevice sBd2(&bd, 128,  256);

I would love a PR to Mbed CE to make these docs clearer!

1 Like

Thanks for pointing to the source code for SlicingBlockDevice. I tried to find it but quickly gave up. I will submit a PR later.

For now I’ve got to win the fight against dying Ethernet port on Mbed boards. Welcome to view the question on StackOverflow.

Replying for the updates.