Application level. Lets assume the CAN driver deals with everything else (Big assumption actually but let’s go with it)
> On 19 Oct 2023, at 20:49, Petro Karashchenko <petro.karashche...@gmail.com> > wrote: > > Hi, > > I do not fully understand if you are looking from Application or Kernel > perspective? > Also I do not know if the CAN driver is capable of providing you with > information when the message is actually transmitted on the bus. I mean > that for example CAN peripheral may have multiple TX buffers and you can > put your message into one of those, but it can loose internal TX > arbitration if CAN peripheral picks a buffer holding the lowest CAN-ID > first, so the mechanism how do you want to ensure that messages are > transmitted with the chronological order is not clear to me, unless you use > a special version of the peripheral driver that uses a single TX buffer. > > Best regards, > Petro > > чт, 19 жовт. 2023 р. о 22:35 Tim Hardisty <timhardist...@gmail.com> пише: > >> Hello helpful people. I am not sure if this is a POSIX or NuttX >> question, so apologies it it's something I "should" know. >> >> I am looking for a methodology - ideally portable (POSIX) - perhaps a >> queue, to hold a list of messages (CANbus) that need to be transmitted >> in the correct chronological order. I have been using linked lists for >> other things and just about have that sussed (but they do my head in to >> be honest!) but it doesn't seem quite right for this. I am thinking the >> set of "dq_" functions are possibly a good solution but I can't find >> much information/documentation on this and am not sure if its just a >> NuttX-specific thing, although I see it used heavily for audio playback? >> >> Am I on the right track, or should I be looking at something else? >> >> In essence I want to add (queue?) entries (pointers to message structs) >> that need to be sent (on a POSIX timer, which I have setup and working >> well) and once each is transmitted it'll be removed until added again if >> needed. I want it to be as generic as possible. >> >> Thanks! >> >> TimH (aka TimJTi...new email account) >>
