The datasheet does not express that matter very precise. I would suggest you to run a short test and inform us about the result.
Nick, The count7 should be enabled (both in hardware and software) for the load input to be valid.
Wouldn't this be worth a clarification in the datasheet? Like "The Count7 has to be up and running..."
Excellent - thanks for the reply. I thought it probably needed both hardware and software enabled (or I suppose the hardware enable would be labelled "count" instead). Testing this offers some challenges on my current system configuration, so it's good to have a definite response!
EDIT: I would advocate clarification in the datasheet too!
I'm now quite confused! I couldn't get the Count7 component to work in my UDB editor design at all. I resorted to redesigning the component using the datapath's A1 as my bit counter however this requires two states per shift (one to do the actual shift operation, and the other to decrement A1). Now I have a working design however, I decided to attempt to incorporate the Count7 again.
I've defined a "LoadCounter" variable as "(SPIStates == LoadTxDat) | (SPIStates == Load0xFF)..." to activate the load signal on the necessary states,and an "EnableCounter" variable as "LoadCounter | (SPIStates == SendDone)" to enable the counter on the relevant states. These are both combinatorial signals. Despite not having changed any of the rest of the design (I'm not using the counter TC output yet), the design no longer works. If I delete the counter it works again.
I've tried running the Start() API for the counter and it's made no difference, so now I'm left wondering how adding a Count7 affects the UDB component. Are there any known issues with the Count7 component? Do my variable declarations have side effects on the signals I use?
I'll admit I'm hoping someone has a useful hint without my having to learn Verilog, but I'm beginning to think Verilog might be my only option...
It's only the LoadCounter signal that's a problem. If it's set to 1'b1, my component appears to get "stuck", but if I set it to 1'b0 things work as expected - perhaps I need another read of the documentation!
What do you think about posting your project with the results you made so far? Would clarify which way you interact your "UDB Editor" with a count7 - component. To do so, use
Creator->File->Create Workspace Bundle (minimal)
and attach the resulting file.
It's a rather large collection of code and experiments now! If you want a look though, I will post it. Just promise not to make too much fun of my code :)
I've actually got things working now, and have an inkling as to what was going on. To set the background, the component I'm designing is an SPI interface specifically for SD cards with the aim of implementing DMA easily, and interfacing it with the FatFS library. Version 1 used a standard SPI component with a fairly large amount of questionable logic attached to implement DMA receive without having to worry about the sticky-bits in the SPI component status registers. The UDB version is intended to use fewer resources and allow TX and RX DMAs.
Whenever a byte is sent, obviously, one is received. The state machine starts to send as soon as a byte appears in the input (TX) FIFO then an interrupt is generated directly from "F1 bus status (not empty)" when my bit counter loads a complete received byte in my output FIFO (F1). I had the FIFOs set up on the BUS_CLK (fast mode as I understood), and it was working a treat, although at a lower UDB clock speed than I'd expected.
To compile a file to post here, I decided to remove a few surplus components I was experimenting with, and afterwards discovered even my working design had stopped working! I've had this before when resources get swapped around on a recompile.
Following the scent of timing issues, I changed the FIFO fast mode to DATAPATH_CLOCK, and now I can run the interface at the maximum speed I expected. On top of that, I've successfully incorporated the Count7 component, and can now look into removing that pesky extra decrement state. I think I need to find a good explanation of the FIFO fast mode setting somewhere.
Anyway, if you're curious, let me know and I'll post the project (thanks for pointing out that very useful way to package a project by the way)
There are some usefull bits (bytes) and pieces within a single UDB, for instance some (registered) PLD.
Just by defining in VeriLog a 3-bit wide register and adding one to its value at every clock cycle will make up your needed bit-counter which can be compared to be zero (or any other value) and so forcing the contents of the ALU into the FIFO,
What I wanted to say in my not so plain words is: You can get araound easily when speaking different languages, even VeriLog.
I would greatly GREATLY appreciate it if you could post your project. I am looking for a way to communicate with my sdccard using DMA and fatfs is fine for me. I am currently working on the exact same thing with no luck so far and I can even further your design by creating that verilog component Bob has suggested, I have a similar one already in the project I'm looking to implement your design into.
I had no idea there'd been a response to this thread until now! Sorry. I believe a complete, minimal example project can be found at:
I was managing about 1.8 Mbps read speed if I recall correctly... If you have a look at my other projects you should find my FatFS code::blocks project too - you'll have to link code::blocks to the GCC compiler provided with the PSoC Creator to compile it, but this will allow you to fiddle with the configuration of FatFS to suit your needs.
EDIT: I should add that if you reconfigure FatFS, you copy the .a library into the library folder of the NSDSPI component, and will have to update the header file in the API folder to match your configuration.
EDIT2: After testing the project again, I've found that my maximum read speed was 1.8 MBps, not Mbps!