SJA1000 driver

[Petri Hyötylä-2]

Hello!
I was going to use the SJA1000 driver with our Ethernut 3 project but I
noticed that it seems to be only for AVR.
Is there some serious problems porting it that I'm not seeing? I skimmed
through the sja1000.c and as far as I can tell, it is AVR only because it
manipulates some registers of the AVR directly. If there are no further
issues with porting, I could try porting it by using ifdefs and thus making
it manipulate the corresponding registers in ARM (or use other methods when
available).

BR,
Petri
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ole Reinhardt-2]

Hello!

> I was going to use the SJA1000 driver with our Ethernut 3 project but I
> noticed that it seems to be only for AVR.

Yes, that's right. But there should not be a real issue why it should
not work with arm.

Main Problem might be the bus interface. The sja1000 supposes a
mulitplexed address / data bus where the Ethernut3 provides different
lines for data and addresses.

You could either re-multiplex it again using a cpld or simply use I/O
ports to connect the SJA1000 to. Perhaps you should consider to use a
different CAN controller with SPI interface?

Regards,

Ole Reinhardt

--
 _____________________________________________________________
|                                                             |
| Embedded-IT                                                 |
|                                                             |
| Ole Reinhardt        Tel. / Fax:        [phone] |
| Luisenstraße 29      Mobil:             [phone] |
| 57076 Siegen         eMail:    ole.reinhardt@... |
| Germany              Web:         http://www.embedded-it.de |
|_____________________________________________________________|

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Petri Hyötylä-2]

Thanks Ole
I was afraid that there was something I was not seeing.
I am already using MCP2515 and it has been serving our project well but now
we have to receive bursts of CAN messages and we miss some of them. I'm
guessing that the SPI bus may be overloaded because there is a lot of other
traffic on it, too. That's why I was hoping to test SJA1000 with (hopefully)
little effort to see if removing CAN traffic from the SPI helps. Now other
possible solutions I have is to increase SPI speed by doing the SPI in the
NPL or use a slave MCU to buffer the bursts. Probably AT90CAN128. I guess I
will go with the slave MCU.

On Wed, Oct 21, 2009 at 1:37 PM, Ole Reinhardt <ole.reinhardt@...
> wrote:

> Hello!
>
> > I was going to use the SJA1000 driver with our Ethernut 3 project but I
> > noticed that it seems to be only for AVR.
>
> Yes, that's right. But there should not be a real issue why it should
> not work with arm.
>
> Main Problem might be the bus interface. The sja1000 supposes a
> mulitplexed address / data bus where the Ethernut3 provides different
> lines for data and addresses.
>
> You could either re-multiplex it again using a cpld or simply use I/O
> ports to connect the SJA1000 to. Perhaps you should consider to use a
> different CAN controller with SPI interface?
>
> Regards,
>
> Ole Reinhardt
>
> --
>  _____________________________________________________________
> |                                                             |
> | Embedded-IT                                                 |
> |                                                             |
> | Ole Reinhardt        Tel. / Fax:        [phone] |
> | Luisenstraße 29      Mobil:             [phone] |
> | 57076 Siegen         eMail:    ole.reinhardt@... |
> | Germany              Web:         http://www.embedded-it.de |
> |_____________________________________________________________|
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ole Reinhardt-2]

Hi Petri,

> I was afraid that there was something I was not seeing.
> I am already using MCP2515 and it has been serving our project well but now
> we have to receive bursts of CAN messages and we miss some of them. I'm
> guessing that the SPI bus may be overloaded because there is a lot of other
> traffic on it, too. That's why I was hoping to test SJA1000 with (hopefully)
> little effort to see if removing CAN traffic from the SPI helps. Now other
> possible solutions I have is to increase SPI speed by doing the SPI in the
> NPL or use a slave MCU to buffer the bursts. Probably AT90CAN128. I guess I
> will go with the slave MCU.

Are you using the original Ethernut3? If not, using the SAM7x might be a
solution for you (which has an included can controller)

Bye,

Ole

--
 _____________________________________________________________
|                                                             |
| Embedded-IT                                                 |
|                                                             |
| Ole Reinhardt        Tel. / Fax:        [phone] |
| Luisenstraße 29      Mobil:             [phone] |
| 57076 Siegen         eMail:    ole.reinhardt@... |
| Germany              Web:         http://www.embedded-it.de |
|_____________________________________________________________|

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Uwe Bonnes]

>>>>> "Ole" == Ole Reinhardt <ole.reinhardt@...> writes:

    Ole> Hi Petri,
    >> I was afraid that there was something I was not seeing.  I am already
    >> using MCP2515 and it has been serving our project well but now we
    >> have to receive bursts of CAN messages and we miss some of them. I'm
    >> guessing that the SPI bus may be overloaded because there is a lot of
    >> other traffic on it, too. That's why I was hoping to test SJA1000
    >> with (hopefully) little effort to see if removing CAN traffic from
    >> the SPI helps. Now other possible solutions I have is to increase SPI
    >> speed by doing the SPI in the NPL or use a slave MCU to buffer the
    >> bursts. Probably AT90CAN128. I guess I will go with the slave MCU.

    Ole> Are you using the original Ethernut3? If not, using the SAM7x might
    Ole> be a solution for you (which has an included can controller)

Otherwise, there are FPGA Cores for the SJA1000, so if you hav an FPGA with
some bus access and some free place, the SJA1000 comes for free.

--
Uwe Bonnes                bon@...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Petri Hyötylä-2]

On Wed, Oct 21, 2009 at 4:33 PM, Uwe Bonnes <
bon@...> wrote:

> >>>>> "Ole" == Ole Reinhardt <ole.reinhardt@...> writes:
>
>    Ole> Hi Petri,
>     >> I was afraid that there was something I was not seeing.  I am
> already
>    >> using MCP2515 and it has been serving our project well but now we
>    >> have to receive bursts of CAN messages and we miss some of them. I'm
>    >> guessing that the SPI bus may be overloaded because there is a lot of
>    >> other traffic on it, too. That's why I was hoping to test SJA1000
>    >> with (hopefully) little effort to see if removing CAN traffic from
>    >> the SPI helps. Now other possible solutions I have is to increase SPI
>    >> speed by doing the SPI in the NPL or use a slave MCU to buffer the
>    >> bursts. Probably AT90CAN128. I guess I will go with the slave MCU.
>
>     Ole> Are you using the original Ethernut3? If not, using the SAM7x
> might
>    Ole> be a solution for you (which has an included can controller)
>
> Otherwise, there are FPGA Cores for the SJA1000, so if you hav an FPGA with
> some bus access and some free place, the SJA1000 comes for free.
>
> --
> Uwe Bonnes                bon@...
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. [phone] -------- Fax. [phone] ----------
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>

Hi
I am using the original Ethernut3 with custom PCB connected to the expansion
port.
All these are fine ideas but this is one of those things that have to be
ready by yesterday (ASAP).
We happen to have AT90CAN128 boards in the lab so I'll go with one of those.
I'm guessing (hoping) that it will be fairly easy to get the CAN working and
also the SPI slave code.

BR,
Petri Hyötylä
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ole Reinhardt-2]

Hi,

> I am using the original Ethernut3 with custom PCB connected to the expansion
> port.
> All these are fine ideas but this is one of those things that have to be
> ready by yesterday (ASAP).
> We happen to have AT90CAN128 boards in the lab so I'll go with one of those.
> I'm guessing (hoping) that it will be fairly easy to get the CAN working and
> also the SPI slave code.

I used this library in a project (running without OS):

http://www.kreatives-chaos.com/artikel/universelle-can-bibliothek#downloads

It works quite well, but still had several bugs. I sended patches to the
author but nothing happened yet. If you want to use the lib, let me
know, I'll send you the patch.

My application processes the can traffic and talks via SPI to several
SPI clients. I'm shure you would be able to use it together with the
Ethernut3.

Bye,

Ole

--
 _____________________________________________________________
|                                                             |
| Embedded-IT                                                 |
|                                                             |
| Ole Reinhardt        Tel. / Fax:        [phone] |
| Luisenstraße 29      Mobil:             [phone] |
| 57076 Siegen         eMail:    ole.reinhardt@... |
| Germany              Web:         http://www.embedded-it.de |
|_____________________________________________________________|

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Uwe Bonnes]

>>>>> "Petri" == Petri Hyötylä <phyotyla@...> writes:


    Petri> Hi I am using the original Ethernut3 with custom PCB connected to
    Petri> the expansion port.  All these are fine ideas but this is one of
    Petri> those things that have to be ready by yesterday (ASAP).  We
    Petri> happen to have AT90CAN128 boards in the lab so I'll go with one
    Petri> of those.  I'm guessing (hoping) that it will be fairly easy to
    Petri> get the CAN working and also the SPI slave code.

We use the AT90CAN128 successfull on several boards with Ethernut, on some
boards even without external RAM. Here the crucial CAN code

  // Init AT90CAN128 CAN controller
  canresult = NutRegisterDevice(&devAtCan, 0, 0);
 
  if (canresult)
    fprintf_P(stdout, can_register_P, canresult);
  canInfoPtr = (CANINFO *) devAtCan.dev_dcb;

  // Set CAN bit rate
  CAN_SetSpeed(&devAtCan, CPS_SPEED);
  /*FIXME: It seems at least 4 MOBS need to be given */
  /* explicitly set up 3 receive Message Objects */
  /* Global Broadcast */
  AtCanEnableRx    (6,CPS_CMD, IS_EXTENDED, NOT_REMOTE, DEVICE_MASK,IS_EXTENDED, NOT_REMOTE);
  fprintf_P(stdout, PSTR("MOB for Global Broadcast id 0x%08lx mask 0x%08lx\n"), CPS_CMD, GLOBAL_BC_MASK);
  /* Crate Broadcast */

  AtCanEnableMsgObj(6,CPS_CMD|((uint32_t)base<<CRATE_SHIFT), IS_EXTENDED, NOT_REMOTE, DEVICE_MASK,IS_EXTENDED, NOT_REMOTE);
  fprintf_P(stdout, PSTR("MOB for Crate Broadcast  id 0x%08lx mask 0x%08lx\n"),
            CPS_CMD|((uint32_t)base<<CRATE_SHIFT), DEVICE_MASK);
  /* Explicit Deviced */
  fprintf_P(stdout, PSTR("MOB for Device           id 0x%08lx mask 0x%08lx\n"),
            CPS_CMD|((uint32_t)base<<CRATE_SHIFT)| (uint32_t)address << DEVICE_SHIFT, DEVICE_MASK);
  AtCanEnableMsgObj(7,CPS_CMD|((uint32_t)base<<CRATE_SHIFT)| (uint32_t)address << DEVICE_SHIFT, IS_EXTENDED, NOT_REMOTE,
                    DEVICE_MASK,IS_EXTENDED, NOT_REMOTE);
           
  fprintf_P(stdout, PSTR("Starting CAN RX/TX loop...\n"));

  while(1)
    {
     if (CAN_TryRxFrame(&devAtCan, &canFrame) == 0)
        {
          crate = ID2CRATE(canFrame.id);
          device = ID2DEVICE(canFrame.id);
          command = ID2CMD(canFrame.id);
          if((crate == BROADCAST_ID) || ((crate == base) && (device == BROADCAST_ID)) || ((crate == base) && (device == address)))
            {
              activity = 0xff;
              switch(command)
                {
                case CMD_BOOTLD_CKSUM_REQ:
                  bootld_req(&canFrame, mute);
                  break;
                 
...
As our SPI devices can run quite fast and need byte access, the SPI access
is done in a separate thread like:
THREAD (ReadADS7835, arg)
{
  unsigned char pin;
  unsigned int value;
  unsigned int to_counter = 0;
  unsigned int last_set = 0x8000;
  /*
   * SCK and MOSI outputs need configuration,
   * even if SPI mode is enabled.
   */
  cbi(PORTB, 1);
  sbi(DDRB, 1);
  cbi(PORTB, 2);
  sbi(DDRB, 2);
  cbi(PORTB, 0);
  sbi(DDRB, 0);
  /* set to 2 MHz  */
  SPCR = BV(MSTR) | BV(SPE) | BV(SPI2X) | BV(SPR0);
#define CPS84_OL_TIMEOUT 1000

  for (;;)
...
      /*Read the ADC, Give a short low pulse to start and then keep CONV high*/
      SPDR = 0x7f;
      loop_until_bit_is_set(SPSR, SPIF);
      value  = (SPDR <<8);
      SPDR = 0xff;
      loop_until_bit_is_set(SPSR, SPIF);
      value  |=  (SPDR & 0xfc);
      value = value <<2;
      if (value & 0x8000)
        value &= 0x7fff;
      else
        value |= 0x8000;
      adc_values[DEVICE_ADC_V_ISENSE] = value;

...

Hope this helps
--
Uwe Bonnes                bon@...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion