updated: Tue Jan 17 15:37:27 CET 2006 GETTING STARTED --------------- Haha. What a joke. I've been away for 6 months, and I forgot EVERYTHING! So, how did this work. a tale started on Thu Dec 22 16:43:40 CET 2005. To be fair, I do a fresh darcs pull. there were no changes. Last change was: tagged 0.4 tom@zzz:/tmp$ darcs get ~/darcs/badnop Copying patch 250 of 250... done! Finished getting. tom@zzz:/tmp$ cd badnop/ tom@zzz:/tmp/badnop$ make make -C src make[1]: Entering directory `/tmp/badnop/src' gcc badnop.c -o badnop -g -lreadline -O2 && strip badnop && cp badnop ../bin/ badnop.c: In function 'stream_create': badnop.c:213: warning: incompatible implicit declaration of built-in function 'strlen' badnop.c:215: warning: incompatible implicit declaration of built-in function 'strcpy' make[1]: Leaving directory `/tmp/badnop/src' The warnings are gcc-4. switching to 3.3: tom@zzz:/tmp/badnop$ export GCC=gcc-3.3 tom@zzz:/tmp/badnop$ make make -C src make[1]: Entering directory `/tmp/badnop/src' gcc badnop.c -o badnop -g -lreadline -O2 && strip badnop && cp badnop ../bin/ make[1]: Leaving directory `/tmp/badnop/src' tom@zzz:/tmp/badnop$ ls -al bin/badnop -rwxr-xr-x 1 tom users 22800 Dec 22 16:50 bin/badnop tom@zzz:/tmp/badnop$ bin/badnop Creating new history file .badnop-history ok This gives the barebones forth kernel. not very exciting. I've got my dev board hooked up to the serial port, and executed 'bin/wisp_tty'. This sets the serial port to wisp's wishes. I'm using this one: http://www.voti.nl/wisp628/index_1.html I note I can't execute it in my fresh get, so I'm adding a 'bootstrap' script. In the bin/ directory there are several other scripts. 'bin/bn' seems to be the one to go for, since it loads 'host/forth.f', the forth part of the kernel. tom@zzz:/tmp/badnop$ bin/bn bin/bn: line 4: exec: badnop: not found Need to set paths. I forgot. Before you go tinkering, do '. environ' in the toplevel. tom@zzz:/tmp/badnop$ . environ tom@zzz:/tmp/badnop$ bin/bn ok Alright. We're rolling. load wisp ok This works without complaining, so it's probably right. Now, what's next? I can't seem to see any wisp words though. Let's have a look at the source code. Seems what I just did is wrong: it opens a directory and doesn't complain!! First bug of the day! Moving back to the original ~/darcs/badnop archive, to fix this bug. Seems 'load' calls 'stream_open_file()'. This should check for directory. FIXED. I had a brief stroll through the C code. Input & Error handling is HAIRY :) Back to business. tom@zzz:~/badnop$ bin/bn ok load host/compiler.f ok load wisp/12f675.f ok This seems to work. 'words' gives a nice list of wisp commands. hello Bad file descriptor -:4 input: 'hello' error: can't read ok Not so nice. I remember. You need to give 'ports' on the command line, to facilitate os independence: usually we'll only need one (seral) port to the target. After finding a working serial cable, I got to this: tom@zzz:~/badnop$ bin/bn --port=/dev/ttyS0 ok load host/compiler.f ok load wisp/12f675.f ok hello wisp wisp wispid ok hello wispid Wisp628 1.09 ok So wisp which I use as a (temporary) bootstrap loader seems to work OK. Let's see if we can get the badnop monitor code to work. As I recall, the hard thing here is to keep the host and target in sync. No surprise, I don't remember how this works. The current configuration i have set up on my breadboard is: HOST serial <-> WISP <-> 18F252 <-> 12F629 The 18F is the only one with a serial port. I use it here to control the 12F, which has a tiny synth programmed in it. Some experiment with code packing, writing a forth from scratch tailored to the arch (it's weird though). Been playing around with the timer interrupt to have a 8000kHz square wave synth and interrupt-on-change to enable some PWM power/clock/control circuit. The whole thing runs from 3 wires: ground, output, input power/clock/comm :) Now, I sure hope I got the code backed up. Yes I have apparently. So let's start programming the 18F with the monitor code. Ah. The current state of the pic forth is stored under image/* This contains forth files that can be loaded to set the host side of the dictionary and memory buffer using 'entry', 'org' and ',' words. Very simple. Apparently it's 'stc16/interactive.f' tom@zzz:~/badnop$ bin/bn --port=/dev/ttyS0 ok load stc16/interactive.f ok connect ok target ok { 1 2 + } 0x00007fc0 u ok .ds 3 ok The 'connect' part puts the wisp in passthrough mode. The code between braces is target code. It seems to compile and run OK. The last command '.ds' printed the data stack on the target. Alright, this is enough for now. I'm going for a steak with mushrooms. To check if the monitor is still running, do this ping PING ok USB PICSTAMP The major roadblock at this moment is getting USB to work with Johannes' USBPicStamp circuit. The interesting thing here is I have a Picstamp in my possession which has a version of the monitor in FLASH, but i completely forgot how to connect it. After browsing the code from http://pe.ece.olin.edu/ece/projects.html and having a brief look at http://libusb.sourceforge.net/doc/ USB starts to make sense to me. Time to get a generic driver working. I don't like to mix C18 code with my forth.. First, pinout. This works for 18F252 and 18F2550 (USBPicStamp) I got the wisp hooked up to the serial port, colors are: 19,8 black VSS 20 red VDD +5V 1 yellow program 27 green (RB6) PGC 28 blue (RB7) PGD 17 purple TX (target -> wisp) 18 cyan RX (wisp -> target) Currently wisp's PGC/PGD is disconnected, so I won't accedentally flush it. I got the followin images: tom@zzz:~$ ls badnop/image/ current.f usbstamp.f usbstamp_current.f usbstamp_empty.f tom@zzz:~/badnop$ bn --port=/dev/ttyS0 ok load stc16/usbstamp_interactive.f ok connect ok This loads image/usbstamp_current.f So far so good. The pic is going through it's boot sequence. Though 'ping' does not work. My stamp seems to be out of sync. I got a test program running which starts if I send a command. Let's start over. Looking at host/interactive.f i see the programming words do not write before 0x200 to protect the boot loader. So i replace usbstamp_current.f with usbstamp_empty.f and run again. I manually added the entry: 0x0200 0x0200 entry --user-- to comply with some api change. load stc16/usbstamp_interactive.f ok connect ok ping PING ok target ok { 1 2 3 } 0x00007fc0 u ok .ds 1 2 3 ok { + + } 0x00007fc0 u ok .ds 6 ok Now it seems to work. Let's check the FLASH state, it's probably out of sync. 0 .block D0D5 D00E D01B D047 D0FF FFFF FFFF FFFF D08A D090 D048 D04A D0FF FFFF FFFF FFFF AA9E D7FE A2AB D003 98AB 88AB D7F9 6EEC 50AE A4AB D002 50ED D7F3 0012 A2AC D7FE ok That's the first 64 (0x40) bytes. The first 8 blocks (0x200 bytes) contain the bootloader. So looking at block 8 gives a non-empty (FFFF) block. The device needs to be erased, or we need to move the free pointer. Let's try the latter method first. I find the first free block to be 0x11 (0x440) 0x440 dup entry --user-- 0x440 org ok synced? . -1 ok Now we save the forth. saveforth image/usbstamp_current.f : 2kitt kitt kitt ; ok 2kitt ok This is strange, update did not go automaticly: synced? . 0 ok update 0x00000440 u ok 2kitt ok This works. Yeah, I remember. Need to enable 'incremental' mode, so updates will go automatically. This also updates the forth dump on disk. I just added support for chip erasing for the usb stamp in stc16/usbstamp_interactive.f Basically 'recompile' will not recompile the monitor code, but just reload the 'usbstamp_empty.f' image. To erase the chip and leave only the usbstamp bootloader serial monitor intact do 'erase-application'.