NI SPEEDY 33: How to write data to flash interface and use this board as USB host?

[modestt]

these questions ideally go to a NI systems Engineer, but I would really appreciate help from any NI SPEEDY user.

1) how to write user data to Compact flash interface ? how to access the add on flash on the board ?

2) how to use this board as USB host ?

[pjtanz]

Hello,

I have attempted to answer your questions below:

1) how to write user data to Compact flash interface ? How to access the add on flash on the board ?

On the NI SPEEDY-33 hardware, there currently is an unpopulated footprint for a CompactFlash card interface.  However, LabVIEW DSP does not currently provide an API to the flash, and thus, there is not an easy way to access it.  That said, this is not an impossibility...  we could provide you with a nudge in the right direction.  This would require a pretty significant amount of work from you, though.

2) how to use this board as USB host ?

I like to think of the USB Host port on the NI SPEEDY-33 as a "failed experiment".  Since the code that is necessary to perform USB communication is pretty dense, it ended up taking being too large for the board and rendered the board virtually unusable.  Thus, we do not support the USB host port.

I hope that this has been helpful.

Regards,

P.J.

LabVIEW DSP R&D

[modestt]

hello P.J,

that was very helpful. couple more queries:

i understand that there is no easy way to write data to add on flash, but can we write data to system onboard Flash( the one on which code resides) ? just in a form of simple CSV files ? if that is the case, is there a way to read those files from Board using PC ?

i appreciate ur help 🙂

Thanks

Ahmed

[pjtanz]

Hi Ahmed,

There is a way to write to the onboard flash one byte at a time using the Elemental I/O blocks, but there is a caveat.  One of the LabVIEW DSP developers uses a really nice analogy that I will steal here.  Imagine that the bits of the onboard flash are like bowling pins.  When the flash is cleared, all of the pins are set up.  As you write to memory locations, you knock pins down selectively.  Once they're are down, the only way to bring them back up is to clear the flash again.  The result of this is that you can only write to a memory location once.  You can read this data any number of times, but in order to write a new value, you need to clear all of the data first and you will lose what is in the rest of flash.

I hope that this answres your question.

Regards,

P.J.

[modestt]

hello PJ,

that was incredibly helpful. So that's what i understood from your email.

we can write data such as CSV files or some other format, one byte at a time to on board flash. Once filled up, we need to reset the whole flash and that will also reset the code residing on flash. Here are questions that i can think of:

1) how would i know the legitimate address on which data can be written ? Since in stand alone mode, the code also resides on same flash and with no base address discrimination scheme, its very easy to corrupt the flash.

2) will the flash write function will let us know that the write was successful ? in case of flash full or unsuccessful write operation.

Thanks for all ur help.

ahmed

[pjtanz]

Hi Ahmed...

Here are the answers to your questions...

1) how would i know the legitimate address on which data can be written ? Since in stand alone mode, the code also resides on same flash and with no base address discrimination scheme, its very easy to corrupt the flash.

This is true.  The answer is, really, you don't know and could corrupt your flash unless you're REALLY careful.   These Elemental I/O memory peeks and pokes were intended to be used to read and write registers, not program data.   

2) will the flash write function will let us know that the write was successful ? in case of flash full or unsuccessful write operation.

No.  There is no indication.  Keep in mind that this approach is neither the intended nor recommended use of this functionality.

I would discourage you from continuing down this path unless it is absolutely your only option.  I think that your very reasonable questions demonstrate just a couple of the many ways that you could make a simple mistake and crash your application by writing the wrong memory address...

Regards,
P.J.