KryoFlux - Need More Power?

2009-07-13

Generally USB is unreliable on some boards, and apparently this is a known problem. The Ukrainian board we have is particularly bad as one not-so-important USB feature does not work at all due to missing circuitry, and possibly using a PCB that was meant for a different chip in the first place. It’s not a big thing, just annoying.

For HD disks we may need something faster or at least with more on-board RAM to do it reliably. It might just (barely) work if there are no showstoppers in USB communication - we’ll see. Whatever happens, an assembly version is completely off the cards - that is just not going to happen.

The dumping/communication mechanism still has to be worked out, it should be very reliable and remain the same no matter what hardware we migrate to. Doing things that look promising instead of doing something within constraints is good for prototyping, but may not be so good for production use.

Note that timing is very tight even for DD disks. If anything goes wrong there is no room for retry, you have to restart as the USB buffer fills up, and there is not enough buffer space to assume everything will just be okay. So it’s quite possible that the host side would retry to dump a track several times if for example, you run something on the PC that made its USB communication slower for just a few milliseconds... certainly not very nice.

In hardware it is pretty normal to go for the cheapest solution that looks good on paper, and if problems arise (like they do here) simply move onto the second cheapest option and so on... Practically endless iterations until you have something that barely works according to specifications and still has the lowest possible cost associated. It’s understandable when you are thinking of millions of units and even one dollar cost saved per unit would save millions, compared to maybe a few tens of thousands of additional engineering cost. However we are talking about hundreds of units at most here, so realistically the engineering cost is much higher than the gain in production.

Anyway, it’s not time completely wasted, but getting the board to do something it just cannot do is time wasted. We need to see how far it can be pushed, and if the result is unacceptable we will just completely abandon it. If it is only good for DD disks, we will mark it as such, then move to other hardware for HD.

(later)

What is the point in continuing to struggle with the current hardware? What about using the Beagle Board?

It certainly has:

Plenty of on-board RAM
Fast USB
600 MHz clock speed, compared to 48 MHz we have to work with

What is unclear is whether the GPIO interface is fully suitable. It should be, but probably better not to say until we can test real hardware. So, we thought, should we stop mucking about and just get a Beagle Board?

The main drawback of going with one is the price, even with it is subsidised, it is far more expensive than the little devices we are currently using. We want this thing to be widely used, and certainly the cost of the Beagle will restrict that.

So we will continue to struggle with the current boards to see if it can be made to work reliably with DD disks. The code will be very similar on any board, and we don’t have any other boards right now. The Beagle is ARM based as well (this one is ARM7TDMI, Beagle is ARM Cortex A8, a much improved version of ARM7 with vector instructions etc.), and will need fast IRQ servicing - although not that badly as this one does.

So, yes, we will continue with what we have for development purposes and order and build the new boards while the software is being worked on.

(later still)

The board has 64 KiB, but that SRAM is shared between your code, data and stack, including the buffers you need for dumping and communication. In the end, you might get about 32 KiB for buffers if you are careful with compiler options. We could flash our code, but that is a non-option for development and also awkward for users.

So, just to make it clear, these ATMEL-based boards do not have enough RAM for one revolution of data, and multiple revolutions of data are required from a single continuous read in order to get the data needed. What happens is that it starts to read data and sends it over USB. If anything goes wrong, it is just unlucky. The USB buffer overflows, and there is no way to recover since data got lost. You must restart... until you are lucky enough to get the USB flowing uninterrupted.

Think of it like the original CD writers. Stability is on par with the very early ones from the 90s, basically non-existent. They do the same thing, but just for writing only - we have to do it for both reading and writing.

(later again)

Good news. We finally forced GCC (after re-reading the latest manual of GCC and make) to compile an ARM specific fast IRQ routine that is pretty much identical to what anyone would write in assembly:

void DiskReadIrq() 
{ 
  static int z=0; 
  z++; 
}

Produces:

70 .loc 1 6 0 
71 ldr r8, .L3 @ tmp133, 
72 ldr ip, [r8, #0] @ z, z 
73 add ip, ip, #1 @ tmp136, z, 
74 str ip, [r8, #0] @ tmp136, z 
75 0000 00000000 .loc 1 7 0 
76 subs pc, lr, #4 @

This can help to save quite a few cycles per bit cell... without doing assembly.

The master plan is to make it super-fast and simple since the timing of bitcells could be anything and put real processing work only into the main thread instead. The main thread will be free running whenever there is new input from the interrupt buffer.

However since USB communication can be blocked at any time (one of the main obstacles without RAM) the main thread will generate data into an USB buffer first, and that will get flushed whenever and as often as possible.

For those who are interested, this will make it fairly complex, with two lockless free-running ring buffers.