PDA

View Full Version : PBP for dsPIC 16bit??



photoelectric
- 8th May 2011, 12:24
hi all,

Is it possible??i mean all the command listed in the PBP green book can be used for dsPIC??

thanks

HenrikOlsson
- 8th May 2011, 12:50
Short answer: No.
PBP works with PIC10, 12, 16 and 18 "only".
I'd probably take a look at MikroElectronikas mikroBASIC PRO for dsPIC (http://www.mikroe.com/eng/products/view/229/mikrobasic-pro-for-dspic30-33-and-pic24/) or move over to the dark side....

Acetronics2
- 8th May 2011, 17:06
Hi,

The subject was discussed some times ago ...

looked Melabs had no real project for 16 bits ...

May be Charles Leo could make a little " update " about the future ...

BTW CCS C compiler also is a possibility ( take care to recent versions > 4.110 : somewhat buggy ...)

Alain

rmteo
- 9th May 2011, 18:57
And why would 16-bit PICs be interesting? A PIC16 is rated at 5MIPs and the fastest PIC18s are rated 16MIPs (typically 10MIPs). The 16-bit PIC24/dsPIC are rated from 16-40MIPs. However, MIPs (million-instructions/second) are very misleading and do not not take into account things like instruction and data sizes. So how, for example, does a 10MIPs PIC18F97J60 compare to a 16MIPs PIC24FJ64GA004 - is the PIC24FJ 1.6x faster? In real world testing and benchmarking, it is more like 13-23x. Comparing PIC32s which are rated at 40-80MIPs, the disparity gets even larger. Instead of 4-8x that of a PIC18, it can be as much 160x. Take a look at the CoreMark figures (last column) in the table below.

Acetronics2
- 10th May 2011, 11:23
(post removed)

rmteo
- 10th May 2011, 16:21
(post removed)

Acetronics2
- 10th May 2011, 17:01
(post removed)

rmteo
- 10th May 2011, 21:16
(post removed)

Acetronics2
- 10th May 2011, 21:49
(post removed)

rmteo
- 11th May 2011, 00:47
(post removed)

mister_e
- 11th May 2011, 03:48
Really constructive post...Deserves a sticky...

Archangel
- 14th May 2011, 04:08
Why stop at the 16s Pie in the sky ask for 32

photoelectric
- 16th May 2011, 15:02
hi,
any example of application using dsPIC??
if it is just driving specific motor application would be wasted for dsPIC??

thanks

Demon
- 16th May 2011, 16:16
...
Is it possible??i mean all the command listed in the PBP green book can be used for dsPIC??
...





Short answer: No.
PBP works with PIC10, 12, 16 and 18 "only".
....



Why not? I've never used or seen a DSpic but thought this an interesting subject so I did some googling:

dsPIC30 is a 16bit mcu:
http://ww1.microchip.com/downloads/en/DeviceDoc/70102K.pdf

(p. 62)
The format supported is the IntelŪ HEX 32 Format (INHX32).


PIC 24F are also 16bit mcu:
http://ww1.microchip.com/downloads/en/AppNotes/91025a.pdf

(p. 2)

The formats supported are the Intel HEX Format (INHX8M), Intel Split HEX Format (INHX8S), and the Intel HEX 32 Format (INHX32).


It would seem it's just a matter of using a programmer that generates INHX32 hex files. I have no clue which format is generated by my MeLabs U2 programmer. The most I could find was:


The melabs programmer software is compatible with the standard Microchip HEX format files.

INHX8M? INHX8S? INHX32?


So, is it possible that finding a programmer that generates INHX32 hex files is the only hurdle to using PIC Basic Pro on dsPIC devices?


Or am I totally not seeing something?



EDIT: This is from 18F2550.INC in PBP folder:


LIST p = 18F2550, r = dec, w = -311, w = -230, f = inhx32

So a PIC 18F2550 is apparently programmed in INHX32 format, why couldn't a dsPIC?

Demon
- 16th May 2011, 16:29
...
looked Melabs had no real project for 16 bits
...


I wouldn't make a statement like that (EDIT: Until Microchip closes the production line or issues a formal statement).

http://www.microchip.com/en_US/family/16bit/index.html



Microchip’s 16-bit, PIC24 MCUs and dsPICŪ Digital Signal Controllers provide designers with an easy upgrade path from 8-bit PICŪ microcontrollers and a cost effective option to 32-bit MCUs. The broad product line includes everything from eXtreme Low Power microcontrollers to high performance digital signal controllers. Combined with hardware and free software these 16-bit products make the design of Control, mTouch™ Sensing (http://www.microchip.com/en_us/technology/mtouch), Graphics (http://www.microchip.com/en_us/technology/graphics/), Connectivity (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2664&param=en537008&redirects=connectivity), Digital Power Conversion (http://www.microchip.com/SMPS), Smart Sensing (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2885&param=en547253) and Motor Control (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2125&param=en026178&pageId=64&redirects=motor) solutions easy to implement.

rmteo
- 16th May 2011, 16:47
...So, is it possible that finding a programmer that generates INHX32 hex files is the only hurdle to using PIC Basic Pro on dsPIC devices?

Simple answer - no. Programmers do not generate INHX32 files - that is the job of the compiler. The files required by a PIC12/16/18 is very different from that of a dsPIC. While it may be possible to take a PIC12/16/18 HEX file and burn it into a dsPIC, it will not do what you expect it to.

Demon
- 16th May 2011, 16:55
Simple answer - no. Programmers do not generate INHX32 files - that is the job of the compiler.
...


Ok, my mistake.

If this is from 18F2550.INC in the PBP folder:



...
LIST p = 18F2550, r = dec, w = -311, w = -230, f = inhx32
...


Then it will be used by compiler right?
(Mecanique Studio Plus, MPLAB or whatever alternatives if there are any)

So, wouldn't you still end up with an INHX32 hex file anyways?

Demon
- 16th May 2011, 16:57
(just had a thought)

Or is it more an issue of how the commands are structured within the hex file?

The layout is compatible, but the commands are not.

cncmachineguy
- 16th May 2011, 17:04
That is the "file format" same as pdf, doc,pbp,xls,dwg and so on.

But the content will not be correct. At best you will get an eight bit program to run on a 16 or 32 bit processor. This will not be too good. For instance, when we declare a WORD variable, the compiler generates code to make the uP act on the WORD in multiple BYTES. The 16 bit uP would not need the extra overhead of manuiplating the BYTES since it can handle WORDS. But the program would have it anyway since it was compiled for an eight bit uP.

Archangel
- 19th May 2011, 03:54
That is the "file format" same as pdf, doc,pbp,xls,dwg and so on.

But the content will not be correct. At best you will get an eight bit program to run on a 16 or 32 bit processor. This will not be too good. For instance, when we declare a WORD variable, the compiler generates code to make the uP act on the WORD in multiple BYTES. The 16 bit uP would not need the extra overhead of manuiplating the BYTES since it can handle WORDS. But the program would have it anyway since it was compiled for an eight bit uP.
PBP could very well have a separate compiler switch like it does for longs to switch up to 16 bit compiler, yeah it would probably be a a complete rewrite from the code in an 8 bit compiler but the interface could remain the same and use the same syntax. Look at how similar "C" compilers are for each series. All said I think it would be Do able, however; I think the upgrade price would be steep, I think it would HAVE to be. My thoughts are it would be worth it so as not to need retraining in " C ".

mister_e
- 19th May 2011, 04:14
You can start right now with assembler or C... it's free (with some limitations).

If you already mess with 10,16,18 series, then you'll discover PIC24, DsPIC, PIC32 assembler is far different... not to mention the extra features and architecture.

Download a datasheet... then oh surprise, you also need to download the family common datasheet for x specific section of the internal peripherals.

Yes it is a complete rewrite, no it's not simple... and no you don't need to stick to C, there's already Basic compilers available.

On the long run, you may find it handy to know C.

rmteo
- 7th June 2011, 17:09
.....On the long run, you may find it handy to know C.
If you want to leverage your efforts into commercial/professional activities, then C/C++ is the way to go. It dominates the market at 84% (ASM is the next highest with 5%) with all other languages making up the balance of 11% - BASIC (all dialects, not just PBP) accounts for 1% of total usage.
5650

mister_e
- 7th June 2011, 17:42
It's been said countless time in here, compilers are just tools. You want to have more than one screwdriver in your kit.

I say, if you can, learn them all :D

Keep programming fun, enjoy what you do..life's too short.

harryweb
- 29th July 2011, 15:34
I would like to program PIC24, because they have 4 UART ! Need Them because SERIN(OUT)2 are not good for my apps

Regards

rmteo
- 7th August 2011, 22:00
I would like to program PIC24, because they have 4 UART ! Need Them because SERIN(OUT)2 are not good for my apps

Regards
Sure looks like you are not going to find the solution here any time soon.

longpole001
- 5th July 2014, 08:00
wish , wish , wish 3 years on

harryweb
- 7th July 2014, 09:20
In august 2011 Rmteo told me:
Sure looks like you are not going to find the solution here any time soon.

Using from 2012 another compiler for pic24: MikroBasic. Many bugs, not a complete forum as this one... but working.

Ioannis
- 7th July 2014, 10:39
And Proton seems to make the first steps in the 16bit world just the previous few months. But looks more promissing than Mikroe with the tons of bugs.

Well, I wish too for the step forward, but on a stable compiles. And Charles I am sure will do this when he is ready. I feel that the time comes...

Ioannis

longpole001
- 7th July 2014, 10:58
yes i have looked at mikrobasic perhaps for the arm processors , not look at the bugs that may come with it as yet

i also cant see why microchip cant put larger amount of ram/prom in 18f products , would be great for say 256k/ 384k option , but that reserved for 16/32bit devices

Ioannis
- 7th July 2014, 11:06
You answered your self.

So, it seems that we have the freedom to "choose" which PIC to use. I say, they make us to choose the bigger chips for more memory.

Ioannis

Demon
- 7th July 2014, 12:05
I would like to program PIC24, because they have 4 UART ! Need Them because SERIN(OUT)2 are not good for my apps

Regards

18F with 4 USART:

http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC18F67J94

Robert

harryweb
- 8th July 2014, 08:58
@ Robert,

The text you select had been written in 2011... not sure that 18F67J94, if exist at this time, was suported by PBP2.60...
;-)


I can see now, that, here in France, electronicians are using more and more ARDUINO, raspberry Pi, beaglebone.... (linux embedded and python prog) May be because of the price and no simple basic compiler for big PIC available. (?)

Regards

HenrikOlsson
- 8th July 2014, 09:48
Hi,
The 18F67J94 (or, in fact, any of the xxJ94 devices) doesn't seem to be supported even by PBP3 (Supported devices (http://pbp3.com/devicelist.html)).
I'd love for PBP to support other device families but as have be said, the 24 and 32 series PICs are completely different animals compared to the 12, 16 and 18 series. However, and I know the thread is old so the point may be moot but if 4 USARTs is the driving factor for going to a 32bit microcontroller one might think about taking a step back and re-evalutate. Take a look at the MAX3107 for example, 4UARTs with 128bytes FIFO buffers, SPI/I2C interface to the main controller.

/Henrik.

harryweb
- 9th July 2014, 09:13
Hi,

I used some PIC24 with Basic and it's different from 12,16,18 series, but easier than using a new device like MAX3107.
For MAX3107, it seems that it is a new device (2014 ?) and I remember that I found some other same kind of device in 2011. They were very expensive !

This topic is not mine and there are many other things than 4 USART to use with 24 and 32 series.
There is a song here that says those who do not go forward, go backward.
I hope it's not already too late ;-)
Regards