hi jim,
As one who really likes PICs and PD this sounds like an interesting project to me. Not sure how I could help out as it's been a while since I've used Forth.
sounds like a perfectly good resume to me :)
Just so I understand what you are trying to do are you envisioning for example separate pd PIC objects that would configure the A/D read it , configure PWM etc. I guess I've been doing this with MIDI but having direct objects would be nice.
yes. lots of things are possible once actialy have the chain from pd message -> PIC & back, and it's completely programmable and interactive. no files, no external compilers, all in one. that's the main goal.
i want an interactive forth interpreter running which can handle some basic requests, modify registers and install handlers in the PIC (i.e. swapping in a block of flash memory containing freshly compiled code).
this can then be used to build a more highlevel kernel that can implement some more io functions, and some pd specific things. find some patterns of things that might be useful.
ideally, i'd like to have a mini-pd or at least the guts of what's necessary to simulate pd object behaviour, running on the PIC. creating an object would then be the equivalent of starting some task on the PIC, so pd object io can be directly mapped to pic pin io.
but that's just one use. the important part is that there is a this realtime interactive link between pf->mole->PIC and back. applications could be split into two parts. a loader, which loads a certain env into the PIC, and pd objects that map to whatever the loader has loaded into the PIC, i.e. a bitbanged midi router.
so the basic thing that has to be made in order to get this all working, is a small interpreter/loader for the PIC and a test circuit. the communication could be plain serial for starters, or midi which is a tad bit more difficult to write a valid protocol for i guess but much more flexible. (i.e. you could use pd + mole to program a standalone midi application in the PIC).
this loader could be done in assembler or forth. basicly nothing more than receive, interpret, execute. it would send forth commands (maybe encoded directly as addresses with the symbol table is in the host to simplify the target interpreter.) so interpret is nothing more than decode and execute.
and that's where my knowledge stops. i read the manual to get to know the architecture so i could write the forth compiler, but i don't have any experience with actually doing something useful with a microcontroller. the experiment stopped at the simulator last time.