Show Posts
Pages: 1 2 3 [4] 5 6 ... 23
46  Products / Arduino Due / Re: UART byte format on: January 11, 2014, 08:32:19 pm
Bear with me here a moment. I'm going to give you a compilable program at the end but I'd like to explain how I got there so if anyone needs to do this again it doesn't take as much digging.

Serial1 is USART0 on the Cortex M3 chip. The easiest thing to do is use the Usart class defined in CMSIS. This is what the Arduino code does and what the _pUsart variable is. So, the easiest thing to do would probably be to make your own variable like that which is pointed to the proper place. Then you can use that variable just like the USARTClass does to change how the serial port works. So, you'd need to figure out where the variable is set and do the same thing yourself. Here is the definition for Serial1:
USARTClass Serial1(USART0, USART0_IRQn, ID_USART0, &rx_buffer2);
This line is found in variant.cpp which resides in the directory arduino/hardware/arduino/sam/variants/arduino_due_x

The first first parameter (USART0) is the reference we're looking for. So USART0 is defined somewhere to be a pointer to the proper memory location and Usart is the name of the class we need to use for this pointer. Something like this:

Usart * _pUsart = USART0;

Then you can directly work on that object just like USARTClass does. So, here is program that compiles. I have not tested it on a Due but it should work:

#include "USARTClass.h"

Usart *_pUsart;

void setup() {
  // put your setup code here, to run once:

  _pUsart = USART0; //USART0 is Serial1, change this for other serial ports
  _pUsart->US_MR = US_MR_USART_MODE_RS485 | US_MR_USCLKS_MCK | US_MR_CHRL_8_BIT | US_MR_PAR_EVEN  |
                   US_MR_NBSTOP_1_BIT | US_MR_CHMODE_NORMAL;
 
}
void loop() {
  // put your main code here, to run repeatedly:
 
}
47  Products / Arduino Due / Re: UART byte format on: January 10, 2014, 10:02:15 pm
Hi all
I need on DUE 8N2 or 8E1 format? Any solution?

Both of those modes are natively supported by the USART hardware on the Cortex M3 chip. So, yes, there is a solution - you just tell the appropriate USART hardware which mode you'd like. (Sounds so easy when I say it like that!) You can find info about this in the Cortex M3 manual (atsam3x_dc.pdf) around page 837-838. Though, my guess that if you're asking a question like this you probably have no idea what the information in the document is really telling you to do - it can be a fairly daunting thing to get into. You find find where the serial mode is configured here: arduino/hardware/arduino/sam/cores/arduino/USARTClass.cpp/.h In USARTClass.cpp you will see how the mode is set. Now, does this do you a bit of good? No. _pUsart is protected so you can't access it from outside of the class. And, the class does not expose any way to set the # of bits, parity, and stop bits for the port. So, fun stuff. What are you to do then? Well, if you know you'll only ever need 8E1 mode then you can edit USARTClass.cpp to set that mode. Then every sketch you compile will automatically set the USART ports to 8E1. Or, you can manually set up pointers to the proper configuration space and then directly write the new mode from your sketch. This isn't terribly easy to explain how to do, especially since there are many USART ports. Or, you could edit the class to expose a way to set the parity and stop bits and then try to get the Arduino maintainers to pull your change into the mainline. That's the best way in my opinion. Or, you can get someone else to do it.

I guess the short answer is that you're kind of stuck if you hope to maintain general Arduino compatibility unless you directly write to the config registers yourself. Otherwise the Arduino core must be edited.
48  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: January 10, 2014, 09:13:41 am
I posted another example (a traffic snooper). But, does anyone have any other requests or suggestions? Maybe an example of how to do PID requests and parse responses for OBDII? I'd like at least some of the examples to be useful right off the bat for various things instead of being pointless demonstrations of features.
49  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: January 10, 2014, 09:11:42 am
Hi all,

I recently started following this thread and I was trying to see if I could get it to work on my own. I cant, however , seem to get the examples to compile and I keep getting the following errors.

CAN_EchoTest.ino:7:21: error: variant.h: No such file or directory
In file included from C:\Users\jhsieh\Documents\Arduino\libraries\due_can/due_can.h:72,
                 from CAN_EchoTest.ino:8:
C:\Users\jhsieh\Documents\Arduino\libraries\due_can/sn65hvd234.h:34: error: 'uint32_t' does not name a type
C:\Users\jhsieh\Documents\Arduino\libraries\due_can/sn65hvd234.h:37: error: 'uint32_t' does not name a type
C:\Users\jhsieh\Documents\Arduino\libraries\due_can/sn65hvd234.h:39: error: 'uint32_t' does not name a type
etc...

I'm sure I have done something obviously wrong. Can anyone point it out?

Hmm... variant.h does exist. My guess is maybe you aren't using the proper Arduino IDE (you need 1.5.2 or newer) or that you forgot to set the board to Arduino Due (programming or native port).  Otherwise, you do have the library installed to the proper place so it should work.
50  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.
51  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.
52  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.
53  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).
54  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?
55  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.
56  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.
57  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!)
58  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.
59  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.

60  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.
Pages: 1 2 3 [4] 5 6 ... 23