remove arbitrary timing loops

[gtoal]

I'm not sure if this is really a bug report or an enhancement request;

Suggestion: use arm cycle count register for accurate short timings rather than timing loops which may be cache dependent.

mov   r6,#10                // <- Oscillator frequency dependent magic number here!!
waitdataloop:
subs  r6,#1
bne   waitdataloop

3.4.28. c15, Cycle Counter Register (CCNT) The Cycle Counter Register counts the processor clock cycles. It is a 32-bit counter that can trigger an interrupt on overflow. You can use it in conjunction with the Performance Monitor Control Register and the two Counter Registers to provide a variety of useful metrics that enable you to optimize system performance.

You can access the Cycle Counter Register by reading or writing CP15 c15 with the Opcode_2 field set to 1:

MRC p15, 0, , c15, c12, 1 ; Read Cycle Counter Register MCR p15, 0, , c15, c12, 1 ; Write Cycle Counter Register The value in the Cycle Counter Register is Unpredictable at Reset. The counter can be set to zero by the Performance Monitor Control Register.

The Cycle Counter Register can be configured to count every 64th clock cycle by the Performance Monitor Control Register.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/BIHCGFCF.html

[technobly]

I have recently disabled the Sys_Tick_Handler in favor of the DWT hardware cycle counter to do short timing and delays... so we are most of the way there :D Cycle count is still oscillator dependent though, so I think these little magic timing values will always be an issue if we want the code to be tight. The other way to do it is to create a hardware timer that is always set to something useful like 1us that gets clocked based on initial setup (reload value) and MCU oscillator value... but it still wouldn't be useful for the super tight timing delay you referenced above.

[technobly]

Here's the appropriate ARM reference section for VEXTREME as well, Cortex-M4... and the section on DWT: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100166_0001_04_en/ric1417175910926.html

[technobly]

@gtoal good news! This was resolved without weird timers... turns out the Vectrex gives us all of the timing info we need already, just have to monitor the right signals. Fixed in PR #61 here: https://github.com/technobly/VEXTREME/pull/61/files#diff-d5f45277bf3d94a2cc5369b788f6ffdfR197-R203