Searching \ for '[PIC] Hello world PIC32' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Hello world PIC32'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Hello world PIC32'
2011\10\23@094257 by Electron

flavicon
face

Hi,
I'm trying to set up a Workspace to do some MPLAB SIM sessions on a virtual PIC32 to experiment with this MPU both in asm and C.

When I have created the Workspace, I did these steps:

Project Wizard > Next
Device PIC32MX460F512L
Active Toolsuite: Microchip PIC32 C-Compiler Toolsuite
I enabled Store tool locations in Project
Next
Create New Project File (I specified the path and filename)
Then I created and added two blank source files, one .S and the other .C
I've put in the .C one this small source:

---

#include <p32xxxx.h>

int main(void) {
  return 0;
}

---

If I build as a library then no errors, but if I build as a normal target I get:

----------------------------------------------------------------------
Debug build of project `C:\Coding\PIC32\v001.mcp' started.
Language tool versions: pic32-as.exe v1.12, pic32-gcc.exe v1.12, pic32-ld.exe v1.12, pic32-ar.exe v1.12
Preprocessor symbol `__DEBUG' is defined.
Sun Oct 23 15:33:21 2011
----------------------------------------------------------------------
Clean: Deleting intermediary and output files.
Clean: Deleted file "C:\Coding\PIC32\v001.o".
Clean: Done.
Executing: "C:\Programmi\MPLab\MPLAB C32 Suite\bin\pic32-gcc.exe" -mprocessor=32MX460F512L -c -MMD -MF"v001.d" -D__DEBUG "v001.S" -o"v001.o" -Wa,--defsym=__DEBUG=1
Executing: "C:\Programmi\MPLab\MPLAB C32 Suite\bin\pic32-gcc.exe" -mprocessor=32MX460F512L -x c -c "v001.C" -o"v001.o" -MMD -MF"v001.d" -D__DEBUG -g
Executing: "C:\Programmi\MPLab\MPLAB C32 Suite\bin\pic32-gcc.exe" -mprocessor=32MX460F512L "v001.o" "v001.o" -o"v001.elf" -Wl,-L"C:\Programmi\MPLab\MPLAB C32 Suite\lib",-L"C:\Programmi\MPLab\MPLAB C32 Suite\pic32mx\lib",--defsym=__MPLAB_BUILD=1,--defsym=__MPLAB_DEBUG=1,-Map="v001.map"
v001.o: In function `main':
C:\Coding\PIC32/v001.C:34: multiple definition of `main'
v001.o:C:\Coding\PIC32/v001.C:34: first defined here
Link step failed.
----------------------------------------------------------------------
Debug build of project `C:\Coding\PIC32\v001.mcp' failed.
Language tool versions: pic32-as.exe v1.12, pic32-gcc.exe v1.12, pic32-ld.exe v1.12, pic32-ar.exe v1.12
Preprocessor symbol `__DEBUG' is defined.
Sun Oct 23 15:33:22 2011
----------------------------------------------------------------------
BUILD FAILED

Any help please? I want to play with the PIC32 simulator :-)

I actually have a Starter Kit board too, but I wanna start from scratch, and not using that board, but the MPLAB SIM.

Thanks a lot.

Cheers,
Mario

2011\10\23@095708 by Electron

flavicon
face

Hi again,

neverminds.. I had a .C and a .S file with the same name (actually v001.C and v001.S), the system was creating two .o files, overwriting the second, causing this fault.

MPLAB should warn the user in this case in my opinion..

Anyway, it's solved now.

Many thanks anyway :D I hope it's useful to somebody else thus I'm reporting my experience.

Cheers,
MarI/O



{Quote hidden}

>Mario

2011\10\23@101835 by V G

picon face
Just out of curiosity, what are you trying to do with the pic32?

On 2011-10-23, at 9:56 AM, Electron <spam_OUTelectron2k4TakeThisOuTspaminfinito.it> wrote:

{Quote hidden}

> -

2011\10\23@165036 by Electron

flavicon
face

Something that requires good raw computing power. The dsPIC could suffice
but it would draw too much current. I'm evaluating tricky ways to reduce
current consumption on the dsPIC xor move on / convert to the PIC32. Although
I have had PIC32 chips and a starter kit for years, I haven't took a look to
it yet. Both options are quite time consuming and I need to see if the PIC32
route would take too many efforts. The chips are cheap and powerful, they
draw very little current, learning them may be a winner for other future
projects in any case, so it was about a time I had an indepth look at them.


At 16.18 2011.10.23, you wrote:
{Quote hidden}

>> --

2011\10\23@170832 by Yigit Turgut

picon face
On Sun, Oct 23, 2011 at 11:49 PM, Electron <electron2k4spamKILLspaminfinito.it> wrote:
>
> Something that requires good raw computing power. The dsPIC could suffice
> but it would draw too much current. I'm evaluating tricky ways to reduce
> current consumption on the dsPIC xor move on / convert to the PIC32.

Is there a benchmark that has been made with identical algorithms to
compare power consumptions of dsPIC and PIC32

2011\10\23@191332 by V G

picon face
On Sun, Oct 23, 2011 at 4:49 PM, Electron <.....electron2k4KILLspamspam.....infinito.it> wrote:

> Something that requires good raw computing power. The dsPIC could suffice
> but it would draw too much current. I'm evaluating tricky ways to reduce
> current consumption on the dsPIC xor move on / convert to the PIC32.
> Although
> I have had PIC32 chips and a starter kit for years, I haven't took a look
> to
> it yet. Both options are quite time consuming and I need to see if the
> PIC32
> route would take too many efforts. The chips are cheap and powerful, they
> draw very little current, learning them may be a winner for other future
> projects in any case, so it was about a time I had an indepth look at them.
>
>
What's the purpose? Is it for a cost sensitive mass produced product? Or
just a few?

How about a small CPLD? These things run at speeds well over 200MHz and you
could do your calculation in one clock cycle. They draw a lot of power
compared to the PIC32 but you could power them down when you don't need
them

2011\10\24@031003 by Electron

flavicon
face
At 23.08 2011.10.23, you wrote:
>On Sun, Oct 23, 2011 at 11:49 PM, Electron <EraseMEelectron2k4spam_OUTspamTakeThisOuTinfinito.it> wrote:
>>
>> Something that requires good raw computing power. The dsPIC could suffice
>> but it would draw too much current. I'm evaluating tricky ways to reduce
>> current consumption on the dsPIC xor move on / convert to the PIC32.
>
>Is there a benchmark that has been made with identical algorithms to
>compare power consumptions of dsPIC and PIC32 ?

I looked at the datasheets, and was impressed by the difference. In my case
it's like 20mA vs 130mA, as the PIC32 has more features that can be used to
save energy (to say one, you can clock the peripherals at lower frequences
than the CPU, but you still have a 1-cycle counter (which I need bad) that
follows the CPU clock, and the I/O ports remain too at full speed).

The PIC32 is really a couple or three steps forward 24/30/33 chips, although
I loved and still love them a lot. And a dsPIC I used much (the 30F6012) costs
like 5 times more the most featured PIC32 (e.g. 695 or 795 chips). True, 33F
cost less than 30F, but I haven't used any. I will use the PIC32 a lot if the
future as I have many projects which need raw computing power. Moreover, it
doesn't have a DSP core, but at least it can do 64bitAcc+=32bit*32bit operations
in 2 cycles (which don't stall the CPU, so you can do something else in the
odd cycles).

The MIPS is a good platform, although I don't like the asm syntax and it
doesn't even look that good vs ARM or other RISC architectures, but then
benchmarks seem to be all in favour of MIPS. Also, the Microchip implementation
of the MIPS M4K core is all for speed, they seem to have really worked to give
a powerful CPU, as all performance options during synthesis were used (multiple
buses, high performance mul/div, etc..).

2011\10\24@031623 by Electron

flavicon
face
At 01.13 2011.10.24, you wrote:
>On Sun, Oct 23, 2011 at 4:49 PM, Electron <electron2k4spamspam_OUTinfinito.it> wrote:
>
>> Something that requires good raw computing power. The dsPIC could suffice
>> but it would draw too much current. I'm evaluating tricky ways to reduce
>> current consumption on the dsPIC xor move on / convert to the PIC32.
>> Although
>> I have had PIC32 chips and a starter kit for years, I haven't took a look
>> to
>> it yet. Both options are quite time consuming and I need to see if the
>> PIC32
>> route would take too many efforts. The chips are cheap and powerful, they
>> draw very little current, learning them may be a winner for other future
>> projects in any case, so it was about a time I had an indepth look at them.
>>
>>
>What's the purpose? Is it for a cost sensitive mass produced product? Or
>just a few?

Product (sold in the thousands, hopefully, but unlikely more than that).


>How about a small CPLD? These things run at speeds well over 200MHz and you
>could do your calculation in one clock cycle. They draw a lot of power
>compared to the PIC32 but you could power them down when you don't need
>them.

CPLD's would only be able to do (and well) a part of the project. I also
need a proper CPU and program.

I have much experience with FPGA's but zero with CPLD's.. as I understand
it while the former are dominated by interconnect, the latter are by logic.
Gotta play with a CPLD someday.. I just don't have the time right now.

Cheers,
Mario

2011\10\24@035607 by Electron

flavicon
face

PS: for those interested, here's a small introduction to registers and ALU
of the MIPS (PIC32 CPU), read after "A Quick Introduction to MIPS Assembly":

http://www.cs.uiuc.edu/class/fa06/cs232/section/disc1sol.pdf

As you can see coding in assembly is actually easier on the PIC32 than on
the PIC24 or dsPIC30/33 or even more on the PIC.

I use C++ a lot too, so let's not open a debate on asm vs C/C++. I just want
to show that asm on the PIC32 is very easy, once you get bootstrapped. Then
where it's useful or not, only you and the specific project can tell it. But
the false myth that coding for the PIC32 in asm is harder than for the other
PICs must be eradicated. :D As the opposite is actually true..


At 01.13 2011.10.24, you wrote:
{Quote hidden}

Product (sold in the thousands, hopefully, but unlikely more than that).


>How about a small CPLD? These things run at speeds well over 200MHz and you
>could do your calculation in one clock cycle. They draw a lot of power
>compared to the PIC32 but you could power them down when you don't need
>them.

CPLD's would only be able to do (and well) a part of the project. I also
need a proper CPU and program.

I have much experience with FPGA's but zero with CPLD's.. as I understand
it while the former are dominated by interconnect, the latter are by logic.
Gotta play with a CPLD someday.. I just don't have the time right now.

Cheers,
Mario

2011\10\24@040638 by William \Chops\ Westfield

face picon face

On Oct 24, 2011, at 12:55 AM, Electron wrote:

> As you can see coding in assembly is actually easier on the PIC32  
> than on
> the PIC24 or dsPIC30/33 or even more on the PIC.


Thanks for the pointer.

> I don't like the asm syntax and it
> doesn't even look that good vs ARM or other RISC architectures, but  
> then
> benchmarks seem to be all in favour of MIPS.

I've been reading up on ARM and MIPS architectures recently, and I  noticed the same thing.  MIPS doesn't LOOK like it would turn out to  be more efficient than ARM.  Is there analysis somewhere explaining  why it is anyway?  Maybe it's those "immediate operand" instructions.

I had to do a web search for how to do multi-precision arithmetic on  MIPS.
There's no carry flag, so it's sorta gross.  I'm still not sure I  actually believe it works all the time :-(  I never thought the PIC16  weirdness where there was a carry flag but no "add with carry"  instruction would look good...

BTW, I thought the new 16bit PICs had lower power consumption.  A  random PIC24H datasheet says <50mA when running 40mips...

BillW

2011\10\24@043218 by Electron

flavicon
face

Eventually, an even more indepth introduction can be found here:
http://www.eecs.harvard.edu/~ellard/Courses/cs50-asm.pdf

I think the MIPS manuals are not really clear, and they are huge. I suggest,
at least for introductory purposes, to see elsewhere, like in the PDF's I
linked.


At 09.55 2011.10.24, you wrote:
{Quote hidden}

>

2011\10\24@044053 by Electron

flavicon
face

PPPPPPPS: :D Also, this is useful to have always handy:
http://www.mips.com/media/files/MD00565-2B-MIPS32-QRC-01.01.pdf

I'm looking for one with CPU flags and maybe even opcodes, does anyone know
where it can be found?


{Quote hidden}

>>-

2011\10\24@050537 by Electron

flavicon
face
At 10.06 2011.10.24, you wrote:
>
>On Oct 24, 2011, at 12:55 AM, Electron wrote:
>
>> As you can see coding in assembly is actually easier on the PIC32  
>> than on
>> the PIC24 or dsPIC30/33 or even more on the PIC.
>
>
>Thanks for the pointer.
>
>> I don't like the asm syntax and it
>> doesn't even look that good vs ARM or other RISC architectures, but  
>> then
>> benchmarks seem to be all in favour of MIPS.
>
>I've been reading up on ARM and MIPS architectures recently, and I  
>noticed the same thing.  MIPS doesn't LOOK like it would turn out to  
>be more efficient than ARM.  Is there analysis somewhere explaining  
>why it is anyway?  Maybe it's those "immediate operand" instructions.

My idea, but please take it with a grain of salt, is that ARM is superior
but hardly exploitable by complier technology.

Then, by taking a deeper look at MIPS (which I studied 20 years ago and
almost forgot all of it) we can notice that it has some clever instructions
too, so it's not as "simple mind" as it easily appears at the begin.

Please consider also that the PIC32 scores very well vs other ARM MPU's
not only because of MIPS vs ARM, but (IMHO) mostly because Microchip really
did a good job with it, by using multiple buses, high performance mul/div
and other technical solutions that really unleash all the potential of the
M4K core. It looks like in this regard the ARM MPU's manufacturer have much
less care than Microchip did. Also, the Microchip peripherals are good
compared to other MPU's (although I really wish they made them 32bit like
the core, but I won't bother), so all in all, price considered, power
consumption considered, and CPU power, peripherals and configurability
considered, the PIC32 now seems to me a really really nice high perf MPU.

They are going to release SDIP low pin count (>=28 pin IIRC) PIC32's soon,
so it'll become even more interesting.


>I had to do a web search for how to do multi-precision arithmetic on  
>MIPS.
>There's no carry flag, so it's sorta gross.  I'm still not sure I  
>actually believe it works all the time :-(  I never thought the PIC16  
>weirdness where there was a carry flag but no "add with carry"  
>instruction would look good...

Multi-precision arithmetic for me is very important, even of a 32bit CPU.
One thing that disappointed me is that although the PIC32 MIPS core has
32bit*32bit=64bit MULs, it only has 32bit/32bit=32bit DIVs, not 64/32.
However, there's always a limit on the word size of any CPU, so
multi-precision arithmetic is something that must always be taken
into account.

Yes, as incredible as it may seem, the MIPS lacks a carry flag. This is
a distinctive advantage for  out-of-order-register-renamed designs,
although I'm not sure if they made this design choice at that time because
of this. ;-)

Personally I think it would be much wiser (from a "best bang for the buck"
design logic) to implement multiple cores than to pretend from a single core
to execute more than one instruction per cycle. However, my model doesn't
fit with old software, of course.

Regarding MIPS multiprecision arithmetic, you can do it e.g. this way:

       addu        alow, blow, clow
       sltu        tmp, alow, clow                (set tmp = 1 if alow < clow, else 0)
       addu        ahigh, bhigh, chigh        *
       addu        ahigh, ahigh, tmp

If you ask me, I'd prefer to have the carry bit any time, but unfortunately
we don't have it on the MIPS. I just wanna make it clear that multiprecision
arithmetic is entirely possibly on the MIPS of course, although not as
efficiently as an hypotethic:

       addu        alow, blow, clow
       addcu        ahigh, bhigh, chigh


>BTW, I thought the new 16bit PICs had lower power consumption.  A  
>random PIC24H datasheet says <50mA when running 40mips...

Thanks for the hint, I really need to take a look at this option too then,
as I don't really need the DSP core for this project, and a 24F would be OK
too.

Thanks again!

Cheers,
Mario

>
>BillW
>
>

2011\10\24@133719 by Peter Johansson

picon face
On Mon, Oct 24, 2011 at 5:04 AM, Electron <spamBeGoneelectron2k4spamBeGonespaminfinito.it> wrote:

> They are going to release SDIP low pin count (>=28 pin IIRC) PIC32's soon,
> so it'll become even more interesting.

Do you have any details/references for this?

-p

2011\10\24@165538 by Electron

flavicon
face
At 19.37 2011.10.24, you wrote:
>On Mon, Oct 24, 2011 at 5:04 AM, Electron <TakeThisOuTelectron2k4EraseMEspamspam_OUTinfinito.it> wrote:
>
>> They are going to release SDIP low pin count (>=28 pin IIRC) PIC32's soon,
>> so it'll become even more interesting.
>
>Do you have any details/references for this?

Uh, Microchip site, the first 12 from this chart:
http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=211&mid=10&lang=en&pageId=74

Looks like "future product" meanwhile became "in production" for half of them already, e.g.:
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en556007

Cheers,
Mario





>
>-p.
>

2011\10\24@173816 by Electron

flavicon
face

PS: datasheet:
http://ww1.microchip.com/downloads/en/DeviceDoc/61168B.pdf

Please notice they are SPDIP, not DIP (pitch is not the classic breadboard-friendly 0.100 inches).


{Quote hidden}

>

2011\10\24@175937 by Kerry Wentworth

flavicon
face
Actually, SPDIP is 'skinny' DIP, .1" spacing like any other DIP, but the rows are .3" apart, instead of .6" like a 'normal' 28 pin DIP.  Quite 'breadboard-friendly'.

Kerry


Electron wrote:
{Quote hidden}

>

2011\10\24@182802 by IVP

face picon face
> Actually, SPDIP is 'skinny' DIP, .1" spacing

The other one is Shrink DIP, 0.07" x 0.3". A lot of the old Texas
TMS chips are Shrink DI

2011\10\24@184625 by Chris Roper

picon face
That is good to know, thanks.
I think I will get a few in stock to play with, I am loving the PIC32
on the CHIPKit Uno and would love to have that number crunching power
on a breadboard.
I just wish we had a C++ compiler in MPLAB (/me ducks to avoid the bricks)


On 24 October 2011 23:57, Kerry Wentworth <EraseMEkwentworthspamskunkworksnh.com> wrote:
{Quote hidden}

>

2011\10\24@190705 by V G

picon face
On Mon, Oct 24, 2011 at 6:46 PM, Chris Roper <RemoveMEcaroperspam_OUTspamKILLspamgmail.com> wrote:

> That is good to know, thanks.
> I think I will get a few in stock to play with, I am loving the PIC32
> on the CHIPKit Uno and would love to have that number crunching power
> on a breadboard.
> I just wish we had a C++ compiler in MPLAB (/me ducks to avoid the bricks)
>
>
They're (DIP versions) not available for ordering/sampling until at least
December as far as I can see. But excellent price and package format. Super
easy to throw in a breadboard and no reason to choose a smaller PIC over
them for most people. At Around $2.50 in singles for the biggest 28 pin DIP,
it's an excellent competitor for that AVR chip every script kiddy loves to
hype about

2011\10\25@035310 by William \Chops\ Westfield

face picon face
I think I'm losing confidence in Microchip's compiler expertise...

What's the point again of defining the SFR addresses in the linker  instead of in the C include files?
It seems to prevent a significant slew of "obvious" optimizations, and  there is still a huge per-chip source include as well, so it's not  really moving any chip dependencies to link time...

    digitalWriteFast(3,1);  // compiles to LATxSET = b
9d00135c:       24020001        li      v0,1
9d001360:       3c03bf88        lui     v1,0xbf88
9d001364:       ac6260e8        sw      v0,24808(v1)
    digitalWriteFast(3,0);  // compiles to LATxCLR = b
9d001368:       3c03bf88        lui     v1,0xbf88
9d00136c:       ac6260e4        sw      v0,24804(v1)

Love that double load of identical constants!

Is this the sort of thing that Microchip's "global optimization" fixes?

Grr.
BillW

2011\10\25@070947 by Electron

flavicon
face
At 23.57 2011.10.24, you wrote:
>Actually, SPDIP is 'skinny' DIP, .1" spacing like any other DIP, but the
>rows are .3" apart, instead of .6" like a 'normal' 28 pin DIP.  Quite
>'breadboard-friendly'.

I'm pretty sure I saw SDIP with smaller spacing.. however I'm glad you're right
at the very least on this PIC32 issue, I checked the datasheet and it's indeed
0.100 as you wrote, so these PIC32 become very hobbyst friendly.

Meanwhile I have coded more for them (in assembly and in C) and I must say I am
more and more impressed by the ease (in asm) and power of these "little" MPU's.

Cheers,
Mario


{Quote hidden}

>

2011\10\25@072428 by Electron

flavicon
face
At 09.53 2011.10.25, you wrote:
>I think I'm losing confidence in Microchip's compiler expertise...
>
>What's the point again of defining the SFR addresses in the linker  
>instead of in the C include files?
>It seems to prevent a significant slew of "obvious" optimizations, and  
>there is still a huge per-chip source include as well, so it's not  
>really moving any chip dependencies to link time...
>
>     digitalWriteFast(3,1);  // compiles to LATxSET = b
>9d00135c:       24020001        li      v0,1
>9d001360:       3c03bf88        lui     v1,0xbf88
>9d001364:       ac6260e8        sw      v0,24808(v1)
>     digitalWriteFast(3,0);  // compiles to LATxCLR = b
>9d001368:       3c03bf88        lui     v1,0xbf88
>9d00136c:       ac6260e4        sw      v0,24804(v1)
>
>Love that double load of identical constants!
>
>Is this the sort of thing that Microchip's "global optimization" fixes?

I hope so. Oh, and that was digitalWriteFast, I have seen more horrific
output from the compiler. :D

This is an example (but there could be more and better) that asm is not
finished on the PIC32, where actually it's even easier than in dsPIC or
PIC.

I prefer to code in asm, if I am in a hurry I do write a function in C,
develop, debug.. when I'm happy with it, I rewrite it in asm, maybe even
taking a look at the disassembly of it.


>Grr.
>Bill

2011\10\25@095345 by Wouter van Ooijen

face picon face
>  I'm pretty sure I saw SDIP with smaller spacing.. however I'm glad you're right
> at the very least on this PIC32 issue, I checked the datasheet and it's indeed
> 0.100 as you wrote, so these PIC32 become very hobbyst friendly.

Glad I saw this topic started on the PICList. If I am not mistaken these are the very first 32-bit microcontrollers in a hobbyist-friendly (DIP) package!! I had my reservations about the PIC32 (Cortex seems to be the wave now), but this can change the hobbyist world.

One missing piece for me is C++ support. Anyone knows what Microchip is up to?

--
Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2011\10\25@101300 by Wouter van Ooijen

face picon face
> Glad I saw this topic started on the PICList. If I am not mistaken these
> are the very first 32-bit microcontrollers in a hobbyist-friendly (DIP)
> package!! I had my reservations about the PIC32 (Cortex seems to be the
> wave now), but this can change the hobbyist world.

Microchip will probably be first, but not the only one with DIP 32-bit uCs:

(From the LPC2000 group)

NXP today announced the availability of new low-pin-count package options -- SO20, TSSOP20, TSSOP28 and DIP28 -- for its market-leading ARM(R) Cortex(TM)-M0 LPC1100 family of microcontrollers. The new LPC111x devices are the world's first 32-bit ARM microcontrollers in low-pin-count packages, and open the door for a broader range of applications previously closed to typical 32-bit MCUs due to package footprint or manufacturing constraints. Starting at $0.49, NXP's low-pin-count devices deliver 50 MIPS of performance compared to the 1 to 5 MIPS performance typical of 8/16-bit MCUs, at a highly competitive price point enabled by NXP's exceptional capacity in manufacturing high-volume commodity packages.


--
Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2011\10\25@110322 by William \Chops\ Westfield

face picon face

On Oct 25, 2011, at 6:53 AM, Wouter van Ooijen wrote:

> If I am not mistaken these are the very first 32-bit  
> microcontrollers in a hobbyist-friendly (DIP) package!!

Yes, it will be interesting to see if Microchip gets laughed at or ...  followed by the industry as a whole.
TI made a similar decision with their low-end MSP430 chips; the first  MSP430s release in DIP form were well into the product-line  lifecycle.  Since there have been followons since, I guess it hasn't  been seen as an internal disaster. (The infamous LaunchPad would have  been cheaper (to manufacture) if the target CPU had been SMT...)

BillW

2011\10\25@110657 by William \Chops\ Westfield

face picon face

On Oct 25, 2011, at 7:12 AM, Wouter van Ooijen wrote:

> The new LPC111x devices are the world's first 32-bit ARM  
> microcontrollers in low-pin-count packages

Well, that's not true.  The first CM3's on the market, from Luminary  Micro (now part of TI) included a 28pin SOIC.  And NXP themselves  already has the LPC1102 (16 balls; itty bitty package.)

BillW

2011\10\25@112152 by Wouter van Ooijen

face picon face
>> If I am not mistaken these are the very first 32-bit
>> microcontrollers in a hobbyist-friendly (DIP) package!!
>
> Yes, it will be interesting to see if Microchip gets laughed at or ...
> followed by the industry as a whole.

IMO having at least one DIP chip in a product line opens it up for hobbyists and students. Though these might be an insignificant market in themselves, they do cause a lot of www coverage, and might be the future professionals...

--
Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2011\10\25@113515 by V G

picon face
On Tue, Oct 25, 2011 at 11:21 AM, Wouter van Ooijen <EraseMEwouterspamspamspamBeGonevoti.nl> wrote:

> IMO having at least one DIP chip in a product line opens it up for
> hobbyists and students. Though these might be an insignificant market in
> themselves, they do cause a lot of www coverage, and might be the future
> professionals...
>
>
Exactly. Such is the reason for the unfortunate rise to fame of the AVR

2011\10\25@113719 by Ariel Rocholl

picon face
Agreed. From what I heard, MC did mistakenly thought the "PIC32 starter kit"
would take the place of intro device format for hobbyists. And that may have
worked out perhaps, but the fine pitch connector included for "expansion"
was useless for hobbyists and even professionals. I find TI starter kit
boards way more convenient, you can really work out their entry micros
regardless they are not DIP format as the breakout board offers most, if not
all, the pins easily accessible in 0.1" pitch...

-- Ariel Rocholl
http://www.rf-explorer.com

On Tue, Oct 25, 2011 at 5:21 PM, Wouter van Ooijen <RemoveMEwouterKILLspamspamvoti.nl> wrote:

{Quote hidden}

2011\10\25@121956 by Peter Johansson

picon face
On Tue, Oct 25, 2011 at 11:03 AM, William "Chops" Westfield
<westfwSTOPspamspamspam_OUTmac.com> wrote:

> TI made a similar decision with their low-end MSP430 chips; the first
> MSP430s release in DIP form were well into the product-line
> lifecycle.  Since there have been followons since, I guess it hasn't
> been seen as an internal disaster. (The infamous LaunchPad would have
> been cheaper (to manufacture) if the target CPU had been SMT...)

TI is clearly trying to break into the hobbyist market with the G2
chips in DIP and the Launchpad.  I think they have achieved a fair
degree of success, but only a fraction of the potential.  The MSP430
is an absolutely wonderful architecture to work with -- modern enough
to be easy to use (having none of the legacy headaches associated with
8-bit PICs) and without the complexity associated with 32 bit MCUs --
yet you would never know this from the marketing materials.  The
LaunchPad is clearly aimed at the Arduino, yet lacking the simple
cross-platform IDE and easy-to-use libraries (not to mention all of
the add-on hardware support libs) the learning curve is still quite
steep.

I have a suspicion that an unfortunately large number of LaunchPads
wind up collecting dust in the back of a drawer or shelf, but that is
absolutely no fault of the hardware whatsoever.

-p.

2011\10\26@044731 by William \Chops\ Westfield

face picon face

On Oct 25, 2011, at 4:23 AM, Electron wrote:

>>
>>    digitalWriteFast(3,1);  // compiles to LATxSET = b
>> 9d00135c:       24020001        li      v0,1
>> 9d001360:       3c03bf88        lui     v1,0xbf88
>> 9d001364:       ac6260e8        sw      v0,24808(v1)

>> that was digitalWriteFast, I have seen more horrific output from  
>> the compiler.

That does look pretty optimal for setting an output pin; I'm happy  (aside from the lack of optimization when manipulating other pins  "nearby" in the code.)  (digitalWriteFast() is a macro to implement  the digitalWrite() "standard Arduino function" when all the arguments  are constants.  A horrible kludge depending on gcc features and  compile-time optimization.  But about 20x faster than the function.

BillW

2011\10\26@061709 by Isaac Marino Bavaresco

flavicon
face
Em 26/10/2011 06:47, William "Chops" Westfield escreveu:
> On Oct 25, 2011, at 4:23 AM, Electron wrote:
>
>>>    digitalWriteFast(3,1);  // compiles to LATxSET = b
>>> 9d00135c:       24020001        li      v0,1
>>> 9d001360:       3c03bf88        lui     v1,0xbf88
>>> 9d001364:       ac6260e8        sw      v0,24808(v1)
>>> that was digitalWriteFast, I have seen more horrific output from  
>>> the compiler.
> That does look pretty optimal for setting an output pin; I'm happy  
> (aside from the lack of optimization when manipulating other pins  
> "nearby" in the code.)  (digitalWriteFast() is a macro to implement  
> the digitalWrite() "standard Arduino function" when all the arguments  
> are constants.  A horrible kludge depending on gcc features and  
> compile-time optimization.  But about 20x faster than the function.
>
> BillW
>


I agree.

What the OP wants?
I can see "load the bit mask" -> "load base address" -> "output the
value at base address+offset".
How could it be optimized further? Only if he preloads everything, but
then he would have two wasted registers.


Isaac

2011\10\26@110839 by Electron

flavicon
face
At 10.47 2011.10.26, you wrote:
>
>On Oct 25, 2011, at 4:23 AM, Electron wrote:
>
>>>
>>>    digitalWriteFast(3,1);  // compiles to LATxSET = b
>>> 9d00135c:       24020001        li      v0,1
>>> 9d001360:       3c03bf88        lui     v1,0xbf88
>>> 9d001364:       ac6260e8        sw      v0,24808(v1)
>
>>> that was digitalWriteFast, I have seen more horrific output from  
>>> the compiler.
>
>That does look pretty optimal for setting an output pin; I'm happy  
>(aside from the lack of optimization when manipulating other pins  
>"nearby" in the code.)  (digitalWriteFast() is a macro to implement  
>the digitalWrite() "standard Arduino function" when all the arguments  
>are constants.  A horrible kludge depending on gcc features and  
>compile-time optimization.  But about 20x faster than the function.

A but OT:

for a start, I think it makes a sense to devote on of the 32 CPU regs
to the SFR base ( @ BF88 ). In the original code (not shown above),
LUI V1,0xBF88 is repeated every time. Ok, probably with the optimizer
on (which is only available for 60 days for common mortals) it will
be eliminated, but then again I decided to use asm as a main language
on the PIC32 (and eventually add some C functions where necessary) and
devoting a CPU reg for the SFR base looked like a good idea to me (if
I'll ever need that reg, I will use it and then restore it to the SFR
base).

Also, I don't like that the SFR's are linker objects, I am making a
set of includes ( _LATDINV, etc.. ) to be used as offsets for the SW.

Cheers,
Mario


>
>BillW
>
>

2011\10\26@111059 by Electron

flavicon
face
At 12.17 2011.10.26, you wrote:
{Quote hidden}

The incriminated code was:

    digitalWriteFast(3,1);  // compiles to LATxSET = b
9d00135c:       24020001        li      v0,1
9d001360:       3c03bf88        lui     v1,0xbf88
9d001364:       ac6260e8        sw      v0,24808(v1)
    digitalWriteFast(3,0);  // compiles to LATxCLR = b
9d001368:       3c03bf88        lui     v1,0xbf88
9d00136c:       ac6260e4        sw      v0,24804(v1

asm instruction #4 is redundant (IMHO even the #2, as a register should
be devoted to store the SFR base at ~all times, as we're talking about
a MPU here, not WindowsNT code in ring3).


>I can see "load the bit mask" -> "load base address" -> "output the
>value at base address+offset".
>How could it be optimized further? Only if he preloads everything, but
>then he would have two wasted registers.
>
>
>Isaac
>
>

2011\10\26@111137 by William \Chops\ Westfield

face picon face

On Oct 26, 2011, at 3:17 AM, Isaac Marino Bavaresco wrote:

> What the OP wants?
> I can see "load the bit mask" -> "load base address" -> "output the
> value at base address+offset".

The original complaint was against the slightly larger piece of
source code for:
  digitalWriteFast(3,1);
  digitalWriteFast(3,0);
Which produced:
  li      v0,1
  lui     v1,0xbf88
  sw      v0,24808(v1)
  lui     v1,0xbf88
  sw      v0,24804(v1)
Which has an obvious extra instruction.
In a loop, two different registers are used to hold the (same)
address "page" of two io registers.

It's similar to setting the RAM page explicitly for every access
on PIC16; not really horrible, but exactly the sort of thing that
I would hope a compiler would NOT do.  I guess Microchip is really
hooked on the idea!  :-)

BillW

2011\10\26@125640 by Isaac Marino Bavaresco

flavicon
face
Em 26/10/2011 13:11, William "Chops" Westfield escreveu:
{Quote hidden}

I'm pretty sure that with optimizations on, the compiler would remove
the redundant instructions.


Isaac

2011\10\26@141832 by William \Chops\ Westfield

face picon face

On Oct 26, 2011, at 9:56 AM, Isaac Marino Bavaresco wrote:

> I'm pretty sure that with optimizations on, the compiler
> would remove the redundant instructions.

It would have to be done at link time rather than compile time,  because the actual SFR addresses aren't defined until link time.   That's why my original message in this sub-thread was questioning the  wisdom of defining SFR addresses at link time.  (the redundant  instructions are created with (gcc) compiler optimizations turned on;  frankly I don't see how they can be avoided if the SFR addresses  aren't known at that point.  It's not even a gcc "failure to  optimize"; it's not having the right info (constants) at the right  time...)

(Can someone run the code segment through the full optimizing PICC32  compiler and see if it does better?  A code segment like this should  be sufficient:
  LATBSET = 1;
  LATBCLR = 1;
)

BillW

More... (looser matching)
- Last day of these posts
- In 2011 , 2012 only
- Today
- New search...