We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello,
I am getting some really strange problems when using the ported usbaudio keil code from this zip file
ics.nxp.com/.../mcb1700.code.bundle.lpc1769.lpcxpresso.zip
with the LPC1769xpresso and the embedded artists base board, it is appearing as a usb composite device, do you think perhaps the usbdesc.c needs to be changed for the newer processor 1769. all jumpers and power seem to be correct.
Or maybe chinzei, will post usbaudio code that he has got working on the lpc1769, for some reason even newer code will not work, well I have flash bin files onto the lpc1769 created with uvision and they will not work. The only one that works at the moment is the one that has bugs in the usbcore.c with no audio.
But with, or without, his help, you should be able to figure out if the issue is with the USB code handing over audio data to for playback, or if the issue is with the generation of the audio or if it is with the hardware picking up the audio hand delivering it to an audio jack.
You can even add some code lines that on press of a button captures the next 100 audio samples the USB code thinks it receives and stores them in a buffer - then they can be dumped on a serial port to verify if you do get real samples.
Exactly what have you done to subdivide this issue into smaller pieces and figure out where in the chain it fails?
The thing is, is that the same code works on the lpc1768 but it will not work on the lpc1769, how I am supposed to be able to fix problems like this.
... how I am supposed to be able to fix problems like this.
It might be worth you considering a different career.
The thing is that most code do not work initially. So how am a poor developer supposted to be able to fix problems like that?
The way the society have found to move forward is to try to attempt debugging broken code. It is a significant part of a developers life to compare what happens with what was expected to happen, and then try to deduce something from that - or potentially break the problem down into smaller problems until the error(s) are identified and taken care of.
The interesting thing here is that new developers write code that they have already written many times before. So most times, they are breaking new ground. But they still have to perform their debugging or they would be stuck. There can't automagically exist someone who do know more and can step in and do the debugging.