hi all,
just polling for reactions.
i noticed 2 things: * pd and forth mix very well * forth and microcontrollers mix very well
i had this idea of writing a forth for a picmicro, which consists of 2 linked forths, one running on the host, one on the target. which effectively enables you to have a 'shell' on a microcontroller over a serial line, or midi, or another bus.
it's not working yet, mostly because i just was too scared to apply power to that picmicro circuit, but the start of the idea is on my zwizwa site. the design is mostly ready, the implementation sucks and needs to be redone.
this forth (badnop) is actually the one that made me write mole, and mole, which is no more than a geek toy atm, eventually lead to a better pf. it took me a while to get right. once you start writing forths..
now, i was thinking. why not just make mole to be the host forth, choose an architecture, and start develloping some standard microcontroller protocol for pd, so you could eventually just abstract (a program running on) a microcontroller as a pd object.
i'm currently using the picmicro 18f452 as a target chip, which is not extremely fast and cheap and all, but has an instruction set that maps very well to forth, so i can compile directly to binary code. no need for closed source tools etc.. (generated code is peephole-optimized and actually works in the simulator :) i'd like to eventually design it that the target does not matter, but i'd like to get the rest working first.
now, i know this has a lot of 'forth' in it, but would anyone be remotely interested in helping to design/implement it further? it's not too hard to actually do, most of it already works except the hardware part, and might be pretty useful.
the thing for me to find out is how 'standard' i can make the way to plug this into pd. i can go on a solo tour and say 'just use mole', but i'd like to somehow take this to a higher level. maybe writing some basic library to run on a micro.
any idea would be welcome.
cheers tom
On Mon, 23 Aug 2004 19:48:15 +0200 (CEST), Tom Schouten doelie@zzz.kotnet.org wrote:
hi all,
just polling for reactions.
i noticed 2 things:
- pd and forth mix very well
- forth and microcontrollers mix very well
now, i know this has a lot of 'forth' in it, but would anyone be remotely interested in helping to design/implement it further? it's not too hard to actually do, most of it already works except the hardware part, and might be pretty useful.
This sounds almost too tempting to spend time I don't have at the moment on. So yes I am interested, but I have to finish a couple of things in the next month or two first. pd controllable micro controllers... wow And I have always wanted to learn forth as well.
G
hi gerard,
just polling for reactions.
i noticed 2 things:
- pd and forth mix very well
- forth and microcontrollers mix very well
now, i know this has a lot of 'forth' in it, but would anyone be remotely interested in helping to design/implement it further? it's not too hard to actually do, most of it already works except the hardware part, and might be pretty useful.
This sounds almost too tempting to spend time I don't have at the moment on. So yes I am interested, but I have to finish a couple of things in the next month or two first. pd controllable micro controllers... wow And I have always wanted to learn forth as well.
good. allies++ :)
i'm not exactly working on it myself now, so it's definitely something long-term (might even see the arrival of picmicro usb devices with flash).
might even see the arrival of some docs for mole and pf :)
more later
tom
Hi Tom, 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. 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. Jim http://artmeetsengineering.blogspot.com
hi all,
just polling for reactions.
i noticed 2 things:
- pd and forth mix very well
- forth and microcontrollers mix very well
i had this idea of writing a forth for a picmicro, which consists of 2 linked forths, one running on the host, one on the target. which effectively enables you to have a 'shell' on a microcontroller over a serial line, or midi, or another bus.
it's not working yet, mostly because i just was too scared to apply power to that picmicro circuit, but the start of the idea is on my zwizwa site. the design is mostly ready, the implementation sucks and needs to be redone.
this forth (badnop) is actually the one that made me write mole, and mole, which is no more than a geek toy atm, eventually lead to a better pf. it took me a while to get right. once you start writing forths..
now, i was thinking. why not just make mole to be the host forth, choose an architecture, and start develloping some standard microcontroller protocol for pd, so you could eventually just abstract (a program running on) a microcontroller as a pd object.
i'm currently using the picmicro 18f452 as a target chip, which is not extremely fast and cheap and all, but has an instruction set that maps very well to forth, so i can compile directly to binary code. no need for closed source tools etc.. (generated code is peephole-optimized and actually works in the simulator :) i'd like to eventually design it that the target does not matter, but i'd like to get the rest working first.
now, i know this has a lot of 'forth' in it, but would anyone be remotely interested in helping to design/implement it further? it's not too hard to actually do, most of it already works except the hardware part, and might be pretty useful.
the thing for me to find out is how 'standard' i can make the way to plug this into pd. i can go on a solo tour and say 'just use mole', but i'd like to somehow take this to a higher level. maybe writing some basic library to run on a micro.
any idea would be welcome.
cheers tom
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
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.
Sounds great Tom. I'd be glad to help out with the hardware, or some PIC assembly code when it comes time. I could also design a printed circuit board if it helps. Nice Project :) jim http://artmeetsengineering.blogspot.com
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.
Sounds great Tom. I'd be glad to help out with the hardware, or some PIC assembly code when it comes time.
you by chance don't have some midi handling uart code for the 18f452 lying around? just midi in and out. something like that could serve as the guts for a very tiny interpreter to get it bootstrapped.
I could also design a printed circuit board if it helps.
alright. a standard board included in the package :)
hello,
Tom Schouten wrote:
Sounds great Tom. I'd be glad to help out with the hardware, or some PIC assembly code when it comes time.
you by chance don't have some midi handling uart code for the 18f452
lying
around? just midi in and out. something like that could serve as the guts for a very tiny interpreter to get it bootstrapped.
this is a cut and past from code made for 16F87x i think this should be compatible for 18Fxxx... (???)
on this exemple receving is not made by interuption, so you have to pool the rcv subroutine. i hope you'll understand my french comment.
this is just sending and receving midi bytes and not messages.
fell free to ask me question about pic (never used 18F, but I used 16F a lot)
I also can help for the hardware part, pcb and maybe some asm.
Cyrille
initialisation ;--------------- ; configuration du port TX / RX BSF STATUS, RP0 ; select bank1 bsf TRISC, 7 bsf TRISC, 6 ; pour permettre l'utilisation de ces pattes par l'USART
movlw .39 movwf SPBRG ; initialisation de la frequence
movlw b'00100100' movwf TXSTA ; initialisation du port TX
BCF STATUS, RP0 ; select bankO
movlw b'10010000' movwf RCSTA ; mise en route du port serie
movf RCREG, W movf RCREG, W ; purge du buffer de reception serie
;------------------------------------------------------------
snd
; envoie le mot 8 bits de W en midi ; utilise le port TX du Pross
rgstr_plein btfss PIR1, TXIF goto rgstr_plein ; le registre d'envoie est plein, il faut attendre movwf TXREG ; on charge la valeur a envoyer ds le bon registre
return ; c'est deja fini !
;------------------------------------------------------------ rcv btfsc PIR1, RCIF ; test de presence de message ds le buffer de reception goto rcv2 ; appelle du traitement de reception d'un message movlw .0 ; w=0 qd le buffer de reception est vide return
rcv2 movf RCREG, W ; on met dans W le message reçu movwf midi_oct ; on le sauve pour le traitrer movlw .1 ; w=1 ->buffer plein return
I could also design a printed circuit board if it helps.
alright. a standard board included in the package :)
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
this is a cut and past from code made for 16F87x i think this should be compatible for 18Fxxx... (???)
on this exemple receving is not made by interuption, so you have to pool the rcv subroutine.
and interrupts shouldn't be too hard to add. currently, there's not much to interrupt so this should do just fine.
thanks!
fell free to ask me question about pic (never used 18F, but I used 16F a lot)
I also can help for the hardware part, pcb and maybe some asm.
cool. quite a team already :)
this sounds amazing. im not sure what help i can be, but sometime inthe nexrt few months (after these two projects im stuck in now end) if i find some free time i'd love to help see this to reality as i have like 9000 projects planned with pic's and pd. wonderful idea tom!
Tom Schouten wrote:
hi all,
just polling for reactions.
i noticed 2 things:
- pd and forth mix very well
- forth and microcontrollers mix very well
i had this idea of writing a forth for a picmicro, which consists of 2 linked forths, one running on the host, one on the target. which effectively enables you to have a 'shell' on a microcontroller over a serial line, or midi, or another bus.
it's not working yet, mostly because i just was too scared to apply power to that picmicro circuit, but the start of the idea is on my zwizwa site. the design is mostly ready, the implementation sucks and needs to be redone.
this forth (badnop) is actually the one that made me write mole, and mole, which is no more than a geek toy atm, eventually lead to a better pf. it took me a while to get right. once you start writing forths..
now, i was thinking. why not just make mole to be the host forth, choose an architecture, and start develloping some standard microcontroller protocol for pd, so you could eventually just abstract (a program running on) a microcontroller as a pd object.
i'm currently using the picmicro 18f452 as a target chip, which is not extremely fast and cheap and all, but has an instruction set that maps very well to forth, so i can compile directly to binary code. no need for closed source tools etc.. (generated code is peephole-optimized and actually works in the simulator :) i'd like to eventually design it that the target does not matter, but i'd like to get the rest working first.
now, i know this has a lot of 'forth' in it, but would anyone be remotely interested in helping to design/implement it further? it's not too hard to actually do, most of it already works except the hardware part, and might be pretty useful.
the thing for me to find out is how 'standard' i can make the way to plug this into pd. i can go on a solo tour and say 'just use mole', but i'd like to somehow take this to a higher level. maybe writing some basic library to run on a micro.
any idea would be welcome.
cheers tom
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
-
cyrille henry -
gerard van dongen -
jim ruxton -
Josh Steiner -
Tom Schouten