chipKIT® Development Platform

Inspired by Arduino™

chipKIT-core v1.3.0 and v1.3.1 released

Created Wed, 07 Sep 2016 00:53:10 +0000 by EmbeddedMan

EmbeddedMan

Wed, 07 Sep 2016 00:53:10 +0000

The chipKIT development team is very proud to announce two new versions of chipKIT-core.

Both versions are available through the Arduino IDE Board Manager, and as separately installable zip files (from here : http://chipkit.net/wiki/index.php?title=ChipKIT_core)

Release notes on what has changed can be found here : http://chipkit.net/wiki/index.php?title=ChipKIT_core_release_notes

For instructions on how to use and install chipKIT-core, please see http://chipkit.net/wiki/index.php?title=ChipKIT_core

fleatech

Fri, 21 Oct 2016 05:17:26 +0000

I noted the following...

Version 1.3.0 (August 30, 2016)

Major changes/fixes #246 Update pulseIn() to support different CPU clock rates #253 Improved PWM - new functions analogWriteFrequency(Hz) and analogWriteResolution(bits), maintains duty cycle of PWM when settings are changed.

Are there any notes on the use of these new and update functions ???

majenko

Fri, 21 Oct 2016 09:16:37 +0000

pulseIn() looks no different to how it always did - it just behaves properly now.

analogWriteResolution() is a standard Arduino function and is documented here: https://www.arduino.cc/en/Reference/AnalogWriteResolution

analogWriteFrequency() takes one parameter - the carrier frequency to run PWM at.

Both the latter two are shown in an example sketch AnalogWriteFrequencyAndResolution which can be found in the "Analog" section of "Examples" ("Examples" is a dummy library - find it in the list of library examples).

C D Frost

Fri, 11 Nov 2016 09:55:26 +0000

I am using the current release with the Arduino IDE to program a Clicker2 for PIC32MX - this works well with MacOS (with a MacBook Pro) but does not work well with the Linux machine we normally use to programme various boards. The error occurs in the final download to the board once it is ready to load.

majenko

Fri, 11 Nov 2016 11:39:57 +0000

And what is the error you get?

C D Frost

Fri, 11 Nov 2016 17:19:16 +0000

Hello,

Below is a copy of the output of the IDE... in this case I was trying the simple 'Blink' example...

Sketch uses 6,504 bytes (1%) of program storage space. Maximum is 500,000 bytes. Global variables use 2,888 bytes of dynamic memory. Programmer for Microchip PIC32 microcontrollers, Version 2.1.24 Copyright: (C) 2011-2015 Serge Vakulenko

*** Enter programming mode now. ***

UHB bootloader not found: vid=1234, pid=0001, serial=(none)

No target found. An error occurred while uploading the sketch

majenko

Fri, 11 Nov 2016 20:12:00 +0000

Does your user have access to that USB device? It's a common issue in Linux that by default a user can't talk to just any USB devices.

The "proper" way of granting access is through udev.

As root, create a file /etc/udev/rules.d/50-clicker.rules and in it put:

ATTRS{idVendor}=="1234", ATTRS{idProduct}=="0001", MODE="0666", GROUP="plugdev"

Then restart UDEV:

$ sudo /etc/init.d/udev restart

Now it should start working...

C D Frost

Mon, 14 Nov 2016 12:07:48 +0000

Hello,

Thanks this seems to work! I had (wrongly) assumed that as the USB port had been used for various other boards that it would work for the Clicker 2, but clearly it required a bit more adjustment to the Linux system. Many thanks.

majenko

Mon, 14 Nov 2016 13:39:17 +0000

Most USB boards present a virtual serial port, and being in the "dialout" group gives you access to those. However the clicker2 uses a HID bootloader instead, so a device node /dev/ttyACMx isn't created. Since your existing permissions are keyed to the group that node is in, if there isn't one then your existing permissions are no longer used - you need to create a different set of permissions that work in a different way - and that is what udev is now doing for you.

Your existing permissions are still valid for accessing a USB serial port created by your sketch, of course.

rasmadrak

Wed, 14 Dec 2016 23:30:57 +0000

I've been using MPIDE 0023 for ages and thought I'd upgrade to the new fancy Arduino 1.6.13 with 1.3.1 chipKIT core. Wooh yeah!
I haven't updated my coding environment in years, but my WinXP laptop is running on it's final prayers now and MPIDE 0023 is no longer supported, and is considered "a threat", in OSX. I have an interesting problem to report. I must say, I'm not sure where exactly the problem is - and bear with me - but:

I've gotten my old code to compile after a few tweaks (still requires disabling DSPI2 and DSPI3 on my MAX32 board def though). But the problem is that Serial2 doesn't seem to work properly. It does work somewhat, but the communication "stutters", in lack of a better word. I have a Arduino Mega2560 connected to it (on 500 000 baud ) that handles a light matrix on its end, and the lights go haywire. When sending proper data over the interface it does get there, but it's like trying to read a book in darkness while someone flicks the light on and off all the time.

These are facts:

  • I've changed from WinXP MPIDE 0023 to Mac OSX 10.10.5 Arduino 1.6.13 + core 1.3.1. (big jump!)
  • A simple empty sketch causes Serial2 to "glitch"/"stutter", so it's not my code - it's in the core.
  • There has been trouble with DSPI (not used or linked at the moment though) and hardware serials before.
  • Serial(0) and Serial3 are confirmed to work reliably with computer serial com and serial com with a wavTrigger. Unsure about Serial1.

I realise this might be stupid questions, but nonetheless important;

  1. What has changed when it comes to hardware serials from MPIDE to the new core?
  2. Is the core 100% compatible with Arduino 1.6.x, or at least the same functionality as MPIDE 0023?
  3. Are custom baud rates unsupported and could this be the problem? (It's a bit of an inconvenient process to update the Mega)
  4. Any tricks, tips or things I can try to help verify/resolve this?

rasmadrak

Thu, 15 Dec 2016 09:31:31 +0000

I have verified that it is indeed serial data corruption caused by the MAX32-board. The software on the Arduino waits for a sync byte from the ChipKIT, before fetching 12 additional bytes where each bit is corresponding to on/off state for that light etc. Even if I send all 0's except for the first byte (character 'S') the lights goes crazy.

If I enable debugmode on the Arduino, which basically overwrites any input from the serial-port, it correctly lights up the current debug light. However - the status that is sent back to ChipKIT over serial gets corrupted, but sometimes show correct value. Usually 254 or 255 is returned instead of any number below 100. (Theory: Could probably be explained with Serial return -1 ie "nothing" and I load it into a byte... ).

Since no other card is using non-standard baud rates, I suspect it could be related to that in the new IDE?
If I half the read speed to 250 000 from 500 000, I believe the communication to be more stable. However, since I installed the new Arduino IDE+core I cannot compile the Arduino board any more... :roll: So I can't confirm or test completely different baud rates yet. I also cannot yet confirm if it's a problem with just Serial2, or that it simply manifests there due to higher/non-standard speeds.

But the problem is basically: With the old version I can use super high serial speeds without a glitch. With the new IDE I (presumably) cannot use anything higher than 56700 baud reliably. The same hardware configuration runs beautifully compiled on the old IDE code base, whereas the new code base fails miserably even with a standard "blink" sketch that sends the byte equivalent of "S000000000000" over Serial2.

majenko

Thu, 15 Dec 2016 10:16:26 +0000

The new IDE will have no bearing on the software that runs on the board - it is merely an interface.

Things may have changed slightly in the core as regards the UART software though, but not enough to cause the symptoms you describe. My immediate thought is it's a problem of baud-rate error percentage, but at 500,000 baud both chips (should) give 0% since it's working with nice round numbers. Also that code hasn't changed for years, if ever.

So I can't see it being a serial communication (low level) problem. It could be an issue with your code, though, which is executing differently since you are compiling with a newer version of GCC with slightly different optimization. If you share the serial portion of your code we can take a look and see if there is anything that could possibly cause the symptoms you mention.

rasmadrak

Mon, 19 Dec 2016 09:52:55 +0000

Thanks for your reply, Majenko. :) I will double check the test sketch I used tonight as I currently do not have access to it, but as I wrote in my previous reply I've tried using Serial2 with a bare minimum clean sketch as well, like so (pseudo):

setup()
{
	Serial2.begin(500000);
}

loop()
{
	//The code below is pretty much pseudo: 
	
	char outbytes[13];
	outbytes[0] = 'S';  //sync byte.
	for (i = 1; i < 13; i++)
		outbytes[i] = 0;    //fill up all "light slots" with zeros. 
		
	Serial2.write(outbytes, 13);   //send 13 bytes of light data to Arduino.
}

The sketch (when using proper commands) should send 'S' sync char to the Arduino, which will then wait until it gets the remaining 12 bytes of light data. In this case, all lights should be off (all zeros). Using the new IDE, or at least the native code in the new IDE, the lights flicker. That means the Arduino is getting additional non-zero data or interpreting the sync byte as light data for reasons unknown.

Edit: Just to be clear - The code has absolutely no issues on the old MPIDE I was/am using. There I can run several DSPI's, 3 hardware serial ports and almost all pins on the Max32 simultaneously without any hiccups. But that laptop is singing the final verse now....

majenko

Mon, 19 Dec 2016 12:08:57 +0000

Are you sure the Arduino can physically cope with that quantity of data being hurled at it at such a great speed? You are most likely overwhelming the receive buffer on the Arduino and getting data loss.

rasmadrak

Mon, 19 Dec 2016 20:09:42 +0000

I'm not 200% sure, but it has no problem coping using the old compiler. However - it can of course be that the new computer, new compiler, new code base and what not runs much faster (possibly even with different optimization options) so that the Arduino gets swamped, just like you suggested.

Here's the actual code, by the way:

byte outbytes[13];
        outbytes[0] = 'S';
	int c=0;
	byte outbyte=0;
	for (byte a=12; a > 0; a--)
   {
		outbyte=0;
		for (int i=7; i >= 0; i--, c++)
		{ 
			bitWrite(outbyte, i, light[c]->value);   
		}
		outbytes[a]=outbyte;
   }

	Serial2.write(outbytes, sizeof(outbytes));

I'll try lowering the speed, since it's really kind of overkill at the moment anyway, approximately 80 times faster than it needs to be. I'm just afraid that I'll spend too long sending light updates when I could do processing etc. But I'll check! \m/

rasmadrak

Mon, 19 Dec 2016 20:24:32 +0000

It seems you're absolutely right, Majenko. Not that I'm all that surprised, though... :D

If I slow down the sending, throwing a maximum of a byte or so every 20ms the Arduino manages to keep up with the basic-example. I'll try implementing the same workaround (for now) in the proper code and we'll see if that's the problem for sure!

Edit:

Confirmed. It works fine in the proper code as well with 56700 baud instead! Lower or higher doesn't work, so it would seem I accidentally found a weird sweetspot where everything worked before. Oh well, happy camper here and I can now focus on writing the game rules instead. 8-)

[url]http://poormanspinball.blogspot.se[/url]

majenko

Wed, 19 Sep 2018 09:28:32 +0000

And what is the error you're encountering? I use Linux as my primary operating system. The programming tool pic32prog is created in Linux. Linux is the primary platform used for testing everything. It's more likely for things not to work in OS X or Windows than in Linux.