ESPUSB - Chat about the software components

User avatar
By RichardS
#53020 I think CNLOHR is more concerned right now with how long it takes to react to a bit then to send a bit...

RichardS
User avatar
By cnlohr
#53034 @RichardS: Yes, unfortunately that is the case.

@Rudi I did not see the german posts until you linked them... But, I did not have any problems synthesising the 12 MHz signal out. By stippling the data, 13, 13, 14 clocks, (40 clocks total @ 160 MHz = 4MHz * 3 = 12 MHz). So long as NO NON-CORE-MEMORY operations are made after the "write" to the GPIO registers, there does not appear to be any waiting, so there's tons of time to do processing between writes. If another "write" is issued in under (12?) cycles, it will halt the processor until the first write completed.

I was going to use the same technique to read... But, it seems as soon as you issue a read the entire processor halts, even if you don't use the data you read until many cycles later. Maybe I'm just doing something wrong?
User avatar
By RichardS
#53081 We need @projectgus to help here again :-) it seems very slow, there is something up!

RichardS
User avatar
By projectgus
#53115 Hi everyone,

A few things, that I think explain most of what's going on here:

* GPIOs hang off a peripheral bus (APB I'm fairly sure). Peripheral bus is slower than the CPU, I'm fairly sure default speed is half the standard CPU speed so 40MHz. Even when CPU speed is doubled to 160MHz, this bus stays at 40MHz (the doubling only effects CPU clock). So 17 CPU cycles @ 160MHz is 4 peripheral bus cycles, plus 1 CPU cycle.

* From what you're reporting, writes seem to take ~13 CPU cycles @ 160MHz. So one peripheral bus cycle less than reads. There might be a way to equalise this timing for reads (maybe by reading a different register), but it's probably a hardware limitation.

* More serious is the problem where the CPU stalls on a read until it's complete. Unfortunately I'm 99% sure this is a CPU design limitation. LX106 CPU has a single entry write buffer (you see this option mentioned in the Xtensa ISA manual, and the lx106-hal contains "XCHAL_NUM_WRITEBUFFER_ENTRIES 1"). This means that a write is buffered by the CPU, so it can do other things until the write completes. This is why you get 12 extra CPU cycles when you write to a GPIO register, the write buffer is handling this write and the CPU can do anything else which doesn't also trigger a bus write.

(BTW, this buffering is also one of the use cases for the MEMW instruction - when you need to know that writes are actually complete before you can continue.)

* The bad news is, there is no equivalent "read buffer" in LX106 - if you read from memory, the CPU doesn't continue until the read is complete. This is why you're seeing 17 cycles to complete a load.

I don't know of a way around this. I think it's the kind of use case (bit-banging GPIO reads at >10MHz) that noone really thought would exist, so it's not been designed for. The design of the CPU considers that it's more important that registers have read correct values before the CPU executes the next instruction. Sorry!

When I get a chance I will double-check you can't clock the GPIO's bus any higher, but I'm 99% sure this isn't possible (and even if it is possible, doing it will probably break other peripherals.)