Other Parts Discussed in Thread: HALCOGEN
我不太了解 HalCoGen 自动生成的 HAL 低级代码的设计/API。 我 的想法是、或者我已经这样做了、就是在没有/很少修改的情况下按原样使用它、但我发现不清楚如何最好地使用 API。
我有的示例、是来自 HalCoGen 层的 SPI 驱动程序的通知调用。 考虑说"spiEndNotification (spiBASE-t* SPI)"调用。
这个想法似乎很好、我可以提供这个处理程序的执行、以便在 TX 耗尽或 RX 缓冲区已满时进行回调。 看起来很好、但是
一件事情就是只使用一个参数、我的处理程序无法立即检查回调的原因/源代码、我的代码必须访问并重新检查 SPI 的寄存器以查看原因是什么。 但这意味着访问的寄存器与较低代码/HalCoGen 代码已经读取的寄存器相同-例如、就像标志一样-所以似乎我被强制执行第二次(或更多)相同的寄存器访问来再次读取相同的信息。 而且，这种情况甚至可能不再有效：例如： 中断和中断标志寄存器可能已被该代码修改
如果您的代码想检查调用 spiEndNotification()的原因，您似乎需要猜测 是 SPI 高级中断还是低级中断，您不知道需要 查看哪个- INTVECT0或 INTVECT1 -以查看它是完整的 Rx 还是空 Tx。
此外，一旦包含了 spiEndNotification()处理程序代码，就不能禁用该特定调用-它不再是可选的。 而且、由于发送将始终启用 TX 中断、因此您的代码现在将始终获取此调用、即使您不关心此调用(因为您已经使用 spiSendData 等设置了所有缓冲区)。
我想您可以避免使用此 spiEndNotification() API 部分，方法是使用应 传递所有标志的其他通知调用：void spiNotification(siBASE-t *spi, uint32 flags)
但如果不更改 HalCoGen 代码，还不清楚如何操作。 生成的中断处理程序代码- mibspi1HighLevelInterrupt、 mibspi1LowLevelInterrupt -仅针对默认开关情况调用此更"通用"spiNotification 回调、即 RX 满或 TX 空时的_Exclive_Cases。 所以... 当您只想发送/接收数据时，您似乎不打算在基本/正常情况下使用这些数据！
.and sendNotification 也不会将向量源作为参数、因此虽然不重要、但您可能无法签入您自己的处理程序、哪个中断源是它的源。 (但是... HalCoGen 代码会读取它、可能刚刚传递它)。
我在生成的中断处理程序中看到的另一个奇怪现象是、这个(不安全)代码(snip)：
switch(vec)
{
case 0x24U: /* Receive Buffer Full Interrupt */
{
uint16 *destbuff;
destbuff = g_spiPacket_t[0U].rxdata_ptr;
*destbuff = (uint16)spiREG1->BUF;
所以，呃， 很好，所以如果你做 spiSendAndReceive(.) 而不仅仅是 spiSendData(.) 这不会设置 RX、并且您没有专门禁用 RX、您基本上会使系统崩溃、尝试写入到空或无效的位置。
我对这个 API 感到非常跛行模式，我不知道我是否以灵活的方式理解它的正确使用模式。
是否有一个适当的示例-超过2个内衬轮询的 SPI 发送/接收？ 一个更复杂的中断驱动示例正在运行此 HalCoGen API？
