24-bit Devices Selection

[kmp84]

Hello All,

Please for your advice!

pic24xxxxx, dsPic30Fxxx or dsPic33xxxxxx?

I have to make a choice of new controller for the project with the following requirements:

1. Math operation with double precision floating points.
2. More than 2 HW UART for serial (ModBus RTU) communication.
3. Finally add CCS TCP/IP stack with ENC28J60 controller.

Debugging is also important thing and until now I use CCS U64, but with simple test that I made with dsPic30F4013 it is so slowly!


P.S. I have successfully run CCS TCP/IP with 18F46K22 micro.

Your advices are always very helpfully for me!

The Best Wishes!

[temtronic]

comments

1) do you really need double precision fp numbers ? PICs, by their nature, are not designed for FP operations ! Never have,n ever will. Using 'scaled integers' you could easily get 10-50 TIMES the speed over FP AND be just as accurate. Others who have 'done the math' will explain in detail if need be. I've never checked to see if someone has made an FP coprocessor or married an 8087 FPU to a PIC.

2) if it's 'painfully slow' while 'debugging', remember that the code compiled for 'debug' is NOT the same as 'release' code ! I don't use debuggers, of ICDs or simulators as nothing works better for testing than the Real World.

As for choosing which family, read the datasheets real good and be sure to choose one with MORE pins than you think you need, MORE memory than you think to need. Also there's a HUGE 'learning curve' to any new device and the 'bigger' PICs have quirks. I use the 18F46K22 for 99% of all my products.I always have room and pins left over. IF you can stay with it, you've also got a personal library of working code,functions and knowledge you can use. Migrating to another PIC series ain't easy !

[Ttelmah]

Ongoing to this. These are 16bit devices not 24bit devices.

There are some things that standard floating point will never do.
For instance, if you are doing financial calculations these should not be used. There are some numbers that just cannot be represented in FP.
For example, 1/3 can never be coded exactly. Any number that cannot be represented as a direct binary sequence, can never be accurately handled by FP. 12.1 for example will always have an extra '1' at the end of the displayed value.
Now, 'throwing' digits at the FP can reduce the errors, but makes things slower and slower, and uses more and more space.
If you genuinely have an application that must use DP FP, then look at a processor that has a hardware FP unit. For example the Intel Atom processor. This is not what a PIC should really be used for.
If however it is something like financial, then there are fixed precision integer libraries that can be downloaded, and will behave far better.

[kmp84]

[PCM programmer]

[kmp84]

I will give you more info :

I will get double floats from PC and some fuel sensors and have to make math calculation. For examples: I will get: 1234567890123.123 as IEEE 754 double and has to add to 9876543210.321 IEEE 754 double format and have to have 2-3 digit precision after decimal point.

[Ttelmah]

And the DsPIC hardware maths is _integer only_.
It is designed for things like DSP.
It makes a big difference to the FP performance, but this is still a factor of perhaps 100* slower than a proper floating point hardware co-processor.

The big question is still 'why' the FP is wanted/needed?.

Worth realising that for example the error on calculating the diameter of the Earth using single precision, is several orders of magnitude less than the errors in the model of the Earth's shape....
As already said for some things float should not be used.

Just FYI, the PIC33 takes 1.6uSec to perform a single precision multiply, 2.7 to do a double. Problem is that something like a sin, takes just over 50uSec, and not much longer if you switch to double (sounds great), but the actual progression used is only giving about 6 digits. Just using 'double' doesn't give you double precision accuracy, unless you use an actual DP library. As soon as you do, the speed plummets....

So using a double, sin(0.1), gives you 0.099833314506 while using a single it gives 0.0998333. Problem is the value using a high accuracy calculator is 0.099833416646828. Unless you increase the terms used, you still only get slightly improved single precision figures.....

[kmp84]

Okay, I understand how hard it is FP and DFP for PIC MCU, but PC wait for double FP IEEE754 value from my controller and it cloud't be changed! Also if I stay with PIC18 how to hendlle math operation MUL,DIV,SUB and ADD with integer value more than 4 294 967 295?

Thanks for your Attention!

[temtronic]

There are 2 'roads to travel'..

1) hardware. Use a FP coprocessor. I did a very quick Google and saw a few hits for a 'floating point unit' made for micros. They appear to interface via I2C,SPI or serial. Another option would be to add an 8087 80287, 80387 FPU. Now I have not done any looking into that although I did make a product using a PIC16F877 with an 8 bit ISAbus,so I could use cheap PC cards, course that was 2 decades ago...sigh.You'll have to 'do the math' and see what the total time is sned FP #s to FPU, crunch #s,return FP # to PIC. Compare to PIC doing FP itself.

2) software. As pointed out FP using PICs is painfully slow,however if that is the 'choice', then just beaware of the time it'll take. We don't know what 'math' you have to do other than 2 FP in - 1 FP out, hooked to a PC. It might( and I haven't tried ) be better to convert the 2 FP numbers to integers, do the 'math', then cast back as FP.You may end up with better numbers and integer math is 100x faster( or more ) !! BTW divide is a HUGE time user, clever guys avoid if at all possible.

I will say that since you're connected to a PC, presumably with a USB interface, use a USB<>TTL module and NOT a PIC with internal USB. That $1 piece of hardware will eliminate a lot of USB problems !

It will be interesting to see your study of FP time calculations and which solutions works, and why.

[Ttelmah]

If you have a double IEEE value coming in from the controller, there is nothing to stop you putting this into a single.
There is nothing 'magic' in this.
Honestly it will be easier using a chip that does support the double, though in fact it is fairly easy to do even on chips that don't support this.

A huge amount depends on what the range of numbers the controller produces?. Few control systems can produce sensible values outside the range supported by single precision, and if this is the case, conversion doesn't have to handle overflows. Even fewer can produce values that have sufficient resolution to overflow single precision, so nothing would be lost.

A huge amount does depend also on whether it is worth trying to do this on a PIC. As I've already mentioned a Intel Atom, gives you a FPU. The latest Raspberry PI units (The Pi-2, and Pi-3), also have a hardware FPU, and are under $35. If you want to do a lot of PIC I/O, then use a USB enabled PIC, and attach this to the Pi. The CDC driver in the Pi happily talks to a PIC, and allows you to massively extend the I/O. You need to use Raspian to get the full FPU support.

[temtronic]

One question..
How often do the numbers come from the PC?

IE: If say once per second, then the PIC( almost any PIC) could handle doing 'the math' before the next data comes( 1 second later)

It's the 'details' that determine what options you have available.
As pointed out PICs aren't great at FP, like hammering tacks with a sledge hammer, it can be done though

[RF_Developer]

I'd not worry about the maths, all the selected processors will do double length floats okay. Not very fast, but fast enough for most purposes.

I am more concerned about running Modbus alongside TCP/IP on the same PIC. Modbus is an old (1979) and somewhat clanky protocol, using timing to determine message framing (i.e. when packets start and end). TCP/IP is a complex protocol and some operations, such as serving webpages, can take considerable time, this may mean the two clash for time, resutling in missed Modbus messages and other nasty problems. It would be less of a problem if the PIC was a Modbus master than a slave.

You also mention multiple serial ports. If you are intending to implement multiple Modbus ports then that is even more of a problem. I'd seriously think about splitting this functionality across more than one PIC.

Another thing to think about is that if you've got TCP/IP then you can implement Modbus TCP for one port. Later versions of CCS modbus.c support TCP mode, though you have to provide the TCP/IP support through the CCS TCP/IP stack.

[kmp84]

Okay Friend,

Thank you very much for your advice and suggestion! You are "Light" for me!
I have run successfully CCS TCP/IP Modbus Server with four sockets and Modbus serial RTU on the same MCU (PIC18F46K22).

P.S: I didn't understand how to convert double IEEE float to int32 or single float when I get eight bytes?
For example I get this data over serial or TCP :
0x41,0xD2,0x65,0x80,0xB4,0x87,0xDF,0x3B which is ~1234567890.123 double IEEE.

I have a test board with PIC24FJ256GA106 and will test with it and I'll write again.

Thanks,

[Ttelmah]

Though it was pointless in the situation involved, the code being tried here:
<http://www.ccsinfo.com/forum/viewtopic.php?t=56789>
shows part of what is needed.
What you have is an exponent and a mantissa. You can just take the MSb's of the mantissa and the LSb's of the exponent, and move these into the single. You have to check for the special cases of the exponent (0, and 7FF), and for exponents beyond the range that will fit into the single. However unless the values can have silly large or small values, these shouldn't happen. This is why the question about the range of values involved?. If you don't have to handle the special values, the conversion is much easier.