PICBasic or BasicStamp -- ?

Nowadays I think that the preferred entry to embedded development would be the Arduino family. It is an open platform, hardware and software, with a considerable number of daughter boards (known as "shields") to implement various auxiliary functions.

On a sunny day (Fri, 26 Nov 2010 14:12:50 +0100) it happened Geir Holmavatn wrote in :

If you are talking about 'devices' you can do all that with some PICS. If you are talking 'boards' I would get one that runs Linux. In the last case the processor may be less of an issue, and TCP stack, USB, serial, and anything you want has already be implemented, and you can simply probram in C using the gcc compiler and libraries.

If you go 'devices' you will need to learn asm very likely for 'device'.

WTF not start with a simple PIC and flash a LED?

I have been pleased with and impressed by the Melabs BASIC Compilers. (There are also low cost/free C Compilers available.) Melabs also offers prototyping boards and displays.

The resulting code runs much faster than the equivalent Stamp code.

A nice side effect of using these compilers is that you can inspect and study the (commented) assembler code generated by the compiler. This helps immensely in the understanding of the PIC architecture(s) and helping you potentially write your own assember code.

My applications are quite simple - RS232, LCD interfaces so I cannot comment on your communication (TCP/IP, Ethernet) requirements.

TomC

There is no decent free C compiler for PIC. Actually the ones you pay for are not so good either.

Stay away from PIC. Its a very obscure and outdated architecture.

No. Look for ARM controllers from NXP, ST, Texas Instruments, etc. They come in many flavours and price ranges. Most new designs are based on ARM controllers. The newer ARM Cortex-Mx devices do not need a single line of assembly to start the controller. There is also no need for 'magic' interrupt routines. Knowledge of the C language is all you need.

Try olimex.com

Hi-Tech C is not decent? (honest question) There's a free version (of the fairly expensive compiler) that's unlimited, just doesn't have optimizations which for what I do hardly matters, anything that's time-sensitive gets done in assembly and PIC18F's have plenty of code space.

I just did a project using a PIC18F2525 (~4KB ram, 24KW rom) and found the part to be just what I needed. 32mhz internal osc, can switch speeds under code control, 8mhz SPI buss, bitbanged SPI at about 1mhz to access a VDRIVE (11 bit SPI + status bit), can self-program its flash rom for bootloaders. For loads of I/O I used MCP23S17 port expanders so the PIC itself could be small. If interested, google: PIC18F2525 MCP23S17 VDRIVE

PICs may be old but that means stable with a well-established toolchain and community of users. "Outdated" depends on what needs doing, PICs are fine for what I (and many others) do with embedded processors. There is no one-size-fits-all, thankfully a wide range of slow (and easy) and fast (and complex) processors are available to do everything from light a low-voltage LED to run a cell phone with graphics.

In regards to the O.P. for ethernet then a PIC might not be fast enough unless a relatively slow data rate is good enough. There are however PIC18F's with ethernet built-in and a free stack... first hit when typing PIC18F ethernet into google.

no :-) it's a steady workhorse great for reading inputs and toggling pins. ARMs etc can run real operating systems at several hundred mhz. PICs top out at 40-50mhz. PICs are useful when simplicity and very low power consumption is needed, and fast processing isn't.

Terry

I really liked HiTech C back in the day. It was such an amazing improvement over the wart-encrusted PicC that it was worth the porting nightmare caused by the completely incompatible libraries.

The other very great advantage of PICs is that Microchip never discontinues them, so you don't get Maxim-ized just because your gizmo stays in production for 5 or 10 years.

Recently I've been using AVRs since the client likes them, and they're okay too--the gnu toolchain works well enough so far.

Cheers

Phil Hobbs

Yes. The command line options don't work as expected. Try to tell it the name of the output file AND the directory where to put the output files. And it needs to be told in which memory bank to put the variables.

Not necessarely. Look at the ARM7TDMI and Cortex-Mx devices. These cores are targeted at microcontroller applications without OS.

Look for Cortex-M0 devices from NXP; these are ultra low power. As a bonus: the faster you process, the shorter you need power.

I have no C libraries so that's not an issue. Actually I rather hate C. I'm sort of looking for a reason not to use it but at the same time I probably need to give up my archaic ways and make peace with the more modern stuff. But only if I can guarantee reliability.

The main thing that makes me nervous about any closed-source compiler is no source so I can never be sure it really works without auditing the assembly output itself, which can be a major task. So for critical stuff I'll probably end up making my own stateless pattern-match "compiler" where each language form emits a specific ML sequence each time with no variation other than parms. Then I just have to prove each sequence is correct and make sure I didn't flub the if then else jump/label generation. I already use such a pattern compiler for PIC16, works great. Last change to it was in 2001.

Exactly. For new stuff it's sometimes hard to find samples, let alone production quantities, and I need to guarantee best I can availability for at least 5 years, preferably 10-15. Occasionally PIC's go out of production but the pinouts stay the same. I can still get compatible parts for PIC16C56.

AVR's are the only serious alternative I see for the kinds of tasks I need to do, especially considering the GNU tools. But still, PICs appear to be the best parts for my apps.

Terry

I typically expect that all files related to a source compilation appear in the same dir as the source and named with the same base name. However I just tried changing to a different directory and specifying the path to the source, output appears in the directory I changed to. Perhaps it wants to write output to the current directory, sounds reasonable. Change directory to where you want output.

That sounds like a good feature. In my last hobby project I had direct peek/poke buffers that the BASIC compiler I was using didn't know about, fortunately variables always started from 0 and grew up, strings started at the top and grew down, I put my stuff in the middle well out of the way. It would have been better if I could tell the compiler exactly where I wanted it to put everything, spitting out errors if I crossed a line.

One weird thing about HTC is it compiles code from the top of rom down, so I have to tell it how high it can go using --rom.

Sorry I don't see too many for sale at Digikey, around here if they have it, it's probably too risky to use. For Cortex-Mx I saw a $4000+ dev board at Mouser.. no thanks :-)

More in the range, still not much selection. Those 16-ball ones are cute. I prefer DIP for perfing and SOIC or TSSOP for production (someone's gotta hand-make the protos, usually me). With a plain $1 PIC in a simple app I can usually get average drain of 50uA or less, that's fine.

I will keep parts like that in mind if I need to do something fancy... but if I needed something with a lot of horsepower I'd be inclined to use a ready to go module and be done with it. Unless I needed large numbers the dev cost would outway the savings of trying to design my own system.

Back to the original subject of an easily programmed ethernet system... one option might be a multi-processor setup - program one of those ethernet-equipped processors with just the stack and as big of buffers as will fit, then put the app in another processor that can be programmed with PICBASIC or whatever and it can send/receive raw data to and from the ethernet processor, thus not bogging down the app with net stuff.

Terry

You are not looking properly. Just a few links:

Putting an ARM controller from NXP on a board is really easy. Keil has excellent example diagrams on their website. The only thing you need to program NXP's ARM microcontrollers is a serial port and Flashmagic (free).

Aaaarghhhh! Multi-processor systems are the hardest to program. This is where most PIC users take the wrong turn. If a PIC is no longer up to the job don't use more PICs but move to another platform!

If you use the LPC1768 you can download a complete software package from freertos.org for it and get started.

Is this the vDRIVE ??

I was insomniac'ing... ok M0 M3 Mx got it

...

Pretty nice, esp. the LPC1313, price is right but got to watch out for hidden costs.. most if not all of what I do require 5V operation and I/O, I prefer internal osc since crystals can be problematic (shock, an extra part), all that can get expensive and far exceed the cost of the processor. Important to match the processor to what needs doing.. most of my real-world needs are served by a PIC12F675 (8 pins, 1K rom, a few dozen bytes of ram, they make 'em by the millions). When I need more power it's usually for a single tester or a hobby thing, for that kind of stuff through-hole (16-28 pins) is better for me.

The dev boards are interesting... bookmarked. The LPC1766 board looks like it would handle the OP's app.

So bootloader is built in. That is a plus.

I disagree. How can using a dedicated processor to offload a compute-intensive task make it harder to program? Last time I did this (a few months ago) I needed a tester with a steady programmable oscillator which didn't need many frequencies but had to be rock-solid. So I used two PIC16F684 14-pin processors, one for the oscillator which I programmed in assembly, another for the control program which I programmed in HLL. Oscillator PIC had 3 pins which it checked at each zero-crossing, carefully subtracting the time that took to avoid distortion. If the inputs were different than the last input, it stopped the current tone, delayed a bit for pin bounce and reloaded the pin states, then performed the command. The main PIC simply wrote what it wanted the oscillator to do to the control pins.

Not hard at all to program, worked first time. Would have been MUCH harder to program this into a single processor. As soon as interrupts are enabled, life just got difficult.

And spend weeks designing and programming a system that could have been done by a couple of $3 parts. It's not the lack of horsepower, it's the division of tasks. A timing sensitive task works better when it doesn't have to deal with the user pressing buttons and a control app works better when it doesn't have to go to great lengths to make sure it doesn't disturb the timing-sensitive task.

Multi-processing most definitely was not a wrong turn in this case, the tester is on a factory floor performing its task and it didn't cost an ARM to make it. Also, imagine how poorly PC's would perform if the CPU had to perform graphics primitives. Multiprocessing is everywhere if you look. Even in the old days mainframes used peripheral processors so they didn't have to constantly check to see if a user pressed a key. For that matter, these days both the keyboard and the mouse contain a processor, usually a lowly 8-bitter as anything more would increase the cost too much.

Or apparently a PIC18... checking it out.

Terry

Not the one I'm referring to, which is a USB disk module with a built-in FAT operating system, the processor sends commands to it to read and write files on a thumbdrive or other USB-attached disk. This web news thing I'm using won't let me post links (or any long lines) but it's at ftdi dot com under products, modules, application modules. Digikey # 768-1003 about $25 ea.

Terry

SNIP

That is one of the main reasons I've stayed with PICs.

In the past I've had both Philips and Siemens drop me in it by discontinuing 8051 family micros without a plug in replacement. I've just had to discontinue an early 90s design based on the 80C537 because of this. The volumes didn't justify reengineering.

The other thing is I've never known PICs on long lead times. It may take a few weeks to get a particular varient but never months. I remember, arounfd the mid 90s a rep trying to get me to move from the PIC to the ST6. I was tempted until I found out they were on allocation and 40+ weeks lead time.

PICs are crap but reliable, never obsolete and always available. More than I can say for Fairchild FETS at the moment, FDD5612s quoted as June delivery:( Had to get old non ROHS parts from the US to keep production going.