Re: [Paparazzi-devel] CAN on Lisa

[Tilman Baumann]

Should we keep the API defined in ./sw/airborne/arch/stm32/mcu_periph/can_arch.c?

Considering that is is not actually used anywhere I would not feel too bad to scrap it.
The thing is that the libopencm3 API is quite different. And I would like to take advantage of the hardware filters in the chip more.

can_hw_init() and can_hw_transmit() would practically be the same. But I would like to change the rx_callback method so that every module could register it's own callback.
Which would make the code quite stm32 specific, I admit. More generic abstractions could be possible though.

Since I can not do things dynamically I will have to probably do some macro magic for the callbacks, or settle down with only allowing one receiver per filter.
I would not mind figuring out how to do that...

What do you think?

On 13/08/12 10:18, Tilman Baumann wrote:

On 12/08/12 00:51, Christophe De Wagter wrote:

https://github.com/paparazzi/paparazzi/commit/399016c983b338242bac04d668a3970d5f1f94b1

Uuuh, that is a lot of code.
I suppose the plan would rather be to fold the CAN stuff back into the main code rather than having the whole AP duplicated.
I would love to work with that.

Can someone perhaps explain what that CSC actually is/was? Are there actually practical CAN servos out there?
I thought I had to invent a Servo protocol, but implementing a existing one is of course much better.
And what is the deal with this BOARD_ID? I can see it's used for CAN addresses... (Since CAN filters are so powerful I was actually thinking of filtering message type and port number rather than boards.)

But so much seems duplicated code, I don't quite know where to look deeper. In what respect did the CSG software differ?
It looks like servo commands are also just a telemetry message type. Good idea.
I will be spending some time with this code in the future. It would be easier though if I knew the general concept already.

Thanks guys.

Piotr, sure let's rock this. I'm not quite sure where to start yet. But if we start small I'm sure I can help.

PS: Can't wait for saner wiring. I crashed my plane Saturday (flew it in manual I fool) and wings ripped off and even some of the wires attached to Lisa created so much inertia that they ripped the plug off.
I really need less wires. It could have been much worse, but I would really prefer a plane that can break in pieces without ripping the electronics to shreds. :)

-Christophe 

On Fri, Aug 10, 2012 at 8:35 PM, Piotr Esden-Tempski <address@hidden> wrote:

Hi Tilman,

I did not port the CAN driver to libopencm3 yet. There is a CAN example in libopencm3 itself as well as in open-bldc codebase. It was a while since I tested it the last time.

I want to bring the CSC functionality back to paparazzi using lisa/m instead of dedicated hardware. I will have to work on that in not so far future. It will be awesome if you want to help with that effort of course! :)

Also as Felix said it is a good idea to look at the old CSC code and maybe reuse at least the high level protocol parts?

Cheers Esden

--
Transition Robotics Inc.
http://transition-robotics.com
the makers of the Quadshot
Co-Founder, Embedded systems Engineer
Mobile: +1 831 440 7454
Skype: esdentem

On Aug 10, 2012, at 11:17 AM, Felix Ruess wrote:

> Hi Tilman,
>
> definitely a good idea!
> There already was the the CSC (CanServoController) that did stuff like that (never used it myself though).
> But we deleted it, as it was not used and maintained anymore and needed to be done in libopencm3 now anyway.
>
> But 4.0 is not converted to libopencm3. So if you want to work on this, use the master branch, where everything is converted to libopencm3.
> Also see the issues for the libopencm3 milestone: https://github.com/paparazzi/paparazzi/issues?milestone=1&state=open
>
> Cheers, Felix
>
> On Fri, Aug 10, 2012 at 6:13 PM, Tilman Baumann <address@hidden> wrote:
> Hi,
>
> I'm fooling around with can at the moment. A friend and I want to modularize UAV components a bit more.
>
> The easiest and lowest hanging fruit seems to be to just pass telemetry messages on the bus first. (probably inspired by one of the data logging modules)
> But anyway. I'm not there yet. First I like to play around with CAN raw. I thought the code is now based on libopencm3. But ./sw/airborne/arch/stm32/mcu_periph/can_arch.c is totally different.
> Eventually I don't care really what I use. But what is it that is being used there and how can I learn about it?
> Has anyone already used that stuff? I suppose the code is there for a reason?
> Would it perhaps be a better idea to scrap that and use the libopencm3 functions? Would they work?
>
> And while this is not my concern yet, I would not mind starting some kind of conversation about this before I start hacking.
> My current idea is basically to just dump ppz format messages on the bus with a prefix to make them filterable. Later additions would be a message type for actuators. (Have not quite grokked if or how I can have multiple Actuators like CAN servos and PWM servos)
> And then of course telemetry receive via CAN and sensor values receive (remote virtual ADC would be cool).
> I guess conversation topics could be the message format. I think the ppz format is the easiest way right now. But perhaps there are better ideas.
>
> Grand vision is to have little can modules (NXP Cortex M0 based processor probably) which drive servos, run actuators and read sensor. Connector could be RJ45.
> This would make wiring much less crazy and planes become more maintainable. Imagine having just one JR45 connector going to each detachable wing and your camera subsystem and what not.
> Also telemetry could become more flexible, radios could be placed where ever is most convenient.
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel