New feature: "unique-id".

[pkoning2]

This returns the board unique ID on Raspberry Pico boards, as a 64 bit value.

See https://github.com/tabemann/zeptoforth/discussions/45

[tabemann]

Is there any reason you are returning the value as a 64 bit value (i.e. throwing 32 bits away) rather than returning the value as a 96 bit value?

[pkoning2]

Is there any reason you are returning the value as a 64 bit value (i.e. throwing 32 bits away) rather than returning the value as a 96 bit value?

It is actually a 64 bit value, the last 8 cycles. It's SPI so for every byte sent we also receive a byte. The operation uses 13 cycles: the first sends the command, the next four are unused in both directions, and the last 8 are the data. It turns out to take less memory to do a loop for 12 cycles into a 3 word buffer than to discard those 4 bytes explicitly and use a 2 word buffer, so that's how I wrote it. By the way, I have an existing Pico program that uses the unique ID, via the C API from Raspberry. I changed that program to display the value it obtained, and compared it with what I get here. They match. You can actually see the extra 32 bits if you do sysclk dup 16 + dump -- it turns out they are all $FF which makes sense because the data sheet shows the input line tristated for those cycles.

[tabemann]

And I should have simply looked this up and confirmed that the value is indeed 64-bit... I'll approve your change once I get home from work.

Thanks,

Travis

On Thu, Jan 11, 2024, 08:16 Paul Koning @.***> wrote:

Is there any reason you are returning the value as a 64 bit value (i.e. throwing 32 bits away) rather than returning the value as a 96 bit value?

It is actually a 64 bit value, the last 8 cycles. It's SPI so for every byte sent we also receive a byte. The operation uses 13 cycles: the first sends the command, the next four are unused in both directions, and the last 8 are the data. It turns out to take less memory to do a loop for 12 cycles into a 3 word buffer than to discard those 4 bytes explicitly and use a 2 word buffer, so that's how I wrote it. By the way, I have an existing Pico program that uses the unique ID, via the C API from Raspberry. I changed that program to display the value it obtained, and compared it with what I get here. They match. You can actually see the extra 32 bits if you do sysclk dup 16 + dump -- it turns out they are all $FF which makes sense because the data sheet shows the input line tristated for those cycles.

— Reply to this email directly, view it on GitHub https://github.com/tabemann/zeptoforth/pull/85#issuecomment-1887263496, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDMC2GIYJN3K6J3ZXIA2DTYN7X25AVCNFSM6AAAAABBVN36VGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBXGI3DGNBZGY . You are receiving this because you commented.Message ID: @.***>