On Sun, Feb 1, 2009 at 1:36 PM, I <kirk...@pdx.edu> wrote:
> Here we go again...
> if(OS != Linux)
> CAN = Easy;
> In one respect, I agree with Sarah's statement in that the only active node
> in an FC failure is the recovery node. Nothing else really matters.
> That said, if you *must* have some sort of non-usb back channel
> communication, CAN is the way to do it. It's easier than any other protocol
> for the same level of performance and robustness (bar NONE). I understand
> that there is a lot of ill feelings on this list toward CAN, but that was an
> issue with CAN implemented with specific hardware and a specific OS and
> driver, all done without any solid tools (which are not needed at all once
> communication is established).
Yes, CAN is robust and reliable. Given the choice between serial and
CAN, I would choose CAN. However, we don't have CAN support on our
current avionics node microcontrollers. We would have to switch to a
different NXP chip to get CAN.
I don't want to have to re-develop the software stack. No one has
ported LPCUSB to the bigger version of the LPC2148 that supports CAN.
It would take time away from the senior capstone members to
investigate the differences between the chips. So I would like to use
serial or something else the LPC2148 supports for any necessary back
channel communication. Or we could have a whatever-to-CAN chip on the
nodes that actually need to talk to each other.
I will ask again, since no one answered the question:
- What back channel links do we need between sensor nodes to get the
rocket safely to the ground if the flight computer fails?
- What messages do we need to send?
> Quoting Sarah A Sharp <saharabe...@gmail.com>:
>> My question (before we jump into CAN or anything else) is, "What nodes
>> need to talk to each other if the flight computer goes down?"
>> If the flight computer is down, the goal should be to get the rocket
>> to the ground safely. I don't think there's much point in trying to
>> use CAN to log data. Given the goal of a safe landing, what nodes
>> *really* need to talk to each other?
>> If it turns out that only two nodes need to talk to each other, why
>> bother with CAN? Why not just run one serial connection between the
>> two? I'm concerned that we're adding too much complexity for what
>> should be a really simple backup system.
>> On Sun, Feb 1, 2009 at 12:07 PM, Dave Camarillo
>> <dave.camari...@gmail.com> wrote:
>>> Hi All, it looks like Denx does have drivers for the CAN hardware on
>>> the 5200. It appears to be a derivative work of Peak Systems
>>> (http://www.peak-system.com) PCAN software. I skimmed the source code
>>> and they have a driver that hooks the PCAN driver (they also support
>>> devices such as the SJA1000 chip and a couple other products from
>>> peak-system). The include in the source tree a command line app for
>>> transmitting and receiving messages as well.
>>> Based on skimming the source code and looking at the pcan web site it
>>> appears to support 2.4 and 2.6 kernels, and the peak site indicates
>>> that they support the PF_CAN (SocketCAN) stuff built into newer
>>> I'm wondering, maybe Josh/Jamey could bring the flight computer on
>>> tuesday and maybe we can play with this a little?
>>> On Sun, Feb 1, 2009 at 5:58 AM, Andrew Greenberg <and...@psas.pdx.edu>
>>>> We've looked a bit at our schedule for the capstone, and the decision
>>>> between CAN and a UART backchannel really, really, really have to be
>>>> made in the next three weeks.
>>>> To even consider CAN as a backchannel, we have to have the MPC5200 talk
>>>> CAN on its native CAN peripheral. That means digging up Denx's MPC52000
>>>> CAN peripheral drivers and actually seeing them work, and testing them a
>>>> We'll talk about this more on Tuesday, but I just wanted to warn
>>>> software folks - I guess mostly Dan and Dave here - that we need to know
>>>> stuff, soon. We'll have the MPC5200 FC at the next meeting for you to
>>>> play with, and I'll bring my CAN2USB adapter.
>>>> Andrew Greenberg
>>>> Portland State Aerospace Society (http://psas.pdx.edu/)
>>>> and...@psas.pdx.edu P: 503.788.1343 C: 503.708.7711
>>>> psas-avionics mailing list
>>> psas-avionics mailing list
>> psas-avionics mailing list
> psas-avionics mailing list
psas-avionics mailing list