On Sat, Mar 23, 2013 at 07:59:51AM -0500, Martin McCormick wrote: > Christopher Head writes: > > Will gputils not serve the purpose if you are looking for an assembler? > > I have no idea which parts it supports versus which parts you are > > interested in, but it seems to work OK for me. For simulation there is > > also gpsim, but I have not tried it. > > Thank you. This is a great help because I suspect I am > more likely to get gpasm and gpsim working than I am to get > mplab-x working. > > I do not presently have a working X environment in Linux > although one system I have should run it but refuses to so far. > I've never tried to unbundle MPLAB-X in a non-X environment. I can tell you that there is a command line assembler in the bundle which works fine once it is installed. As for X, I really cannot think of the last time it didn't "just work". If you like drop me a line off-line and tell me a bit more about your environment. Maybe we can get it figured out. > gputils and gpsim appear to be in the same linage as > what I originally had on here so this should get me back to > where I was before more than likely. True. > > As for the parts, nothing really exotic-- PIC16F84's, > 16F628's and several really old PIC's that are UV-erasable. > I might as well use them in simple projects as they don't spoil. > I think the PicStart plus will program every PIC I presently > have in the parts cabinet so all that is needed is working > software to drive the programmer. That presents an interesting catch-22. You have the parts/tools for old sto= ck. However, the newer parts bring so much to the table, it's almost a shame to look back. For the part three years I've used almost exclusively the enhanced 16F chip line. Here's my current lineup: 12F1840 (8-pin) 16F1825 (14-pin) 16F1847 (18-pin) 16F1938 (28-pin) 16F1939 (40-pin) Each carries a full complement of hardware periperals (USART, I2C/SPI, CCP, enhanced PWM, up to 5 timers, comparitors, DAC, fixed voltage reference, S/R Latch, capacitive sensing, up to 5 I/O ports) along with a boatload of RAM/flash. Each has an internal oscillator that runs up to 32 Mhz that is accurate enough to put out async serial at 115.2kb/s. The enhanced architecture supports 49 instructions, two indirect registers that have the ability to linearly access not only GP RAM but the lower half of the program memory (thus giving direct access to tables). Those FSR registers have pre/post inc/dec and indexed access. Also the program stack is accessible giving rise to true multitasking executives. I just found out last week that on interrupts that a major part of the context of the part is automagically saved and is accessible in the data memory. Each part in the family has the ability to program its own program memory, which means that all can support a bootloader for development. This is all for chips at a price point between $1.20-2.40 USD each directly from Microchip. At this point I just shake my head at the thought of going back to the 16F8= 4, 16F628, or even the 16F88 even for the most simple of projects. I bought a rack of 16F1825's for that purpose. The connundrum of cheap development support is still a work in progress. A PicKit2, the command line pk2cmd program, and the latest device file from Microchip supports the programming of all of these parts. I have developed a reliable 2 pin bootloader that requires nothing more that a USB serial port, a handful of discretes, and python based software that runs on Windows, Linux and Mac boxes. What is missing is a reliable "code dumper" that can be used to dump the bootloader onto a blank chip. I've done some development on it, but it isn't stable enough to release. A complement to that code dumper would be a "cloner" that could take working bootloaded chip and clone it onto a blank chip. This pair of tools would obviate the need to have a PicKit at all. The next level of course is language support. I finally figured out that I wanted to just get stuff done with a minimum of infrastructure. Several years ago I came across FORTH as a development language and realized it was the high level support I had been looking for all along for the threaded interpretive languages I had been developing for years. Its stack based, one word at a time, simple structure facilitates tools simple enough that they can be on chip if necessary. Literally one can hook up a chip to a serial port, open up a terminal program, and develop right on the target just as in the old days of tokenized BASIC. One of my students took on the development of a FORTH kernel for the enhanced 16F parts as a research project and came up with a usable system that is currently without the on-chip translation support. I supplemented his project with a simple assembler that converts FORTH words into the PIC assembler format required to run application programs with his kernel. The result is a development system that makes quick work of most tasks. A quick primer: FORTH utilizes a set of primitive routines and a data stack for computation. A FORTH program consists of a list of 'words' that either represent a literal value that is pushed on the data stack, or the address of a routine to execute. FORTH's power emerges with the developer's ability to create new words from the existing set of words for new computation. These non-primitive words are executed by the internal FORTH interpreter. Because of the stack nature of the FORTH system, operands (which are pushed on the stack) preceed operations. So a typical infix operation such as: v1 =3D v1 + 1 is rewritten into a series of data pushes and primitive operations. Note that the implied "fetch the value" of v1 on the right hand side of the equals and the "store the value" of the equals are explicit operations in forth (represented by the primitives C@ (character fetch) and C! (character store) respectively). So the above expression in FORTH would be: #v1 ; push the address of v1 onto the stack ; Note that without the # in front the interpreter ; would call the word at address v1 instead of pushing ; the value of the address. C@ ; replace the top address on the stack with the value at that addres= s 1 ; push the literal one on the stack + ; add the top two values on the stack replacing them with the result #v1 ; push the address of v1 onto the stack C! ; Store the value in the second slot of the stack into the address o= n the top of stack A new word such as 'inc_v1' that does this operation can be written as such= : :inc_v1 #v1 C@ 1 + #v1 C! EXIT The EXIT is a primitive that serves as a return because calling a word pushes its return address on a return stack. Given the primer, here is a sample Blinky LED Application: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Delays for 1 ms, does not use value on data stack :Delay_1ms #TMR6IF #PIR3 CLRBIT #TMR6IF #PIR3 WAITFOR1 EXIT ;; Delays for n ms, where n is most recent value on the data stack :Delay_ms DUP SKIPNZ DROP EXIT 1- Delay_1ms LOOP ;; Sets up the Delay_ms routine to delay for 1000 ms :Delay_1Sec 1000 `Delay_ms ;; Delays for n seconds, where n is most recent value on the data stack :DelSec DUP SKIPNZ DROP EXIT 1- Delay_1Sec LOOP ; Turn Light off then delay 0.5 seconds :BLINK_IT 4 #LATA SETBIT 5 DelSec 4 #LATA CLRBIT 5 DelSec LOOP ;; Main: This is where your applications goes. Make sure it is an infinite loop! :Main 0 #ANSELA C! 0xC6 #TRISA C! 0x10 #LATA C! `BLINK_IT ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Timer 6 is set to roll over every 1 ms. CLRBIT and WAITFOR1 are primitives that clears a bit and waits for a bit to become 1 respectively. SKIPNZ the the FORTH analog to the PIC skip instruction. It skips the next two words if the value on the top of the data stack, which is removed matches the condition. DUP is a stack primitive that duplicates the top of the data stack. I'll follow up later if anyone is interested. BAJ > > Again, thanks. > > Martin > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist -- Byron A. Jeff Chair: Department of Computer Science and Information Technology College of Information and Mathematical Sciences Clayton State University http://faculty.clayton.edu/bjeff -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .