Hello All, On Saturday 18 May 2013 23:23:28 Rempel, Cynthia wrote: > >> Would following the guidance in: > >> http://lists.gnu.org/archive/html/qemu-devel/2011-07/msg00842.html > >> increase the probability the [CAN] device simulation would be committed > >> to qemu? > > > >Yes, I think so. > > > >Here is also some help which shows the fundamental > >requirements for new contributions: > > > >http://wiki.qemu.org/Contribute/SubmitAPatch > > Thank you! This is very helpful :) > > >Are you planning to emulate an existing CAN controller, > >or do you want to design a new virtual CAN controller > >from scratch? > > If feasible, we would prefer to emulate a CAN controller that has a LinCan > port, so that we have a "known good" software configuration to work with... > > http://ortcan.git.sourceforge.net/git/gitweb.cgi?p=ortcan/lincan;a=tree;f=l >incan/src > > We would want to have the student write an emulation for the CAN portion of > one (1) of the CAN controllers... We will want to be able to hook it into > qemu-system-arm... which of these controllers would it be more feasible to > write an emulation for? > > ADLINK 7841 card > AIM104CAN PC/104 card > BFAD can > C_CAN Bosch > CAN104 PC/104 > Kontron EB8245 > EMS-WUENSCHE CPC-PCI > CAN/PCI-200 > PCI/PMC 266 card > PCAN-PC/104 > sja1000 CAN > SH7760 HCAN2 > HMS30c7202 C_CAN > i82527 CAN > IXXAT iPC-I 165 > KVASER PCIcan > M437 PC/104 > MPC5200 MSCAN > PC-I03 > PCAN-PCI > PCCCAN board > PCM-3680 PC/104 > MX1_DIS1 > PIP5,PIP6,PIP7 and PIP8 > SJA1000 chip PeliCanCAN > SSV board > TS-7KV multifunction card > Unicontrols PCAN > > We really appreciate all the help!
The question is what is the reasonable controller to emulate. Today, Bosch IP core C_CAN is quite often integrated in devices. But its windowed message objects access is nightmare. Some clean simple CAN controller (like FreeScale MSCAN) would be much simpler to implement, but this is not PCI connected on any target (mos probably). So if we speak about chip with broad availability then SJA1000 is the choice. It complicates things by only 8-bit registers access and old non-PeliCAN mode for compatibility. But it can be even ignored. Then it is single Rx object + FIFO based which simplifies implementation. There exists many PCI boards with SJA1000 behind different PCI/local buss bridges. Some are quite bizare with strange edge triggered IRQs routing and combining which requires to be extra carefull for IRQ processing on driver side. The board with clean simple design and level interrupts are Kvaser PCIcan-S, PCIcan-D, PCIcan-Q. The actual naming is little different but I expect that it is same HW PCIcan HS, PCIcan HS/HS, PCIcanx 4xHS http://www.kvaser.com/en/products/can/pci.html We have more these cards so we can check even on real HW. I have found manual there for example http://simlab.dyndns.org:9000/AllegroHandWiki/images/c/c5/Kvaser_PCIcan_Hardware_Reference_Manual.pdf So it is good choice for QEMU and Linux (and even for RTEMS if more architectures should be supported). The PCIcan-Q has even nice feature to connect and terminate selected channels directly on board so no external componets/cables are not required for simple testing. On the other hand some FPGA design like Gailser GRCAN, MSCAN or FlexCAN can be simpler when we consider non PCI one system. By the way, how is it with future possible integration ofMBED (http://mbed.org/nxp/lpc1768/) board QEMU support (https://github.com/gdrane/MBEDSimulator.git). It LPC17xx is an another candidate. We should discuss the QEMU CAN controller emulation selection on linux-...@vger.kernel.org mailing list. I have information that one big carmaker in cooperation with one big chip maker has full CAN controller and network model including bit-timing implemented. But I do not know more and it is possible that their implementation is to complex for reuse in QEMU (and probly even not publicable). But we should discuss on which chip to focuss with SocketCAN maintainers on linux-can for sure. Best wishes Pavel Pisa e-mail: p...@cmp.felk.cvut.cz www: http://cmp.felk.cvut.cz/~pisa university: http://dce.fel.cvut.cz/ company: http://www.pikron.com/
