I tasked an employee with updating one of our simpler devices (currently using an HCS08) to use an MK02FN64, thinking it'd be a good exercise to get him some familiarity with the part and the new IDE and SDK. He just came to me with the SDK's interrupt-driven UART send/receive example code, and it looks like no one ever even tried to compile it. For starters:
uint8_t sendData[] = [’H’, ’e’, ’l’, ’l’, ’o’];
Those should be curly braces.
sendXfer.data = sendData
No semicolon on this line.
UART_TransferSendNonBlocking(&g_uartHandle, &g_uartHandle, &sendXfer);
The handle is passed twice here, and the function isn't being passed the peripheral base at all.
UART_TransferReceiveNonBlocking(&g_uartHandle, &g_uartHandle, & receiveXfer);
Same problem here. That's at least four errors in about 30 lines of code. What gives? Is there a corrected version available? This is MCUXSDKK22FAPIRM Rev. 0.
Moving on to the UART receive with ring buffer example, there's a more serious and less obvious error:
if (bytesRead = RX_DATA_SIZE) /* Have read enough data. */
This is an assignment, not a condition. It will immediately assign RX_DATA_SIZE to bytesRead and will always evaluate to true. (Tip for whoever wrote this: Put your constants on the left and it won't compile if you use = instead of ==.)
If this is indicative of the level of quality control on the MCUXpresso SDK then we simply can't afford to use it. It's not hard to figure out what the code is supposed to be doing, but there's not much point in even providing example code if it can't be counted on to be even superficially correct. What the heck, NXP? This wouldn't fly in an intro to C programming class and I'm supposed to be counting on it to guide my employees.
I try to be understanding about oversights and deficiencies in documentation because I know how hard it is to be thorough and to anticipate all of a user's questions. That's not what happened here. This is code that's flat out wrong, and it's not something an expert needs to look at to see that. You don't even need to compile it; pasting it into Eclipse is enough to highlight some of the syntax errors. Allowing untested example code into official SDK documentation is downright negligent. This looks like the work of a very inexperienced programmer, which in itself is fine since we all started somewhere and making the new guy write the example code helps highlight the shortcomings in the documentation, but there seems to have been absolutely no checking of the code. I don't see how I can have any confidence that the quality of the SDK code itself is any better.
Scott
