I know that this has already been discussed in other topic but I was not able to find the solution of the problem.
Serial communication implemented with the native port is incompatible with Processing: you can send data packets from the Arduino Due to the PC but conversely hangs around.
So I tried to figure out how much you could push on the programming port and I have verified that the limit is linked to the fact that the clock and the dividers of the two processors are not in tune with frequencies above 115200bps except some magic numbers that are 250kbps (very fine), and for payloads of no more than 128 bytes: 400kbps, 600kbps, 1000kbps.
There is someone who is able to run the "native port" or do better on "programmig port"?
stefano_gsi:
Serial communication implemented with the native port is incompatible with Processing: you can send data packets from the Arduino Due to the PC but conversely hangs around.
Really? I wish somebody told me that before I did it! ;)
Regards,
Graham
Serial communication implemented with the native port is incompatible with Processing: you can send data packets from the Arduino Due to the PC but conversely hangs around.
I hadn't heard anything about that. Got a link? (I haven't actually USED the native port...)
on the programming port and I have verified that the limit is linked to the fact that the clock and the dividers of the two processors are not in tune with frequencies above 115200bps
That makes sense. The programming port is still a 16MHz 16u2, and has the usual limitations of bitrates. It might go 2Mbps too.
@westfw, I don't know your name sorry.
It is kind of coincidental that you should turn up here, I was going to seek you out on a different matter, but since you are here, and since it is loosely related to this topic here we go....
I got a STM32F7-Discovery board last week and have been having major problems using it. Specifically I wanted to do simple stuff like Serial.println() and see it in a terminal program. The ST-Link worked but if I connected either USB-HS or USB-FS they were not recognised by the PC as COM ports. The upshot was I installed ANY/ALL ST USB drivers I came across..... Finally I have working COM ports from the ST board.
Now, back on topic, what the OP said about the native port not being compatible with Processing...
Earlier this year I started playing around with a SPI flash ic on my DUE. To program it I wrote an Arduino sketch and corresponding Processing sketch. These worked perfectly well on both Programming and Native ports, but with the obvious advantage of the Native port being HUGELY faster....
HOWEVER, I was going to post a slightly less sarcastic version of the post I made last night, quoting the actual transfer rates I achieved over both ports until I realised SOMETHING had gone horribly wrong :(! I can only assume it has something to do with my efforts to get COM ports working on the ST board!!!???? Since I installed all the various different USB drivers for the ST board, my Arduino/Processing sketch on the Native port is no longer HUGELY faster than the programming port which is kind of upsetting.... Further investigation into this matter WILL be a priority!!
In the meantime, if the OP would like to have a look at my Arduino/Processing sketch for flash programming using the Native port, it may help him to do what he is trying to do? It is attached below.
Just to show how badly things have gone wrong, I have been doing comparative tests over the past couple of hours, I don't expect the figures to mean anything to anybody else, but you should see what I am talking about!!
File size uploaded 0x500000 bytes in all cases.
Mega @ 115200
Flash erase time 33secs
Upload time : 7m26s
Total time : 7m59s
Bytes/s : 11755
Mega @ 1000000
Flash erase time 33secs
Upload time : 3m17s
Total time : 3m50s
Bytes/s : 26613
DUE Programming port @115200
Flash erase time 33secs
Upload time : 87m23s
Total time : 87m56s
Bytes/s : 999
DUE Native port
Flash erase time 33secs
Upload time : 11m05s
Total time : 11m38s
Bytes/s : 7884
Before whatever it is that has gone wrong, I was getting 46KB/s on the Native port and the same speed as the Mega at 115200!!! This MUST be fixed soon....
Regards,
Graham
DUE-Native_Processing.zip (8.03 KB)
ghlawrence2000:
Really? I wish somebody told me that before I did it! ;)
What does it mean? You can do it?
Remember that I need to use Processing. With other apps the native works fine.
westfw:
That makes sense. The programming port is still a 16MHz 16u2, and has the usual limitations of bitrates. It might go 2Mbps too.
Yes. The 16u2 can go at 2Mbps and several bitrate obtained from a division for integers (1M, 666k, 500k, etc.) but the SAM3X doesn't support all the same bitrates with suitably accurate
stefano_gsi:
What does it mean? You can do it?
Remember that I need to use Processing.
Read post #3.....
Regards,
Graham
thanks for your post.
I will study your attachement
Good news!! Through a combination of removing the ST drivers and using a USB 3.0 port, speed is back to what it should be!
Regards,
Graham
USB3 should be irrelevant. None of the arduino-class boards implement USB3.
I appreciate that fact, but trust me, it does!
USB 2 Port
DUE Native port
Flash erase time 33secs
Upload time : 10m59s
Total time : 11m32s
Bytes/s : 7955
USB 3 Port
DUE Native port
Flash erase time 36secs
Upload time : 2m01s
Total time : 2m37s
Bytes/s : 43329
Didn't reprogram the DUE between tests, just unplugged from USB2 and plugged in to USB3 port.
Regards,
Graham
OK, I have an update!!
One word.... FU*K ..... I have fine-tuned my flash verify routine and I can now achieve 1.25MB/s over the Native port.
And proof that a USB 3.0 port DOES have advantages over USB 2!
Due Native Port:-
USB 2 Port
Size ok: 0x00500000 bytes
Time taken: 0:05 min:sec
Bytes per second: 1048576
Compare Successful!
Due Native Port:-
USB 3 Port
Size ok: 0x00500000 bytes
Time taken: 0:04 min:sec
Bytes per second: 1310720
Compare Successful!
I am WELL happy!!!
Anybody want to know how I did it?? 
Regards,
Graham
I just got the performance that you had already got and I thought that I would forever given up on using the "native" because on "programming" I arrived at 200kbps but now you're bewildering me.
What do you do?
Anybody want to know how I did it?
Of course.
Any idea how much (before AND after) is due to host-side software issues?
westfw:
Any idea how much (before AND after) is due to host-side software issues?
All of it is due to host(PC) side issues.
Buffer the maximum amount of data possible before sending to the DUE.... 256 byte chunks seems to work well, 512 is the CDC buffer size, but I cannot get 512 byte chunks to work reliably.
Regards,
Graham
Bad PC-side drivers. There are well-known algorithms for automatically buffering data for "trickle-like" generators and "bursty" data paths (Nagle Algorithm and similar.)
Have you tried any alternative drivers (linux, mac, http://www.thesycon.de/eng/usb_cdcacm.shtml)?