You're welcome Andy! Sounds like you're in the thick of it, maxing out the fun

Just want to add that you can also use the simulator, but you will have to write stimuli files to represent the CODEC. At the very least the bit clock and frame sync are needed to drive the serial port which drives the DMA.

While I agree that hardware debugging is nice, you can acheive much the same with the simulator, although it's a bit more work with the I/O files and all. Lucky for me I'm so old school that I actually prefer scopes, LEDs and printf()

Is it possible to run code from RAM on the Chameleon? That would make it possible to have dynamic breakpoints.

All code in the host and DSP runs from RAM. The FLASH memory in the host computer is for boot code and offline storage of the soundskins. I suppose one could use compiled-in soft break points facilitated by macros, and then the host port (or the LCD even) for the console. That would not require any additional capabilities of the tool set, thus being a KISS compliant solution.

Edit to add: I wouldn't be surprised if there's some complete debugging monitor(s) written for the 56k already. But then again, writing your own monitor is always a good way to get to know the system...

Is it possible to run code from RAM on the Chameleon? That would make it possible to have dynamic breakpoints.

All code in the host and DSP runs from RAM. The FLASH memory in the host computer is for boot code and offline storage of the soundskins. I suppose one could use compiled-in soft break points facilitated by macros, and then the host port (or the LCD even) for the console. That would not require any additional capabilities of the tool set, thus being a KISS compliant solution.

Edit to add: I wouldn't be surprised if there's some complete debugging monitor(s) written for the 56k already. But then again, writing your own monitor is always a good way to get to know the system...

DJ
--

Hi Are,

Are you saying that I can get at the front panel from DSP code without going through the host port?

Are you saying that I can get at the front panel from DSP code without going through the host port?

Sorry, I wasn't being clear - I meant that the host could use the LCD and buttons for a simple monitor console (a detailed log could still be printed in the debug window, but it lacks keyboard input if I remember correctly).

Lucky for me I'm so old school that I actually prefer scopes, LEDs and printf()

I really like this stage where it does compile and run but does the wrong thing and you can debug by ear. Works best for controlling code, not so well for the DSP itself where a scope or printing a train of numbers works better but on the occasions where you can do it I find it lots of fun._________________Kassen

Actually I have started to go off "Symphony Studio", when building projects any asm errors are just reported as a single make problem and you have to delve around in the console output to find the actual error.

If you program in C/C++ the error/warning reporting works fine but not for asm!

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum

Please support our site. If you click through and buy from our affiliate partners, we earn a small commission.