Show Posts
Pages: 1 2 [3] 4 5 ... 21
31  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: January 10, 2014, 09:08:27 am
Well I finally got my shield to work reliably, bad soldering was the problem.
Now I am faced with a 29 bit extended frame problem.

The due_can.cpp file has the following:
        ul_id = m_pCan->CAN_MB[uc_index].CAN_MID;
   if ((ul_id & CAN_MID_MIDE) == CAN_MID_MIDE) { //extended id
      rxframe->id = ul_id & 0x3ffffu;
      //rxframe->id = (ul_id);     // I wanted to look at the id - it always returns a 3 in the leftmost position
      rxframe->ide = 1;
   }
   else { //standard ID
        rxframe->id = (ul_id  >> CAN_MID_MIDvA_Pos) & 0x7ffu;
      rxframe->ide = 0;
   }

Your problem with the extended ID was not your fault at all. You can see in the snippet you posted this line:

rxframe->id = ul_id & 0x3ffffu;

I'm not sure what sort of brain malfunction beset me or whoever wrote that but the proper mask for extended frames is 0x1FFFFFFF not 0x3FFFF. I just fixed that in the git repo. Extended IDs are stored in the bottom 29 bits of the register so all you have to do is mask off the extended bit which is what that line was supposed to do. Try your sketch again and I think you'll see it work better now. Sorry about that.
32  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: January 07, 2014, 10:25:23 pm
I have just pushed a commit to github. There are two examples now (as opposed to the previous four) but they show how to use the library now. Word of warning: If you update to this version of the library you will very likely need to update your sketch. Some things have changed. The function to get frames (get_rx_buff) now takes a reference parameter instead of a pointer. This should be easier for most people to use. There are now easy functions for sending frames, receiving frames, and setting filters. There is now less need to directly call low level functions or have to mess with the interrupts. A lot more things are handled within the library now. Additionally, all can frames now use CAN_FRAME instead of having different versions for RX and TX. CAN_FRAME now uses a union for the data bytes so you can directly set things 1 byte, two bytes, 4 bytes, or all 8 bytes all at once.

I have done various tests and this version of the library seems to properly send frames in both standard and extended mode. I have tested reception of standard frames but haven't tested reception of extended frames yet. Both included examples have been verified by connecting a Kvaser Leaf Light to a dual canbus board to scope the traffic.

More changes are coming soon. I'll also create a document that details how to use the new functions.
33  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: January 05, 2014, 04:06:42 pm
I'm fairly sure that extended frames are messed up in a variety of ways currently. I'm going back through this library once again and fixing it up so the problems should be corrected within a week or so.  Also, I'm vastly simplifying the interface for most uses so it should be a lot easier to use too.
34  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: December 23, 2013, 09:27:55 am
Any progress on this effort?

What can be done to help?

Sorry, I haven't gotten around to working on the library in some time. I do hope to get back to it soon.

At this point what needs to happen is for someone (me, you, someone) to create a sensible API that we would then follow. The way it works currently is very convoluted and silly. You shouldn't need to know so much about the hardware to use the library. Paul had wanted to do all of this a while back and things just sort of fell by the wayside - probably my fault.  He had mentioned looking at the APIs for things like mbed. That's probably a good idea. Ideally we'd have an API where you initialize a canbus port by giving the speed and then you can set the filters in an easy way and send frames just by giving an ID, whether it is extended or standard, and the data bytes. There should be a structure or class that we use for canbus frames. It probably would be easiest if we used the same structure/class for both RX and TX frames even though they've got slightly different info (RX frames have no priority while TX frames do).
35  Products / Arduino Due / Re: EEPROM on: November 25, 2013, 04:14:49 pm
Keep in mind that using flash memory for your storage is NOT permanent! Devices like the Due are meant to be programmed lots of times. Every single time you write a new sketch (or update your current one) it will erase the entirety of flash space including your stored stuff. There is no way around this. Sebnil mentioned this but I thought it good to reiterate this point strongly as it totally kills the usefulness for many people. If it still works fine for you then, by all means, have at it. Otherwise you might need to add an I2C connected EEPROM chip or follow m3741's link.

Fantastic!

The in ability to save to a permanent  store on the DUE has always been its down fall in my eyes.

Ill be trying this out for a few projects soon smiley

Question, there's 512KB of Flash on the DUE.
Does this library use the final (1kb? 2KB? 5KB?) for use with the library or do you define this during initialising of the sketch?
36  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: November 17, 2013, 07:00:36 pm
I'd call the current state of the canbus library "just barely operational enough to be useable." And, I say that being one of the people responsible for it.  It does include a total mish-mash of API formats. I suppose the proper answer to your question is that it's still in a state of significant development and, yes, migrating to a more Arduino friendly format would probably be a good thing. The library is used in a project of mine and I think we added a couple of convenience functions that maybe didn't make their way back into the library but either way the library is a mess. I had always meant to go back and clean it up but you know how that goes. It works so nobody ever quite gets back around to making it pretty. I do still want to fix it up though.
37  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: November 08, 2013, 02:48:03 pm
Your CANH/L signals look awful. There is way too much slope on those signals. Are you terminating each end with 120 ohm resistors? Your pictures look to have something like 100k and 22k resistors (it's hard for me to make out all the colors) which doesn't seem to make sense unless I'm looking at the wrong thing.
38  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: October 30, 2013, 09:56:51 am
This is my setup code:
Code:

CAN.reset_all_mailbox();
//Rx-Setup
CAN.mailbox_set_mode(0, CAN_MB_RX_MODE);
CAN.mailbox_set_id(0, TEST1_CAN_TRANSFER_ID, false);
//Tx-Setup
CAN.mailbox_set_mode(1, CAN_MB_TX_MODE);
CAN.mailbox_set_priority(1, TEST1_CAN0_TX_PRIO);
CAN.mailbox_set_accept_mask(1, 0x1FFFFFFF, false);

can_senden(TEST1_CAN_TRANSFER_ID + 0x200, 7, 'A', 'R', 'D', 'U', 'I', 'N', 'O', 0);

CAN.enable_interrupt(CAN_IER_MB0);
And this is Code for incoming frame interpretation (only test structure, I will implement bitwise interpretation). How can I receive all incoming frames with every ID or ID from 100-200? I tried to set accept mask without success. It only works with ID set in mailbox_set_id.

Overall your code looked pretty decent. It should work fine. But, you wanted to know how you might accept every frame 100 to 200. I assume you mean in hex (0x100 to 0x200) and not decimal. The basic process works the same anyway.

To accept a range of message ids you need to figure out which bits they always have in common and which they do not. So, turn 0x100 and 0x200 into binary:

0x100 = 1 0000 0000
0x200 = 10 0000 0000

In between these two the bottom 8 bits will vary from 0000 0000 to 1111 1111. There is a predicament here. It would be easy to accept all frames from 0x100 to 0x1FF but 0x200 is in a different range. If it would be OK to just accept 0x100 through 0x1FF then you'd set your mask to 0x700 and your ID to match against as 0x100. This way any incoming frames are AND with the mask then compared to the match ID. Any frame 0x100 to 0x1FF will pass this test. Any other frame will not. Try it: 0x253 AND 0x700 = 0x200 (doesn't match), 0x070 AND 700 = 0 (doesn't match). 0x1B5 AND 700 = 0x100 (matches!)
39  Products / Arduino Due / Re: Arduino Due and CAN on: September 30, 2013, 09:36:45 am
Now, I could be a slight bit biased but... why on Earth would you want to do this?! You want to ignore the fact that the processor has built-in support for canbus and use something else that won't ever quite be able to match the performance? You seem to realize that it will be a major pain to do what you're trying to do but still you persist in wanting to do it. So, is there some reason you can't use the built-in canbus support and just add the very small amount of extra hardware it takes to use what you've already got? I've used the canbus on the Due with just a cheap protoshield for Arduinos and a couple of chips. It really isn't that hard.
40  Products / Arduino Due / Re: SAM3: How many clock cycles per instruction? on: September 19, 2013, 07:52:44 am
As Leon said, most instructions are single cycle on the Cortex chip. However, it is even better than that. It must have two execution pipelines because it will do 1.25 million instructions per second per 1 MHz. So 84MHz * 1.25 = 105MIPS. That makes it about five times faster than a 328P running 20MHz. However, it also is natively 32bit and so can crunch 32 bit numbers in a single cycle. So, for 32 bit math it is probably around 6x faster again (for a total of 30x faster at doing 32 bit math) If you can work your algorithms so that operations on bytes can be packed into 32 bit integers and processed four at a time then you could see upwards of a 30x speed up.

But, talking about processor speed is a very complicated topic. Take, for instance, the talk of pipelines. A three stage pipeline means that each instruction goes through three stages (probably one per clock) but generally each stage can have a different instruction (so it doesn't slow down the actual # of instructions processed). Now, under ideal circumstances this means that there are always three instructions in the pipe and things are working one clock per instruction. But, a cache miss or instruction dependency can stall or clear the pipe causing it to need to reload. This will waste instruction cycles. This is not really that big of a deal with a three stage pipe. Modern processors can be over 20 stages. Then a pipe getting invalidated is a bad thing.

41  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: September 16, 2013, 11:37:34 am
Arduino code for the Due seems to be gigantic. It takes 10,076 for the blink sketch. AnalogInOutSerial takes 26,712. The size you got for the canbus example is pretty typical for the examples. They just seem to come out that large. However, it doesn't seem to enlarge a whole lot thereafter. My whole VCU project takes up less than 100K of flash space. It has a whole lot more code than the canbus library but only takes up about 30K extra. So, I think that the arduino core library can just be a bit large. I've wondered if there is something that could be done about this but have not actually taken the time to try to figure it out. I'm being lazy because there is still all sorts of available flash space. If my sketches were getting toward 450K in size then I'd worry about how to save space.
42  Products / Arduino Due / Re: Stupid Me! on: September 12, 2013, 09:44:31 pm
Power the Due up. Does it turn on? Can you access serial over whichever USB port you are hooked up to? Is the cortex M3 chip getting so hot that you can fry bacon on it? If it turns on, has serial (run a sketch that shows something over the serial port), you can upload things to it, and it is not currently trying to melt down to the core of the Earth then things are looking good. You should then try to toggle pin 7 on and off to see if it really toggles. If it does then that's a good sign. If you get all of the way through this and it seems to work then it is probably fine. You may have reduced the useful lifespan of the Due even if it does currently work.
43  Products / Arduino Due / Re: More 1.5.3 fun... on: September 10, 2013, 03:14:33 pm
This sort of question seems to come up a lot.

You cannot use AVR system headers in your ARM Cortex code. The Due is a totally different processor architecture. It has nothing to do with AVR at all. If you want to use libraries that make direct reference to AVR libraries and/or headers then you will have to rewrite the library to work around this.
44  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: September 10, 2013, 08:00:11 am
Hello, Can anyone please explain the function of mailbox_set_accept_mask(); both in case of transmitter as well as receiver mailbox.

Thanks,

Owais.

Sure. For transmission mailboxes it means absolutely nothing. The examples might call that function but it is just for completeness and not because you have to. Transmissions will go out no matter how you have the accept mask set.

Now, such is not the case for receiving mail boxes. That's where the accept mask comes into play. It works like this:

1. A frame is sent over the wire and picked up by the Due.
2. The ID of the frame is logical AND with the accept mask
3. This new value is then compared to the id you set for the RX mailbox (mailbox_set_id). If the IDs match then the frame is accepted and available for your program to inspect.

Here is an example. Let's say you set your accept mask to 0x7F0 and your ID to 0x230 (assume only standard frames). Now, a frame with ID 0x232 comes in. So, take 0x232 AND 0x7F0 = 0x230. Compare this to the mailbox ID you set (0x230) and find out that it matches. So, the frame is accepted by your program. Now, if a frame with ID 0x23A comes in then the same thing will happen. If 0x240 comes in then it will be rejected.

In a nutshell: the accept mask allows you to accept a range of frame IDs with a single mailbox. In the example above it allows a range of 16 IDs through 0x230 - 0x23F. The traditional use for this is to tailor acceptance to only frames you care about. Canbus traffic can get busy and you don't want to have to deal with every frame on the bus.
45  Products / Arduino Due / Re: Arduino IDE 1.5.3 on: September 03, 2013, 07:03:35 pm
Yeah, I didn't see it either. I don't think it is really there. Somebody forgot to include it. The version checked into the Arduino repo was pretty old anyway. We never actually requested the new versions to be included so they aren't. As such, it still pays to go grab a fresh copy of the library from my github repos (collin80)
Pages: 1 2 [3] 4 5 ... 21