Migration from Visual DSP++ to Crosscore ad1980

Hey Im currently in the process of Migrating some visual DSP+ code to crosscore embedded stuidos, for the ADSP-BF548 board

The code makes extensive use of the AD1980 codec , AD1980 driver includes and a callback routine. . Currently I am watching this video

http://videos.analog.com/video/products/processors-dsp/2751956133001/Migrating-from-VisualDSP-to-CrossCore-Embedded-Studio/

To assists with the migration. In the video they replaces the BF2x onchip codec drivers includes an all mentions to the codec with the ssm2603.

My question is do I follow a similar process to the above video and replace all mention too the AD1980 with the ssm2603, and if so why?

Cheers Eranga

Parents
  • Hi Eranga,

    Unfortunately, as there is no Device Driver available for CrossCore Embedded Studio, you would have to directly interact with the codec through the SPORT interface. Do you still have VisualDSP++ installed? If so, take a look at the Power On Self Test example for the BF548 EZ-KIT Lite.

    Within the folder "...\Blackfin\Examples\ADSP-BF548 EZ-KIT Lite\Power_On_Self_Test\" you will see a file called "Audio_test.c". This demonstrates how to enable and configure the codec, test a transmit and receive buffer, etc, all using direct register access, rather than a device driver. This could be ported to CCES, and adapted for audio processing (rather than just testing its very small buffers).

    Regards,

    Craig.

Reply
  • Hi Eranga,

    Unfortunately, as there is no Device Driver available for CrossCore Embedded Studio, you would have to directly interact with the codec through the SPORT interface. Do you still have VisualDSP++ installed? If so, take a look at the Power On Self Test example for the BF548 EZ-KIT Lite.

    Within the folder "...\Blackfin\Examples\ADSP-BF548 EZ-KIT Lite\Power_On_Self_Test\" you will see a file called "Audio_test.c". This demonstrates how to enable and configure the codec, test a transmit and receive buffer, etc, all using direct register access, rather than a device driver. This could be ported to CCES, and adapted for audio processing (rather than just testing its very small buffers).

    Regards,

    Craig.

Children
No Data