This might be considered "salami pricing". The company I used to work for made a product to read electrical power meters. They also made a reader/programmer to program these same meters. The reader sold for $3000 and the reader/programmer for $5000. I worked on this line of products so I knew the only difference was the code contained in the eprom that told the unit what to do. I asked a marketing representative how they could justify charging that big difference for basically no physical difference and he told me they were charging for functionality.
People don't want to buy a quarter-inch drill; they want a quarter-inch hole.
I have already a few ideas about implementation of such configuration especially about its DSP part. But now it's time for me going on vacation so I can start this work only as early as end of the March / beginning of the April. So you could consider any new desired functionality for a while and then I try implement it later if possible.
Of course without fremen participation all that could not be possible as I am not familiar with FP MCU programming and debugging.
GREAT, going to try this asap. Thanks fremen. Willing to post the source?
@fremen67 Will the new FW run on the FeelTech FP or is it just a PC UI at this stage? It looks very nice. I got the impression it was PC only, but I've been more focused on my Zynq adventures and haven't kept up
As I read PM0075 p 19, although the flash is read protected, we can force a mass erase and reprogram the device. Is that correct?
I've ordered a couple of the ST Link programmers from eBay. I'm sure I could use one of my dev boards, but when I saw yours I went looking and at $2.54 decided it was well worth having a couple.
GREAT, going to try this asap. Thanks fremen. Willing to post the source?Thank you! Waiting for your feedback. As soon as it is stable, I will open a github and post the source. I am still working on this version right now. I should have waited some more days to finish it but it is the week-end and I know you want homework
Thanks for your kind words!
About CYCLONE configuration. I am pretty sure there isn't NIOS processor inside the configuration. It needs a program memory
but the size of the configuration data provides strong evidence that there is only pure configuration without any program code.
NIOS can run from internal memory but there is very little one in used CYCLONE, only 30 kB and that memory is needed for waveform sample storing (see below).
No doubts that existing configuration read waveform samples from the flash into the internal memory buffer (16kB BTW from 32kB available) before
provide that to the output. 250Msamples/s is at the upper limit of the used CYCLONE chip and the flash can't provide that speeds of reading anyway.
About reverse engineering CYCLONE configuration from its uncompressed/compressed data (they only differ by sizeof data, no extra encryption) I think it is out of our capability.
About 3000000 configuration bits needs some automated software tools to restore a source design. And BTW in which forms, Verilog, VHDL, schematic? Didn't hear
about such capabilities anyway.
If we made a new configuration we certainly can made a special mode in it where SPI interface of FP MCU would be directly
translated to the flash pins so no problem reprogramming it with any new data from USB interface.
And last but not least for the moment. I have already a few ideas about implementation of such configuration especially about its DSP part.
But now it's time for me going on vacation so I can start this work only as early as end of the March / beginning of the April. So you could consider any new desired functionality for a while and then I try implement it later if possible.
Of course without fremen participation all that could not be possible as I am not familiar with FP MCU programming and debugging.
Well, power stayed on here, so I think you did something wrong.
...read waveform samples from the flash into the internal memory buffer (16kB BTW from 32kB available) ...