In case of PIC: keep on dreaming! If your project grows bigger than 10 lines you have to use pragmas to tell the compiler where to store the data. PIC stands for Pic Is Crap.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
In that case download one of the many interactive CPU simulators or write software on a PC and debug from there. There is not much use for single stepping microcontrollers. If you start with microcontrollers you really need to be past the point of needing to single step your software on assembly level.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
I've been using PIC, mostly because I'm all set up to deal with it. PicBasic Pro has lots of macros to do stuff you'd normally like to do. It's expensive, but I got mine free with some hardware junk I bought. I've tried to get up and running with the GCC stuff, but never found anywhere near the macro library capability. Just not worth the change in methodology.
I've used the 16F877a mostly. Once you get a serial port hooked up and a bootloader, you're good to go. You do NOT wanna be unplugging chips to stick 'em in a programmer.
I've found real-time debugging useless, cause it ain't real time. Simulation is even worse. Virtually everything I've ever done has interrupts. And you just can't simulate that reasonably.
There's almost always some asm involved. A compiler with inline assembly is a necessity.
If your compiler has a good set of debugged macros, the actual code you need to debug is pretty simple.
I built a keyboard and lcd character display, but rarely use it.
For hobby projects, I start with a Palm IIIC to do the heavy computing. When I run out of steam there, I use the serial port to interface a PIC for the intermediate data handling. If that's still not fast enough, some stuff gets done with real hardware.
You can plug on infrared or bluetooth/serial/usb adapters for interface to a real PC. I even made a PIC talk GPIB out one end and bluetooth out the other. I've never had the need to program usb into the uC.
So, decide what hardware interfaces you need. Pick a language and a compiler. Then go looking for a chip. Pay close attention to the whole family for compatibility. Don't remember the exact details, but I was looking at the $1 6-8pin pics. Discovered that they're one time programmable. The programmable one costs $10. And the programmable one was dip only and the cheap ones were tiny smt only. Would have been a real hassle for hobby projects.
I'm stuck with PIC, but If I were starting now, I might consider the Arduino stuff. For extreme low power, the TI stuff looked interesting, but I never found any other reason to use it.
Don't overlook a serial/serialIR/serialbluetooth connection to a Palm III as a user interface. They're under a buck at garage sales and save you a lot of programming. They handle big numbers much better. Have lots of ram. Touch screen. The demo version of hotpaw basic is a fine language for writing GUI user interfaces on the palm.
Debugging (on PICs that have the on-chip debug hardware) is real time. There are hardware registers for breakpoint(s) built into the chip. It does use the two ICP pins, a bit of RAM, some flash, and one stack level.
I find simulation invaluable. It makes it easy to run dozens of test cases without having to build up hardware to give an equivalent window into the processor operations. These days with serial LCD displays being relatively cheap.. that's another option, but simulation on MPLAB (using stopwatch) also gives you cycle-accurate counts of execution times- which can be very important in real-time applications. Few, if any, other IDEs have that feature.
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
On a sunny day (Wed, 11 Jul 2012 08:05:15 -0400) it happened Spehro Pefhany wrote in :
Maybe for some, I find I need an output pin and a scope, tha tis all On PIC I have not used C on PICs and never MPlab (waste of time). I have done video with 12F... PIC and H,V sync detection and video processing that way, and no problem. I would not trust a simulator for a micro second, only the real thing. It is all double work, using mplab, because only the real thing will tell you if it works. Not in the least because of all the PIC hardware bugs, bit of a disappointment if you write your SPI code in mplab, and it works, but not in real life! And that goes for a zillion other PIC bugs, work around it (if possible) by doing it all on the chip. And not only PIC, that goes for ANY processor. Just got a new ARM board with Linux in that sort of looks at me if I can hack it..
How are you going to test and debug corner cases on a fixed-point control algorithm with an output pin and a 'scope? I guess you could send serial data out, read it on the 'scope and figure out the numbers from that, but that's pretty tedious.
It's making sure all the stuff inbetween input and output works (as components and as subsystems) that I'm concerned about. I can test C stuff on a peecee, and I have routines that simulate certain fixed point operations, but it's better to look at the real thing. It would be nicer to have conversion routines and not use MPLAB, but I'm not ambitious enough to put the effort into to creating that kind of tool, even if the documentation existed to do it.
On a sunny day (Wed, 11 Jul 2012 12:40:38 -0400) it happened Spehro Pefhany wrote in :
OK, lets get a bit deeper. When I program in asm on PIC I usually start with the boot and serial I/O. Then the drivers for the various hardware interfaces. This is an important point, I have a library with 8, 16, 32 bit hex and decimal printing RS232 routines, so it is just like [using] printf to insert those after a piece of code.
There is an other VERY important reason not to use a 'simulator (mplab here), usually the PIC is connected to the outside world, that could be chips or an LCD, or some other hardware. This cannot be simulated, so in the simulator you work blind anyways. I always work from bottom up, so I get the communication, user input (buttons, whatever) and those chips or whatever it is, working, maybe even the LCD, BEFORE starting on the grand work where you do mysterious math on mysterious data. Usually there is flimsy little RAM to do that anyways, so forget about C, better us asm and every byte available, preferably several times. It is very different from programming on a PC in C where you can just put a temp array of a MB or so on the stack.
I can only give practical examples, but here are some: In the ethernet-color-pic project I first wrote the drivers for SPI to drive the Microchip ethernet chip in C on the PC, with SPI via par port, as I never used that chip, and had to write the TCP/UDP stack too. No simulator needed, just the real chip on the real PC connected to the real LAN. Once I knew the chip (and its limitation), I simply rewrote the C code in PIC 18 asm, did not take that long. Added some stuff, was easy as everything now worked. Of course PIC SPI hardware did NOT work, due to PIC hardware bug, but now I knew it was PIC, not my code. And I already did the SPI in software on the PC, so I could just use that.
For the 'scope-pic project I wrote the FFT routines in C, tested these, and when it worked then recoded it is PIC18 asm, added some stuff. No need for simulator. Every RAM byte is used several times in that project, for display, for scope, and for FFT temp data..
I once wrote a PIC emulator, for 16F84, sort of a dis-assembler to crack smartcards, all in C. A 16F84 in C. :-) Then they went after 'hackers' you know, and dunno where that code is now.
It is sort of natural thing to do when you start on a new micro, I wrote an assembler for the 8052, a disassembler for the Z80, etc etc. Also I wrote the PIC 18 programmer in C for on the PC.. All this soft is on my website freely downloadable.
Converting from C to very optimized PIC asm by hand is actually not hard, it is fun.
Many many years ago I had a book on ARM processors, and I think I threw it away one day. I do not really like RISC in the sense that too many instructions to do some things, I like high level instruction sets. so programming in C and letting the compiler figure it out for ARM seems the sensible thing to do for now.
I got one of those little wireless IP cameras from ebay, movable, it turns out the thing has an ARM processor and runs Linux,
formatting link
there is its board, hidden serial interface, JTAG, same story over again as with the Linksys router (MIPS).
formatting link
Lots of people are playing with this camera type, comes under many brands, I contacted the Chinese manufacturer... Need to fix some bugs.. :-)
Actualy the Tritium decay experiment I wrote in PIC 18 ASM directly, with i2c routines in software tested in C first. Checked yesterday, has now an uptime of almost 60 days, zero errors so far. Same story, uses i2c to interface to those Microchip serial EEPROMs that do NOT really have the auto address increment they suggest they have. Was a tricky thing to find. But at least I knew my i2c routines were OK.
On a sunny day (Wed, 11 Jul 2012 12:02:28 -0700) it happened mike wrote in :
I dunno, I wrote it, it is in almost any PIC asm code on my site
formatting link
That code also includes several LCD drivers.
Yes, I have that, but to me it makes things more complicated...
Well, C was also invented to sort of do printing formatting, I do not use floating point in a normal way, but do everthing in integer and then add the dot at the right place afterwards. The 32 bit math I use is from somebody else, also in that code.
32 bits is enough for most work.
If you need a lot of floating point maybe BASIC or C is easier, but I even did the scope FFT stuff in integer.
There is also a big PIC website or forum with many good asm routines, I have useed some of that too.
There is a bunch of new ones under $2.50 (in singles from MicrochipDirect) and in 28 pin SPDIP for proto-boards. And the free C compliers is pretty good.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
People keep repeating misinformation, or they are not really up-to-date wit= h current technology. PIC32 is no PIC. The re-mappable pins simplify layo= ut jobs and it's the best feature in any micro. Yes, it might be slightly = more expensive than ARM CM3, but can't rule it out just because it's PIC. = Perhaps, Microchip should rename the PIC32 family to: NPIC32?
Why bother if you can get an ARM? A cpu at tens of MHz in a DIP package doesn't sound like a good idea. Better buy a small board with DIP style headers.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
Because we found that Microchip is more responsive than most other ARM dealers, especially in the good old USA.
Agree. 28 pins DIP is huge and expensive (for PCB). Fortunately, it also comes in 5mmx5mm 28 pads QFN. That would be the smallest micro with OTG USB, as far as i know.
That rather depends on how much computing power you need. It's just a fact that far more small uP/uC are sold than large ones. - so they must be good for something.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
But the 3mm x 3mm 20 pads QFN RF transceiver does not have DIP version, so we go straight to PCB. It's a specific example in our case, but not uncommon issue.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.