Wishlist for a new release

Hi Chris,

I wish an CAN support for the  to the new release. 

Is it possible to implement it in the new release?

Alex

Alex,

there are customers using the CAN drivers in MotorWare today.

I'm working with a vendor on providing a nice piece of CAN HW (PC-USB-CAN-TI_HW) with PC side CAN Analyzer that works out of the box with MotorWare and the all of the gMotorVars and various structures.

Is that what you are looking for?

 

Hi Chris,

Yes, thats is what I need.

In Motorware 1_01_00_11 is only the ecan.h file. I am missing the ecan.c.

sw/drivers/ca/src/32gb/f28x/f2806x/ecan.h

I got some files from TI. This would be nice when this files are in the new Motorware.

Thank you Chris,

 

alex,

argh. I didn't realize this was missing from MotorWare.  I've got a bug request filled to do a full clean-up of all the drivers for MotorWare _13 (June; MotorWare _12 releases Tuesday).

 

Hi all,

Alex, are the files you attached provided by TI? Have you managed to use CAN with these drivers?

Chris, can you please let us know if there is an update version of the CAN driver alex has attached (provided it is indeed written by TI) and when it will be included in MotorWare, hopefully with some examples?

Best,

Giannis

Giannis,

All of the MotorWare \driver code has been refreshed, aligned across 2x/5x/6x, and tested. It will be in the next MotorWare release (_14) scheduled for January 22nd.

We have on the to-do list some examples like those provided in the controlSUITE version of the API, and CAN is near the top of the list.  But not sure which will make it into this release.

C:\ti\controlSUITE\device_support\f2802x\v220\f2802x_examples_drivers

Hi Chris,

could you post here at least the eCan driver? This is a serious lack in current MotorWare release and January is too far away, especially considering that all the driver code is already tested.

Thank you in advance,

Giannis

Alex,

I have almost managed to compile my MotorWare app using the ecan driver you posted, I have however a simple but yet unsolved issue:

In the header ecan_new.h there is a check about the baudrate:

#define CHECK	(((( ( USER_SYSTEM_FREQ_MHz ) * 1000)/2) % ((BPRreg+1) * BitTime)))
#if  CHECK
	#error	There`s something wrong with your Baudrate. Check your define values in can.c. For help read chapter 16.10 in the Reference Manual
#endif

The System clock is defined in user.h:

#define USER_SYSTEM_FREQ_MHz             (90.0)

The result is that the #if directive fails with  the message

#31 expression must have integral type

If I define the system clock as (90) (i.e. remove the decimal part the error disappears but I do not know if other problems is introduced by treating USER_SYSTEM_FREQ_MHz as an integer.

Can you please let me know if you had this problem and how you dealt with it?

It turns out this is a limitation of the C preprocessor which cannot perform float arithmetics. GCC supports some  https://gcc.gnu.org/onlinedocs/gcc-3.0.1/gcc_21.html#SEC297 to handle floating point in the preprocessor but the TI compiler doesn't seem to implement them.

So the question is, does USER_SYSTEM_FREQ_MHz need to be float?

Giannis Roussos said:

could you post here at least the eCan driver?

I've sent to the SW team to see if they can share.

Giannis Roussos said:

It turns out this is a limitation of the C preprocessor which cannot perform float arithmetics. GCC supports some  https://gcc.gnu.org/onlinedocs/gcc-3.0.1/gcc_21.html#SEC297 to handle floating point in the preprocessor but the TI compiler doesn't seem to implement them.

So the question is, does USER_SYSTEM_FREQ_MHz need to be float?

This is - as you say - a C compiler limitation, and yes, in this float calculation the MHz setting must be in floating point. What you might have to do is what we did in user.c to check for limits of user.h values. So for example, this check in user.c:

 

  if(USER_PWM_FREQ_kHz > (1000.0 * USER_SYSTEM_FREQ_MHz / 100.0))

    {

      USER_setErrorCode(pUserParams, USER_ErrorCode_pwmFreq_kHz_High);

    }

 

It looks like the processor is doing this math, but the fact that’s not in an #ifdef or #define, makes the compiler use the floating point math of the processor, so this works fine. And it doesn’t use any memory or cycles, at the end, the preprocessor generates a true or false without having the 28x compute this.

Hi Chris,

 I do a lot of development with the F28335 is there any plans to extend the MotorWare driver code to the F28335?

can you also confirm that a MotorWare driver for the CAN will be available soon?

thanks,

Glen.

Glen Prout said:

is there any plans to extend the MotorWare driver code to the F28335?

No, InstaSPIN-FOC nor -MOTION nor MotorWare are being supported for F2833x series.

Glen Prout said:

can you also confirm that a MotorWare driver for the CAN will be available soon?

I can NOT confirm.

We are looking at showing some of the examples that are in the controlSUITE register bit field style with the MotorWare API.  As for a full stack, with CAN these usually come from a 3P.  SimmaSoftware.com is working on this along with some hardware that hopefully they will release soon.

Chris,

Any progress on the CAN side of things? I can see that v_14 didn't add anything to drivers/can. If there's even something incomplete that you could share (either publicly or privately), I would be grateful. I'm prepared to "go register-hacking" if necessary, but as I understand it you already do have *something* that would give me pointers, so to say.

I'm quite experienced on the Tiva platform, so the C2000 side (either MW or CS approach) is still a bit fuzzy to me - ie. what goes where etc. For what it's worth, at least on a quick glance it seems that the CAN peripherals on the TM4C and C2000 are quite similar.

I'd prefer something incomplete now than a fully tested stack two months later :-) The final goal is to receive RPM setpoints and transmit actual RPMS / Torque via the CAN bus, in a somewhat CANopen compatible manner. I've already got libraries written for this on the Tiva side (based on TivaWare APIs), so the CAN->CANopen jump should not be a biggie anymore.

Thanks,
Veikko