Serial over USB driver on STM32, cable unplug detecting

[Giovanni]

But some protocols need it, for example 'LIN' and my protocol has it too. I have devices with USART and new with USB, I do not want to change protocol, because i will need rewrote many programs...

You can implement that by adding messages handling to the CDC driver, the current one is pretty basic.

But there are many changes in new version and I want to know how to quickly migrate from one version to another, and what exactly has changed ..
For example, now UART LLD has 2 versions and files changed its location. Which version to choose? chIQInit has new parameters etc.

Changes are listed in the readme.txt present in the development version, usually it is pretty accurate.

Now it turns out that the flags will be sent asynchronously with respect to the data stream, as the events are asynchronous? Then there are problems with protocols such as LIN, as BREAK signal is used to mark the start of the parcel. I'll have to check it somehow ...

CDC devices process messages and data on different endpoints so I think the deliver order cannot be guaranteed because it depends on how the host handles things. Events are generated after each transfer so it depends on how the host sends the data and from the size of the serial_usb buffers.

Why with ChibiOS 2.4.2 it works without locks and now I must lock? And generally how can I understand from which zone callbacks called?

Hi this is a big change between 2.4.x and 2.5.x, now all callbacks are consistently called outside locks in order to reduce ISR jitter a little bit. It is in the readme

There are two UARTs because different STM32 devices have different UARTs so there are two implementations.

Giovanni

[alexblack]

In new version also stopped working events in my program:

Code: Select all

#define emGPS_DATA_READY              0x0002             // GPS data ready
EVENTSOURCE_DECL(esSYSTEM);
...
chEvtBroadcastFlags(&esSYSTEM, emGPS_DATA_READY);
...
...
  static EventListener elEVENT;
  chEvtRegisterMask(&esSYSTEM, &elEVENT, 0);
  eventmask_t event = chEvtWaitAny(emGPS_DATA_READY);
...

The code with chEvtBroadcastFlags executed (I tested it with debugger).
But chEvtWaitAny is waiting forever.

What could it be? Something changed in the events system?

[Giovanni]

Hi,

Yes some things changed, some functions have been renamed for consistency.

chEvtClearFlags -> chEvtGetAndClearEvents
chEvtAddFlags -> chEvtAddEvents

The meaning of chEvtBroadcastFlagsI() changed the second parameter is no more a eventmask_t but a flagsmask_t.

You can no more broadcast a set of fixed flags like you do in your code, you have to associate the eventmask_ to the listener. When you call chEvtRegisterMask() specify the set of event flags that the listener has to raise.

Note that now there is two sets of flags, the flagsmask_t are flags that are raised from the broadcaster and are ORed in the listener, the eventflags_t are flags associated by the serving threads to the listener and are those that the "wait" functions wait for.

I hope this is clear, I have yet to update the article regarding flags.

Giovanni

[alexblack]

Hi,

Sorry but I did not understand, could you give a simple example of the new events?

For example I need one broadcast thread and some listener threads. Listener threads are waiting certain events and resumed when it happened.

P.s. I revert to ChibiOS V.2.4 but found that USB driver not working properly...

[Giovanni]

Hi,

Basically you don't need to specify the second parameter of the chEvtBroadcastFlagsI() call, put it to zero. The former second parameter of chEvtBroadcastFlagsI() is now specified in the EvenListener object initialization (I imagine it is zero in your current code).

I am cosidering backporting the whole USB stack back to 2.4.x when I am confident enough the new version is stable enough, there is one pending bug but it cannot impact you, it is a very special use case.

Giovanni

[alexblack]

I have one EventSource on all events in program and how can I distinguish events if I 'broadcast' zero? Or I must have one event source for each event?

[Giovanni]

You can have a source for each event or a single source broadcasting those flagsmask_t that you can retrieve using chEvtBroadcastFlagsI(). An example of this are the serial driver or the serial_usb driver, both have a single source that is used to broadcast multiple flags.

Giovanni

[Prof. Dr. YoMan]

Hi,

I am cosidering backporting the whole USB stack back to 2.4.x when I am confident enough the new version is stable enough, there is one pending bug but it cannot impact you, it is a very special use case.

A released 2.4.x with some major improvements would be nice.
Is https://chibios.svn.sourceforge.net/svn ... k/todo.txt up to date?
What is you plan with 2.4.x? There are lots of "- planned" in todo.txt.
What is the plan with 2.6.? Estimated release date?
I am just asking because I am curious.

[Giovanni]

The "todo.txt" is not necessarily updated, it is just a container for pending ideas.

2.6.x should be release Q1 2013, I think there are already enough new features, before that 2.5.x needs polish, retesting, documentation cleanup, regeneration of all reports etc.
2.4.x will be maintained with bug fixes until 2.8.x is released or as long there are commercial customers paying for it.

Giovanni

[Prof. Dr. YoMan]

2.4.x will be maintained with bug fixes until 2.8.x is released or as long there are commercial customers paying for it.

Thanks for the answer.
What is the policy with backports to 2.4.x? Doesn't seem to be a question, because it will be no big thing to update from 2.4.x to 2.6, I guess.
There may be some incompatibilities in kernel and HAL, but hey, we got the source and you.