Hi Marc, On Friday 24 September 2010 01:02:00 am Marc Kleine-Budde wrote: > I've tested your first patch, not the second as I'm concentrating on the > RX for now. For multiple TX buffers we need proper buffer priorities, > though.
Yes, you are right. My second patch probably is pretty broken! > I'm using our 2.6.36-rc4 (the protonic/master) on MX35 with a mcp2515, 2 > MHz SPI clock, currently using 250kbit on th CAN-bus. Ok, that sounds like it's clearly more than your system can handle... at least with the unpatched driver. > Without your patch the RX of a single message (dlc doesn't matter) takes > 19..20 SPI interrupts. I can receive 2 messages (with dlc==1) > back-to-back without loosing one. The third one just gets lost. 19..20 SPI interrupts? Sounds like the SPI driver could use some optimizing. The interrupts you get are probably due to the FIFO that wants more data. The controller probably generates an interrupt every time the FIFO has space for at least one byte, right? Anyway, you should get 10 SPI transfers. Let me think.... 9 of the 10 transfers are for less than 8 bytes. The SPI FIFO is 8-deep, so that should be 9 SPI interrupts for 9 of the 10 transactions. One of the 10 transactions, however is 14 bytes long. Since the MX35 has an 8-deep FIFO, it's 8 bytes with 1 interrupt and then 6 more bytes with one interrupt each.... yields 16 SPI interrupts in total, following my counts. Hmm, I must be counting wrong. > When trying to receive 6 messages I see something quite strange: The > CAN-ID should be always "2", the dlc "1" and the data should be increasing. > > CAN-ID dlc data > > <0x002> [1] 00 > <0x002> [1] 01 > <0x002> [1] 03 > <0x002> [1] 04 > <0x000> [8] 00 00 00 00 00 00 00 00 > > The last frame looks quite broken. I haven't debugged the problem yet. Broken or unreliable SPI, or spurious interrupts on your board is the only thing I can think of.... Are you using automatic Slave-Select, or GPIO? If you use automatic (internal) SS, there might be a chance SS goes inactive during the long (14-byte) message transfer. That could explain the excessive interrupts you get. Does is get worse if you run some CPU-intensive task in the background? I will try to reproduce your problem on my board, but I don't believe I will manage to get broken frames (never had so far), and I am using only GPIO-SS. > I've done this test with the pengutronix's can-utils. On the sending side: > cansequence -p --loop=6 > On the rx side: > candump Unfortunately our test equipment runs on Xenomai RT-SocketCAN, so your tool would need some porting before I can run it. But our system is python- scriptable, so maybe if you explain what "cansequence -p --loop=6" does....? > With your patch it's 8 interrupts per message. And with the improvement > you talked about on the phone, i.e. 2515 clears the RX flag > automatically, I managed to get it down to 7. But I get still this > strage 8 byte long can message, although it takes much more messages to > trigger that problem. Ok, at least my patch improves things ;-P But again, counting SPI interrupts I can't exactly explain this. Can't you count SPI transactions or SPI-SS pulses? IIRC, with my first patch you should have 4 SPI transactions per CAN-frame, and probably 1 less when removing the while() in the CAN ISR, but I am not sure if it is safe to do. Best regards, -- David Jander Protonic Holland. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
