Since the receive and transmit routines rely on ...
Of course you could use SERIN but unfortunately it blocks while waiting for a character. I have been meaning to add some enhancements to Tachyon and more flexible serial I/O might be one of them.
I use a separate task (cog) as serin
#9600 SERBAUD
#P3 == TX --- my pin, device RX
#P4 == RX --- my pin, device TX
{ serial task rx stuff }
WORD rxrd,rxwr \ create receive buffer variables
#128 == rxsize
rxsize BYTES buf232
$10 LONGS stack232
\ Buffer data from the RS232 port - nothing else
pub RS232.TASK
stack232 SP! !SP \ init data stack to 0, assign stack to this task
#9600 SERBAUD \ how fast are we going
rxrd W~ rxwr W~ buf232 rxsize ERASE \ clear rxrd, rxwr and erase buf232
BEGIN
RX SERIN rxwr W@ \ get serial byte
rxsize 1- AND buf232 + C! \ compute addr and write data to buffer
rxwr W++ \ increment buffer pointer
AGAIN
;
\ and read the buffer in keypoll
\ You can read the buffered data with this
pub GET232 ( -- ch|0 )
rxrd W@ rxsize 1- AND rxwr W@ rxsize 1- AND <> \ buffer is empty
IF
rxrd W@ rxsize 1- AND buf232 + C@
rxrd W++
ELSE 0
THEN
;
I have the GET232 working correctly, I can read in the characters sent via the Bluetooth.
Is there a way to pass the received characters to Forth as if it was entered via the console?
Sure, just create a new word called BT for instance that changes the "ukey" variable to point to your GET232.
pub BT ' GET232 ukey W! ;
Place BT in your startup code so that all console I/O will be directed to it.
I guess you are redirecting the console EMIT instruction by changing the mask, so the BT word will look like this:
pub BT ' GET232 ukey W! TX MASK 6 COGREG ! ;
It's best to avoid calling pins TX and RX which also sound like actual transmit and receive functions, as a suggestion give them more specific names such as txd.bt for instance. You can also use CONBAUD to set the console transmit baud-rate.
Normally I just connect Bluetooth directly to the existing console serial pins as I use a PropPlug compatible 4+4 header and my Bluetooth modules just plug in directly to this which includes power.
Hopefully I will be able to update Tachyon very soon to include more flexible serial I/O.
I have the GET232 working correctly, I can read in the characters sent via the Bluetooth.
Is there a way to pass the received characters to Forth as if it was entered via the console?
Sure, just create a new word called BT for instance that changes the "ukey" variable to point to your GET232.
pub BT ' GET232 ukey W! ;
Place BT in your startup code so that all console I/O will be directed to it.
I guess you are redirecting the console EMIT instruction by changing the mask, so the BT word will look like this:
pub BT ' GET232 ukey W! TX MASK 6 COGREG ! ;
It's best to avoid calling pins TX and RX which also sound like actual transmit and receive functions, as a suggestion give them more specific names such as txd.bt for instance. You can also use CONBAUD to set the console transmit baud-rate.
Normally I just connect Bluetooth directly to the existing console serial pins as I use a PropPlug compatible 4+4 header and my Bluetooth modules just plug in directly to this which includes power.
Hopefully I will be able to update Tachyon very soon to include more flexible serial I/O.
Yes here's hoping for more flexible serial IO and those BT modules sound fun, got any links?
Yes here's hoping for more flexible serial IO and those BT modules sound fun, got any links?
These are just the HC05/06 modules mounted onto an adaptor pcb with the possibility of remotely reprogramming the Prop via I2C with the embedded micro although I never did bother to get that to work. Have a look back at this old post but bear in mind that the forum migration(s) has done funny things to attachments, they are so full sized!
reprogramming the Prop via I2C with the embedded micro
WOOOOW. What a cool idea! Sending a uart stream over bluetooth to be protocol converted by a tiny micro is such a cool idea.
I've been doing similar things with other micros and over RS485 networks before usually with an 8-pin PIC but I just thought it was a logical thing to do and since I have direct access to I2C it just makes sense to bypass any bootloader protocol and load up the EEPROM directly. The boot micro is just a tiny MSP430 which I have had a lot of experience with when they first came out so it shouldn't be too hard to write a simple bit-bashed serial and I2C for it.
Expect some more enhancements as I have a big project using 80 props per unit. So there is some neat rs485 network stuff as well.
Peter- You the man! I have been reading Forth books, thanks to you. Look forward to any improvments you make to your labor of love! ( I am not, however, saying I will completely understand it lol)
Peter,
I presume you have a simple editor for you prop hosted tachyon?
Do you have it working hosted on SD card yet?
I could but haven't although I would think it wouldn't be much. I have my old iConsole that has VGA, ps2, dual SD etc that I could press into service. I will give it a go later on. Do you have boards that would make good candidates?
After looking at a very wide variety of ARM tools and even just plain old assemblers I've come to the conclusion if I want to keep it simple I have to do it myself. Since these ARM CM0 processors I am using will be sitting under the control of a Prop I figure that I would just write my own flat assembler that will generate the binary/hex and load it directly onto the ARM chip. I've got a whole choice of chips but one little one that seems to tick a few boxes is the XMC1100 which I can load via a serial bootloader. At the the moment I have little TSSOP16 chips but I may also get some TSSOP38 parts as well and initially I will just use them as smart 12-bit A/D converters and gradually offload more functionality into them.
Since the assembler is written in Tachyon Forth it will be very easy to create powerful macros too.
So programming them would be as simple as sending or loading the Prop with an assembly language file and if I want a listing well that will just be written to a file or echoed to the screen. No relocatable code or linking required etc. Should be interesting. I do have Mecrisp Forth running on these but it seems slow and it is just a Forth, there are no extensions and drivers etc so I plan to get a Tachyon dialect flying on it. There is also the MK02FN64VLF10 chip which is a 100MHz CM4 and stacks of memory and features in a LQFP48 for around $1.70 which I may also use. These chips will also make great math copros which I will probably interface via SPI.
This setup will make it very easy to use an ARM chip at the bare metal level and have it assembled, loaded, and running in one keystroke.
So you can flash the xmc from a P1? That is interesting, as we use an XMC1100T038X0064 in our latest design to emulate the flash. But the chip has to be flashed initially, but we want to use a debugger to do this. Which connections have to be established? Our project decription will follow soon.
Peter,
I presume you have a simple editor for you prop hosted tachyon?
Do you have it working hosted on SD card yet?
I could but haven't although I would think it wouldn't be much. I have my old iConsole that has VGA, ps2, dual SD etc that I could press into service. I will give it a go later on. Do you have boards that would make good candidates?
Yes Peter. Almost about to send the pcb away. 2"x2" with P8XBlade2 at the center, has VGA, TV, 2xAudio, 2xPS2 (Kbd & Mouse), 2x sigma-delta inputs, microSD of course, and a configurable microUSB connection, plus an uncommitted 2x20 header labelled for Raspberry Pi. All these peripherals are linkable by shunts.
Yes Peter. Almost about to send the pcb away. 2"x2" with P8XBlade2 at the center, has VGA, TV, 2xAudio, 2xPS2 (Kbd & Mouse), 2x sigma-delta inputs, microSD of course, and a configurable microUSB connection, plus an uncommitted 2x20 header labelled for Raspberry Pi. All these peripherals are linkable by shunts.
Wot!? no Ethernet?
BTW, I find those PS/2 connectors cumbersome and even more so when you know you are only going to plug old old keyboards and mice into them. Did you see my bit about using nRF24L01s to interface to Logitech wireless keyboard/mice? No connector necessary although if I did have a connector it would still be USB style.
Connector is microUSB. Use a cheap ebay short microUSB to female usb cable. PCB edge space is short so the second is 4pin header.
Easy to plug an ethernet board on top.
Connector is microUSB. Use a cheap ebay short microUSB to female usb cable. PCB edge space is short so the second is 4pin header.
Easy to plug an ethernet board on top.
Have you got the pinout for my IoT5500 module? It's setup so that you only need one side of the dual 10-pin connector. Just use 4 I/O although the SPI clk/do/di can be in common with some other device. If you do I will send you a sample.
Peter, I looked at your thread but couldn't see the pinout.
Do you require 3V3 or 5V and where are they on the pinout?
Because I wanted to maintain the pinout with my P8XBade2, there are a few restrictions in what I have done in the two larger boards. I don't have 3v3/5v/Gnd where normally would have placed them.
I would love to get Tachyon working with PropOS. They should both be able to co-exist, just like ZiCog and CPM an SRAM is present. There is so much space on a microSD card that it would be nice to be able to have one set of images able to run most os/languages as self-hosting, providing the appropriate I/O devices are available.
Should have done this many years ago!
BTW, I don't use a pullup on the SD CS as this is the means for detecting a card which has it's own pullup on that pin and I have never had any kind of problems at all with not having any pullups on SD cards.
I know you have mentioned this before Peter and I have considered not fitting the pullup. On this card I made it a separate resistor whereas on previous boards I used a resistor network.
By testing the various pullups on my pcbs I am able to tell which board it is.
If I don't fit the resistor and no sd is fitted,I cannot tell that this is my board. Then again, if I cannot detect the pullup/sdcard, then the point of being able to detect it to run code from the card is moot. It also bodes well for not using the onboard sd card when the pins are used for something else.
On some of my cards, the pullup is required on the prop pin because I share the /CS pin (via a gate with inverter) with /CE for the SRAM. When low, the SRAM is selected. When high it enables the gate to pass another pin to the sd /CS pin. Since a gate is used, no pullup was required on this anyway, but I cannot read the pin to detect if a card is inserted (no spare pins in the first place).
So you can flash the xmc from a P1? That is interesting, as we use an XMC1100T038X0064 in our latest design to emulate the flash. But the chip has to be flashed initially, but we want to use a debugger to do this. Which connections have to be established? Our project decription will follow soon.
How have you progressed with this chip? Haven't you used the bootloader yet?
I've got the 16-pin TSSOP version with receive on P0.14 and transmit on P0.15. I control the supply to the chip as this is a sure way to reset it and then I send a $00 byte followed by $93 for full-duplex mode after which it responds with the BSL ID of $5D. I also put a pullup on P0.15 so the Prop doesn't get confused as to when the XMC is transmitting.
The bootloader has quite a few modes including booting from SPI Flash.
Hi Peter, I posted a first information about the board PRIME we currently create. We first used a Infineon XMC2Go where flashing is done by a second chip. But it turned out, the demos are all single task, no interrupt, the usic quite powerful (complicated) .. so one of the main tasks was to create a uniform c header file. This will be published in a next step to ease the first steps for others, which will follow this path.
After looking at a very wide variety of ARM tools and even just plain old assemblers I've come to the conclusion if I want to keep it simple I have to do it myself. Since these ARM CM0 processors I am using will be sitting under the control of a Prop I figure that I would just write my own flat assembler that will generate the binary/hex and load it directly onto the ARM chip.
.
.
.
Here comes that standalone system.
Looking forward to this "integration" and a few sample dev boards?
A few years ago I was playing with TFT displays, specifically a 3.5" one based on the SSD2119 which has it's own internal display RAM and can be accessed via 3-wire. I had designed a driver PCB for it but as far as I can tell I never got around to getting this board to run as it had an on-board micro to allow full control over I2C. However when I checked it the other day and bypassed the micro I couldn't get the display to respond and eventually found that 4 mode pins weren't connected to anything on the pcb, so obviously I have never lit this board up before
Anyway, as I said I bypassed the onboard micro but still used my I2C lines from the Prop both for the touch screen chip and also as the clock and data for the TFT's 3-wire SPI mode. All I needed extra was the chip select and it seems that that is hardly needed either as I can leave CS low an it just works. Anyway, since I am using the I2C pins I also use CS and so it turns out that 3 wires is all I need for the TFT+touch screen and 2 of those are free since they are the I2C lines.
My software includes 5x7 mode to give 53 characters by up to 30 lines or the Propeller font which at 1:1 scale gives us 20 characters by 7 lines. I can also scale the X and Y of the Prop font so a single character could fill the screen, which might be good for a final countdown! Like most of my Tachyon I/O devices I have set this up as a streaming device so that output can be redirected to it easily, in fact if I type TFT then Tachyon's output will appear there instead of the default console. The original code used special code modules which I have removed and simply use the SPIWR instructions.
There are a couple of keypad builder words in there, here's a code example of setting up the calculator display shown.
" 789<>456*/123+-0.C=?" 0 STRING KEYCAPS
pub DRAW.CALC
0 $40 TFTXY!
BIG 1 1 XY* --- Easy way to reset the default spacings for font
BLUE SHADE SHADE PAPER RED PEN
KEYCAPS WHITE 5 4 #62 #44 DRAW.KEYPAD
GRAY SHADE PEN 8 8 #304 #56 DRAW.BUTTON --- Draw an "TFT gray" box for the display
GRAY SHADE PAPER YELLOW PEN
TFT #120 4 TFTXY! --- Position our cursor in the virtual TFT screen
BIG 1 2 XY* --- Use the big Prop font scaled 2Y
PRINT" 1.414213562" CON
;
The full code is available in the Tachyon Dropbox folder under extras. The code size including the keypad demo is 1.3k
BTW, I don't use a pullup on the SD CS as this is the means for detecting a card which has it's own pullup on that pin and I have never had any kind of problems at all with not having any pullups on SD cards.
Do you recommend putting a high-Z pull-down on that pin to aid in card detection? Does this strategy work with standard and micro SD cards? Thanks.
Do you recommend putting a high-Z pull-down on that pin to aid in card detection? Does this strategy work with standard and micro SD cards? Thanks.
Well the software pulses it low then floats the line and if it is high then it is pulled-up which means a card is inserted. You will find that the pin and connection capacitance is high enough over that short period to stay low if no card is inserted to pull it high. All I can say is that I have never had a problem in all the many designs I have done which include both SD and microSD. In fact I have found that I don't any pull-ups at all on any of the lines. The only thing I am inclined to do on newer designs is also what I have done on some older designs and that is to include a small SOT-23 LDO as a power-switch so cards can be forced out of some errant multi-block modes etc, a guaranteed way of making them initialize properly.
Peter,
Over on the PropBasic thread you mentioned perhaps putting Basic language support over the top of Forth in Tachyon. IMHO this would be a big boost for those of us who would prefer Basic over Forth. Perhaps Spin support might be interesting too???
Comments
I use a separate task (cog) as serin
#9600 SERBAUD #P3 == TX --- my pin, device RX #P4 == RX --- my pin, device TX { serial task rx stuff } WORD rxrd,rxwr \ create receive buffer variables #128 == rxsize rxsize BYTES buf232 $10 LONGS stack232 \ Buffer data from the RS232 port - nothing else pub RS232.TASK stack232 SP! !SP \ init data stack to 0, assign stack to this task #9600 SERBAUD \ how fast are we going rxrd W~ rxwr W~ buf232 rxsize ERASE \ clear rxrd, rxwr and erase buf232 BEGIN RX SERIN rxwr W@ \ get serial byte rxsize 1- AND buf232 + C! \ compute addr and write data to buffer rxwr W++ \ increment buffer pointer AGAIN ; \ and read the buffer in keypoll \ You can read the buffered data with this pub GET232 ( -- ch|0 ) rxrd W@ rxsize 1- AND rxwr W@ rxsize 1- AND <> \ buffer is empty IF rxrd W@ rxsize 1- AND buf232 + C@ rxrd W++ ELSE 0 THEN ;hat tip to peter and please more I/O enhancementsIs there a way to pass the received characters to Forth as if it was entered via the console?
Sure, just create a new word called BT for instance that changes the "ukey" variable to point to your GET232. Place BT in your startup code so that all console I/O will be directed to it.
I guess you are redirecting the console EMIT instruction by changing the mask, so the BT word will look like this: It's best to avoid calling pins TX and RX which also sound like actual transmit and receive functions, as a suggestion give them more specific names such as txd.bt for instance. You can also use CONBAUD to set the console transmit baud-rate.
Normally I just connect Bluetooth directly to the existing console serial pins as I use a PropPlug compatible 4+4 header and my Bluetooth modules just plug in directly to this which includes power.
Hopefully I will be able to update Tachyon very soon to include more flexible serial I/O.
In the not too distant future you will say "I think I have 10 spare cogs still".
Tachyon with 16 cogs will be too much fun.
Yes here's hoping for more flexible serial IO and those BT modules sound fun, got any links?
These are just the HC05/06 modules mounted onto an adaptor pcb with the possibility of remotely reprogramming the Prop via I2C with the embedded micro although I never did bother to get that to work. Have a look back at this old post but bear in mind that the forum migration(s) has done funny things to attachments, they are so full sized!
WOOOOW. What a cool idea! Sending a uart stream over bluetooth to be protocol converted by a tiny micro is such a cool idea.
I've been doing similar things with other micros and over RS485 networks before usually with an 8-pin PIC but I just thought it was a logical thing to do and since I have direct access to I2C it just makes sense to bypass any bootloader protocol and load up the EEPROM directly. The boot micro is just a tiny MSP430 which I have had a lot of experience with when they first came out so it shouldn't be too hard to write a simple bit-bashed serial and I2C for it.
I presume you have a simple editor for you prop hosted tachyon?
Do you have it working hosted on SD card yet?
Peter- You the man! I have been reading Forth books, thanks to you. Look forward to any improvments you make to your labor of love! ( I am not, however, saying I will completely understand it lol)
I could but haven't although I would think it wouldn't be much. I have my old iConsole that has VGA, ps2, dual SD etc that I could press into service. I will give it a go later on. Do you have boards that would make good candidates?
After looking at a very wide variety of ARM tools and even just plain old assemblers I've come to the conclusion if I want to keep it simple I have to do it myself. Since these ARM CM0 processors I am using will be sitting under the control of a Prop I figure that I would just write my own flat assembler that will generate the binary/hex and load it directly onto the ARM chip. I've got a whole choice of chips but one little one that seems to tick a few boxes is the XMC1100 which I can load via a serial bootloader. At the the moment I have little TSSOP16 chips but I may also get some TSSOP38 parts as well and initially I will just use them as smart 12-bit A/D converters and gradually offload more functionality into them.
Since the assembler is written in Tachyon Forth it will be very easy to create powerful macros too.
So programming them would be as simple as sending or loading the Prop with an assembly language file and if I want a listing well that will just be written to a file or echoed to the screen. No relocatable code or linking required etc. Should be interesting. I do have Mecrisp Forth running on these but it seems slow and it is just a Forth, there are no extensions and drivers etc so I plan to get a Tachyon dialect flying on it. There is also the MK02FN64VLF10 chip which is a 100MHz CM4 and stacks of memory and features in a LQFP48 for around $1.70 which I may also use. These chips will also make great math copros which I will probably interface via SPI.
This setup will make it very easy to use an ARM chip at the bare metal level and have it assembled, loaded, and running in one keystroke.
Here comes that standalone system.
Wot!? no Ethernet?
BTW, I find those PS/2 connectors cumbersome and even more so when you know you are only going to plug old old keyboards and mice into them. Did you see my bit about using nRF24L01s to interface to Logitech wireless keyboard/mice? No connector necessary although if I did have a connector it would still be USB style.
Easy to plug an ethernet board on top.
Have you got the pinout for my IoT5500 module? It's setup so that you only need one side of the dual 10-pin connector. Just use 4 I/O although the SPI clk/do/di can be in common with some other device. If you do I will send you a sample.
Do you require 3V3 or 5V and where are they on the pinout?
Because I wanted to maintain the pinout with my P8XBade2, there are a few restrictions in what I have done in the two larger boards. I don't have 3v3/5v/Gnd where normally would have placed them.
I would love to get Tachyon working with PropOS. They should both be able to co-exist, just like ZiCog and CPM an SRAM is present. There is so much space on a microSD card that it would be nice to be able to have one set of images able to run most os/languages as self-hosting, providing the appropriate I/O devices are available.
Should have done this many years ago!
BTW, I don't use a pullup on the SD CS as this is the means for detecting a card which has it's own pullup on that pin and I have never had any kind of problems at all with not having any pullups on SD cards.
By testing the various pullups on my pcbs I am able to tell which board it is.
If I don't fit the resistor and no sd is fitted,I cannot tell that this is my board. Then again, if I cannot detect the pullup/sdcard, then the point of being able to detect it to run code from the card is moot. It also bodes well for not using the onboard sd card when the pins are used for something else.
On some of my cards, the pullup is required on the prop pin because I share the /CS pin (via a gate with inverter) with /CE for the SRAM. When low, the SRAM is selected. When high it enables the gate to pass another pin to the sd /CS pin. Since a gate is used, no pullup was required on this anyway, but I cannot read the pin to detect if a card is inserted (no spare pins in the first place).
How have you progressed with this chip? Haven't you used the bootloader yet?
I've got the 16-pin TSSOP version with receive on P0.14 and transmit on P0.15. I control the supply to the chip as this is a sure way to reset it and then I send a $00 byte followed by $93 for full-duplex mode after which it responds with the BSL ID of $5D. I also put a pullup on P0.15 so the Prop doesn't get confused as to when the XMC is transmitting.
The bootloader has quite a few modes including booting from SPI Flash.
Looking forward to this "integration" and a few sample dev boards?
Anyway, as I said I bypassed the onboard micro but still used my I2C lines from the Prop both for the touch screen chip and also as the clock and data for the TFT's 3-wire SPI mode. All I needed extra was the chip select and it seems that that is hardly needed either as I can leave CS low an it just works. Anyway, since I am using the I2C pins I also use CS and so it turns out that 3 wires is all I need for the TFT+touch screen and 2 of those are free since they are the I2C lines.
My software includes 5x7 mode to give 53 characters by up to 30 lines or the Propeller font which at 1:1 scale gives us 20 characters by 7 lines. I can also scale the X and Y of the Prop font so a single character could fill the screen, which might be good for a final countdown! Like most of my Tachyon I/O devices I have set this up as a streaming device so that output can be redirected to it easily, in fact if I type TFT then Tachyon's output will appear there instead of the default console. The original code used special code modules which I have removed and simply use the SPIWR instructions.
There are a couple of keypad builder words in there, here's a code example of setting up the calculator display shown.
" 789<>456*/123+-0.C=?" 0 STRING KEYCAPS pub DRAW.CALC 0 $40 TFTXY! BIG 1 1 XY* --- Easy way to reset the default spacings for font BLUE SHADE SHADE PAPER RED PEN KEYCAPS WHITE 5 4 #62 #44 DRAW.KEYPAD GRAY SHADE PEN 8 8 #304 #56 DRAW.BUTTON --- Draw an "TFT gray" box for the display GRAY SHADE PAPER YELLOW PEN TFT #120 4 TFTXY! --- Position our cursor in the virtual TFT screen BIG 1 2 XY* --- Use the big Prop font scaled 2Y PRINT" 1.414213562" CON ;The full code is available in the Tachyon Dropbox folder under extras. The code size including the keypad demo is 1.3kDo you recommend putting a high-Z pull-down on that pin to aid in card detection? Does this strategy work with standard and micro SD cards? Thanks.
Well the software pulses it low then floats the line and if it is high then it is pulled-up which means a card is inserted. You will find that the pin and connection capacitance is high enough over that short period to stay low if no card is inserted to pull it high. All I can say is that I have never had a problem in all the many designs I have done which include both SD and microSD. In fact I have found that I don't any pull-ups at all on any of the lines. The only thing I am inclined to do on newer designs is also what I have done on some older designs and that is to include a small SOT-23 LDO as a power-switch so cards can be forced out of some errant multi-block modes etc, a guaranteed way of making them initialize properly.
' 1- ( n1 -- n1-1 ) DEC test $,#1 wc ' 1+ ( n1 -- n1+1 ) INC sumc tos,#1 ' inc or dec depending upon carry (default cleared by doNEXT) jmp unext$ is the "here symbol".So DEC works only if it is on an odd address, or not ???
Over on the PropBasic thread you mentioned perhaps putting Basic language support over the top of Forth in Tachyon. IMHO this would be a big boost for those of us who would prefer Basic over Forth. Perhaps Spin support might be interesting too???