Last night I posted an update to my LCD driver that breaks the code into an object and demo files. I added rotation 0/90/180/270 degrees as well as the offsety=32 for the red pcbs. The PASM driver runs in its own cog which.includes the 8*8 128 char font.
Can you post your 5*7 (6*8) font please as it will save me making one
I will redo the font to make it the same one I use for the 5110 LCD as this only uses 5 bytes per character rather the than the 7 bytes using 5-bits per line. The flexible writing order configuration allows me to optimize drawing the font. Tachyon doesn't need another cog but just uses its built-in SPI instruction to write bytes or words at 4MHz speeds. I used the rotation command as well so I could view this using the right angle connector I installed to the top instead
btw, I noticed on Aliexpress that if I order a quantity of 10 it adds $2.11 postage so it costs more to buy 10 in one hit than it does to place 10 individual orders!
Last night I posted an update to my LCD driver that breaks the code into an object and demo files. I added rotation 0/90/180/270 degrees as well as the offsety=32 for the red pcbs. The PASM driver runs in its own cog which.includes the 8*8 128 char font.
Can you post your 5*7 (6*8) font please as it will save me making one
I will redo the font to make it the same one I use for the 5110 LCD as this only uses 5 bytes per character rather the than the 7 bytes using 5-bits per line. The flexible writing order configuration allows me to optimize drawing the font. Tachyon doesn't need another cog but just uses its built-in SPI instruction to write bytes or words at 4MHz speeds. I used the rotation command as well so I could view this using the right angle connector I installed to the top instead
If you have it as 48 bits (6*7 or 6*8) that would be fine. All my searching only came up with versions stored in column bytes, and the display really wants row bits. I had better things to do than to write a conversion program
btw, I noticed on Aliexpress that if I order a quantity of 10 it adds $2.11 postage so it costs more to buy 10 in one hit than it does to place 10 individual orders!
I have often found that companies on AliExpress that sell in quantities are more expensive than buying a quantity at the single price from another company. I have seen a few cents discount for buying more than 1, but I haven'tseen the price/postage go up that way.
The 128x128 LCD now uses the more compact 5x7 font arranged as 5 bytes/character. I've done a little watch app for this display as I'd like to package it into a band with the Prop (maybe Cluso99's P8XBlade2 + LiPo) on the other end of the band in a tiny slim-line case such as an SD card holder with the battery.
edit: looks like I can squeeze in a P8, Bluetooth, RTC, IMU and maybe some other stuff along with a small camera battery.
pub PROPWATCH
LCD 1 EMIT
--- print day
yellow fg 3 3 *XY 2 SPACES .DAY
--- print month date
0 24 @XY
cyan fg DATE@ 100 / 100 MOD 1- 3 * " JanFebMarAprMayJunJulAugSepOctNovDec" + 3 CTYPE SPACE
DATE@ 100 MOD DUP PRINT
1 2 *XY 10 MOD 2* " thstndrdthththththth" + 2 CTYPE
--- print hours and minutes
0 50 @XY
white fg 4 5 *XY TIME@ 100 / DUP 1200 > IF 1200 - THEN 100 U/MOD 2 U.N 2 5 *XY ':' EMIT 4 5 *XY 2 U.N
--- print am/pm
108 50 @XY blue fg 1 2 *XY TIME@ 120000 < IF PRINT" AM" ELSE PRINT" PM" THEN
--- print seconds
108 70 @XY
green fg TIME@ 100 MOD DUP 2 U.N
--- set bar position and height
6 H 96 Y
--- draw active seconds bar
2* ?DUP IF DUP W 0 X green fillWindow THEN
--- fill in remainder of bar as inactive
128 OVER - W X red fillWindow
--- messages
0 98 @XY
1 1 *XY CR PRINT" Prop Watch V1.0 - PBJ "
CON
;
I set the time via a terminal, and in the case of the final unit, via Bluetooth. But there is no reason why I couldn't adjust it from the 5-way tactile switch (left,right,up,down,press). Actually I read the real RTC into the soft RTC and that's what the software transparently accesses just to cut down on the slower I2C access.
I have often found that companies on AliExpress that sell in quantities are more expensive than buying a quantity at the single price from another company. I have seen a few cents discount for buying more than 1, but I haven'tseen the price/postage go up that way.
I looks like if the package is small/light enough to go with china standard mail, many send as free shipping .
And if you order a greater number suddenly delivery costs go up significantly. So I regularly place multiple orders for multiple parts.
It is really unbelievable how compact and dense Forth incorporated in Tachyon is. How is it possible that this ukey uemit doing isn't more famous. keyboard, vga, serial interface, ethernet even the EVAL$ is implemented this way. This is really a great tool. The only disadvantage is that one needs 30 years of experience to recognize it and of course some years to learn it. I'm asking myself wether it is possible to teach children Forth. I will experiment in this direction :-)
It is really unbelievable how compact and dense Forth incorporated in Tachyon is. How is it possible that this ukey uemit doing isn't more famous. keyboard, vga, serial interface, ethernet even the EVAL$ is implemented this way. This is really a great tool. The only disadvantage is that one needs 30 years of experience to recognize it and of course some years to learn it. I'm asking myself wether it is possible to teach children Forth. I will experiment in this direction :-)
I totally agree! I just look at this thread and think "Are You Freaking kidding me!" Then I try to understand it! lol
Is there a way to return a cog to the IDLE operation after a STOP, so that I can relaunch something into that cog?
Do a return EXIT or call IDLE. An alternative is to force that cog with a coginit with a copy of the kernel if we have the main Tachyon cog copy itself into a buffer and proceed from there.
Hmmm up against my limited understanding of the bottom levels of TF. I guess the EXIT or IDLE are for a cog to putself on the 'available' list. I am trying to have the top-level interpreter put another cog back into the 'available' pool for later use.
Hmmm up against my limited understanding of the bottom levels of TF. I guess the EXIT or IDLE are for a cog to putself on the 'available' list. I am trying to have the top-level interpreter put another cog back into the 'available' pool for later use.
Cogs don't like being told what to do by other cogs, you have to brain wipe them and start again with coginit. However if the software running in the cog could oblige then control can be passed (back) to IDLE since it is called via the ACALL and sits in a BEGIN...AGAIN loop.
: IDLE
BEGIN !RP !SP COGID TASK 2+ C!
BEGIN 8 ms COGID TASK W@! ?DUP UNTIL
DUP 8>> IF ACALL THEN
0 COGID TASK W!
AGAIN
;
if you look into latest source you see it must be a typo
org ' align the label - needs to be passed in 14-bit PAR register
' idle loop for other Tachyon cogs
IDLE_reset
byte pInitRP ' cog reset entry ???????????
IDLE byte XOP,pInitRP
id02 byte XCALL,xInitStack
byte _1,XOP,pCOGID,XCALL,xTASK,INC,INC,CSTORE ' task+2 = 1 to indicate Tachyon running
idlp byte _8,XCALL,xms ' do nothing for a bit - saves power
byte XOP,pCOGID,XCALL,xTASK,WFETCH ' fetch cog's task variable
byte QDUP,_UNTIL,@id00-@idlp ' until it is non-zero
id00 byte DUP,_SHR8,_IF,01,ACALL ' Execute but ignore if task address is only 8-bits
byte _0,XOP,pCOGID,XCALL,xTASK,WSTORE ' clear run address only if it has returned back to idle
byte _AGAIN,@id01-@IDLE
id01
{
: IDLE
BEGIN !RP !SP COGID TASK 2+ C!
BEGIN 8 ms COGID TASK W@! ?DUP UNTIL
DUP 8>> IF ACALL THEN
0 COGID TASK W!
AGAIN
;
}
Help! I'm fighting with a timer.
I want to print a message every 500 ms. I copied the example from source code and changed a bit but I can't get it running. Does anybody know what's wrong with this?
TIMER blinktimer
WORD blinky
: BLINKY
CR ." This is the message"
blinky W@ blinktimer TIMEOUT \ reload timer
;
\ Setup the timeout vector for this TIMER
' BLINKY blinktimer ALARM
\ Write a reload value to timer's memory which we can change anytime
#500 blinky W!
\ Setup this timer to timeout in 5 seconds
#5,000 blinktimer TIMEOUT
Help! I'm fighting with a timer.
I want to print a message every 500 ms. I copied the example from source code and changed a bit but I can't get it running. Does anybody know what's wrong with this?
TIMER blinktimer
WORD blinky
: BLINKY
CR ." This is the message"
blinky W@ blinktimer TIMEOUT \ reload timer
;
\ Setup the timeout vector for this TIMER
' BLINKY blinktimer ALARM
\ Write a reload value to timer's memory which we can change anytime
#500 blinky W!
\ Setup this timer to timeout in 5 seconds
#5,000 blinktimer TIMEOUT
Thanks in advance,
proplem
The timer is running in another cog and can't control the transmit pin because it is left idling high. Cog outputs are OR'd so any cog can take the pin high but it can't force the pin low if another cog holds it high. The only way to do this is in hardware is to have a pullup on the pin and make sure that the cog floats the pin when it is left idling.
Thanks Peter, as a pc guy I wasn't aware that outputting in minicom means toggling pin 30 although researching this by myself would last some more hours. Ok, understood, but my concept has fallen to pieces.
I wanted to emit messages in a timer task and redirect these to the socket and receive via telnet on the pc side. That seemed to become a simple solution with EASYNET's on board means but obviously it won't.
Hmm. Is it possible to do a LANSEND in the timer task? No same problem, the console cog and the timer cog wouldn't cooperate either.
Seems that I need an own cog for the socket communication to exchange data with the pc. Oh oh that's hard for me to implement ...
AFAIS, it's late in Brisbane, again thank you very very much, Good night :-)
Thanks Peter, as a pc guy I wasn't aware that outputting in minicom means toggling pin 30 although researching this by myself would last some more hours. Ok, understood, but my concept has fallen to pieces.
I wanted to emit messages in a timer task and redirect these to the socket and receive via telnet on the pc side. That seemed to become a simple solution with EASYNET's on board means but obviously it won't.
Hmm. Is it possible to do a LANSEND in the timer task? No same problem, the console cog and the timer cog wouldn't cooperate either.
Seems that I need an own cog for the socket communication to exchange data with the pc. Oh oh that's hard for me to implement ...
AFAIS, it's late in Brisbane, again thank you very very much, Good night :-)
the FTP, Telnet and Weberver 'tasks' run inside keypoll, so in the main Tachyon console COG ...
... really
... it helps to study the existing code ...
before inventing your own strategy / method ...
the FTP, Telnet and Weberver 'tasks' run inside keypoll, so in the main Tachyon console COG ...
So it should be possible to identify keypoll and insert a led toggle to see, how fast this loop is running?
Study code: how much time it will take to study the code if new to Tachyon? any idea?
You can study code on a function by function basis interacting with these functions to help you understand how they work using the source code as a guide.
The keypoll loop is simply what the console cog calls when it is not receiving any serial console input. However as the network sockets are checked during keypoll the LAN layer may switch the console input from serial over to LAN where it can read data directly from the WIZnet chip buffers while implementing its own keypoll.
pub LANKEY ( -- ch )
RXSIZE@
IF
--- read a character from the receive buffer
RXREAD LW@ DUP @RX LC@
--- update read index
SWAP 1+ RXREAD LW! sRECV
ELSE
--- implement a keypoll for when LANKEY is doing nothing
?POLL
--- return with a null character
0
THEN
;
At present all hardware is accessed from the main console cog such as serial transmit but if pull-ups were used for lines that need to remain high I could modify the code so that when a cog was not using that pin it could float the line which would then remain high through the pullup. The net effect of this is that another cog could then call serial transmit or the WIZnet layer and directly control the I/O. If only the Prop had AND'd I/O instead of OR'd since active low has far more usefulness then the cogs would be free to access I/O pins that are not currently being used by another cog.
BTW, you can easily measure the time keypoll takes by measuring KEY when it is idle.
Hello everyone ... I'm back after a medical absence. Looks like I'm gonna be around for a while longer!
Has anyone figured out how to talk to the 32x32 LED matrix from Adafruit using Tachyon? They have a board they call a HAT, that takes care of the level shifting and is compatible with the Raspberry Pi. It would be nice to have the power of a Propeller talking to the HAT!
Hello everyone ... I'm back after a medical absence. Looks like I'm gonna be around for a while longer!
Has anyone figured out how to talk to the 32x32 LED matrix from Adafruit using Tachyon? They have a board they call a HAT, that takes care of the level shifting and is compatible with the Raspberry Pi. It would be nice to have the power of a Propeller talking to the HAT!
Hi Mike, welcome back and good to see that you are here a while longer! I know a thing or two about medical "absence" lately as well but it's enough to just worry about today while I try not to board any flights that start with MH....
Looking at that display I can't see any timing diagrams or datasheet anywhere, just "tutorials" and "examples" and a kind of fritzing diagram
Looks like pin-wise it needs:
6 pin - RRGGBB color
1 pin - OE display blanking (and PWM I guess)
4 pin - A B C D row pair select
2 pin - CLK & STB
Total of 13 pins.
I'm guessing that while we step through 16 row pairs with ABCD we just blank, clock 64 lots of 6-bits, strobe it, enable the display for a set time in a set period which will also be our brightness or shading control. If now we assume that if we refresh each row pair 100 times a second that means that 1600 times a second we need to clock out 64 bytes etc. The clocking of the next row can occur while a row pair is displayed but the OE may still occur whenever it needs to to effect brightness. That's 625us each cycle or just under 10us/byte, not at all a problem even with high-level Tachyon I would think. I could probably write a quick driver blindly that you could test.
Stepping through the "tutorial" I eventually find them discussing the operation of the array (in an Arduino way) but it is simply a bunch of 74HC595s which we clock. For some reason they say the only way to control the brightness/colors is by continually refreshing and I guess they mean the old dreaded frame rate modulation at a super fast rate. I would have thought that OE was perfect for this though. Guess I'd need a hands-on.
If they have used 74HCT595 chips (they say "like 74HC595s") then they can be driven easily from the Prop without the need for level shifting. If the Prop can't drive it directly then there is a very sneaky trick I use and that is to drop the voltage to the matrix using a diode (that can handle the current). Certainly this trick might at least be useful for a quick check.
(I try not to look at examples, they can confuse by making you think you need to do it the same way, which is not always the best way)
btw, I found a PDF, but sadly it's not a datasheet, just the tutorial complete with fritzing diagrams.
Hi Peter,
Thanks for the good words. I'm to the point that if I wake up on this side of the grass, it will be a good day!
There are some libraries (apparently written in Python) that have been developed by the good folks at Adafruit. I've not taken the time required to learn Python, so these files don't make much sense to me. In the bad old days, I could look at a properly documented schematic and timing diagram and using Forth to wiggle the requisite bits and have something happen. There is no documentation on the 32x32 LED matrix and precious little on the HAT interface from Adafruit (I've only seen the schematic), but it appears to mostly be only a level shifter.
Over the next few days, I'd like to sit down with your description above and see what I can do to light up something on this matrix.
Hi Peter,
Thanks for the good words. I'm to the point that if I wake up on this side of the grass, it will be a good day!
There are some libraries (apparently written in Python) that have been developed by the good folks at Adafruit. I've not taken the time required to learn Python, so these files don't make much sense to me. In the bad old days, I could look at a properly documented schematic and timing diagram and using Forth to wiggle the requisite bits and have something happen. There is no documentation on the 32x32 LED matrix and precious little on the HAT interface from Adafruit (I've only seen the schematic), but it appears to mostly be only a level shifter.
Over the next few days, I'd like to sit down with your description above and see what I can do to light up something on this matrix.
If they have used a TPIC6C595 type chip then the Vih(min) is pretty high at 0.85Vcc = 4.25V so you would need level shifters, where I would use two 74HCT245 configured in one direction to provide this as you don't need anything special.
Thinking a bit more about the OE modulation to achieve more than 64-bit color won't work as we can only modulate 64 LEDs together at a time but the idea is fine for brightness control. Your bad old days ways are my favorite ways, just look at the schematic and timing and wiggle the bits.
Hi there,
AFAIU ORG and DS are used to make contiguous memory accessible with different names. I think of it as a kind of a struct but that seems not the right view.
Could anyone clarify what's wrong with the following code?
0196 MONO16
1900 F32
----------------------------------------------------------------
LONG myruntime ok
myruntime 4 + ORG ok
4 DS var1 ok
4 DS var2 ok
4 DS var3 ok
4 DS var4 ok
1 var1 ! ok
Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
It is completely resetting tachyon. I also tried with U@ and U! but I didn't get it.
Comments
I will redo the font to make it the same one I use for the 5110 LCD as this only uses 5 bytes per character rather the than the 7 bytes using 5-bits per line. The flexible writing order configuration allows me to optimize drawing the font. Tachyon doesn't need another cog but just uses its built-in SPI instruction to write bytes or words at 4MHz speeds. I used the rotation command as well so I could view this using the right angle connector I installed to the top instead
btw, I noticed on Aliexpress that if I order a quantity of 10 it adds $2.11 postage so it costs more to buy 10 in one hit than it does to place 10 individual orders!
Here is a 5x7 font (5 bytes per char) organised as col*row
font ' 5x7 font byte 0x00, 0x00, 0x00, 0x00, 0x00 ' 0x20 (Space) byte 0x00, 0x00, 0x9E, 0x00, 0x00 ' 0x21 ! byte 0x00, 0x0E, 0x00, 0x0E, 0x00 ' 0x22 " byte 0x28, 0xFE, 0x28, 0xFE, 0x28 ' 0x23 # byte 0x48, 0x54, 0xFE, 0x54, 0x24 ' 0x24 $ byte 0x46, 0x26, 0x10, 0xC8, 0xC4 ' 0x25 % byte 0x6C, 0x92, 0xAA, 0x44, 0xA0 ' 0x26 & byte 0x00, 0x0A, 0x06, 0x00, 0x00 ' 0x27 ' byte 0x00, 0x38, 0x44, 0x82, 0x00 ' 0x28 ( byte 0x00, 0x82, 0x44, 0x38, 0x00 ' 0x29 ) byte 0x10, 0x54, 0x38, 0x54, 0x10 ' 0x2A * byte 0x10, 0x10, 0x7C, 0x10, 0x10 ' 0x2B + byte 0x00, 0xA0, 0x60, 0x00, 0x00 ' 0x2C , byte 0x10, 0x10, 0x10, 0x10, 0x10 ' 0x2D - byte 0x00, 0x60, 0x60, 0x00, 0x00 ' 0x2E . byte 0x40, 0x20, 0x10, 0x08, 0x04 ' 0x2F / byte 0x7C, 0xA2, 0x92, 0x8A, 0x7C ' 0x30 0 byte 0x00, 0x84, 0xFE, 0x80, 0x00 ' 0x31 1 byte 0x84, 0xC2, 0xA2, 0x92, 0x8C ' 0x32 2 byte 0x42, 0x82, 0x8A, 0x96, 0x62 ' 0x33 3 byte 0x30, 0x28, 0x24, 0xFE, 0x20 ' 0x34 4 byte 0x4E, 0x8A, 0x8A, 0x8A, 0x72 ' 0x35 5 byte 0x78, 0x94, 0x92, 0x92, 0x60 ' 0x36 6 byte 0x02, 0xE2, 0x12, 0x0A, 0x06 ' 0x37 7 byte 0x6C, 0x92, 0x92, 0x92, 0x6C ' 0x38 8 byte 0x0C, 0x92, 0x92, 0x52, 0x3C ' 0x39 9 byte 0x00, 0x6C, 0x6C, 0x00, 0x00 ' 0x3A : byte 0x00, 0xAC, 0x6C, 0x00, 0x00 ' 0x3B ; byte 0x00, 0x10, 0x28, 0x44, 0x82 ' 0x3C < byte 0x28, 0x28, 0x28, 0x28, 0x28 ' 0x3D = byte 0x82, 0x44, 0x28, 0x10, 0x00 ' 0x3E > byte 0x04, 0x02, 0xA2, 0x12, 0x0C ' 0x3F ? byte 0x64, 0x92, 0xF2, 0x82, 0x7C ' 0x40 @ byte 0xFC, 0x22, 0x22, 0x22, 0xFC ' 0x41 A byte 0xFE, 0x92, 0x92, 0x92, 0x6C ' 0x42 B byte 0x7C, 0x82, 0x82, 0x82, 0x44 ' 0x43 C byte 0xFE, 0x82, 0x82, 0x44, 0x38 ' 0x44 D byte 0xFE, 0x92, 0x92, 0x92, 0x82 ' 0x45 E byte 0xFE, 0x12, 0x12, 0x02, 0x02 ' 0x46 F byte 0x7C, 0x82, 0x82, 0xA2, 0x64 ' 0x47 G byte 0xFE, 0x10, 0x10, 0x10, 0xFE ' 0x48 H byte 0x00, 0x82, 0xFE, 0x82, 0x00 ' 0x49 I byte 0x40, 0x80, 0x82, 0x7E, 0x02 ' 0x4A J byte 0xFE, 0x10, 0x28, 0x44, 0x82 ' 0x4B K byte 0xFE, 0x80, 0x80, 0x80, 0x80 ' 0x4C L byte 0xFE, 0x04, 0x08, 0x04, 0xFE ' 0x4D M byte 0xFE, 0x08, 0x10, 0x20, 0xFE ' 0x4E N byte 0x7C, 0x82, 0x82, 0x82, 0x7C ' 0x4F O byte 0xFE, 0x12, 0x12, 0x12, 0x0C ' 0x50 P byte 0x7C, 0x82, 0xA2, 0x42, 0xBC ' 0x51 Q byte 0xFE, 0x12, 0x32, 0x52, 0x8C ' 0x52 R byte 0x8C, 0x92, 0x92, 0x92, 0x62 ' 0x53 S byte 0x02, 0x02, 0xFE, 0x02, 0x02 ' 0x54 T byte 0x7E, 0x80, 0x80, 0x80, 0x7E ' 0x55 U byte 0x3E, 0x40, 0x80, 0x40, 0x3E ' 0x56 V byte 0xFE, 0x40, 0x30, 0x40, 0xFE ' 0x57 W byte 0xC6, 0x28, 0x10, 0x28, 0xC6 ' 0x58 X byte 0x06, 0x08, 0xF0, 0x08, 0x06 ' 0x59 Y byte 0xC2, 0xA2, 0x92, 0x8A, 0x86 ' 0x5A Z byte 0x00, 0x00, 0xFE, 0x82, 0x82 ' 0x5B [ byte 0x04, 0x08, 0x10, 0x20, 0x40 ' 0x5C \ byte 0x82, 0x82, 0xFE, 0x00, 0x00 ' 0x5D ] byte 0x08, 0x04, 0x02, 0x04, 0x08 ' 0x5E ^ byte 0x80, 0x80, 0x80, 0x80, 0x80 ' 0x5F _ byte 0x00, 0x02, 0x04, 0x08, 0x00 ' 0x60 ` byte 0x40, 0xA8, 0xA8, 0xA8, 0xF0 ' 0x61 a byte 0xFE, 0x90, 0x88, 0x88, 0x70 ' 0x62 b byte 0x70, 0x88, 0x88, 0x88, 0x40 ' 0x63 c byte 0x70, 0x88, 0x88, 0x90, 0xFE ' 0x64 d byte 0x70, 0xA8, 0xA8, 0xA8, 0x30 ' 0x65 e byte 0x10, 0xFC, 0x12, 0x02, 0x04 ' 0x66 f byte 0x10, 0x28, 0xA8, 0xA8, 0x78 ' 0x67 g byte 0xFE, 0x10, 0x08, 0x08, 0xF0 ' 0x68 h byte 0x00, 0x88, 0xFA, 0x80, 0x00 ' 0x69 i byte 0x40, 0x80, 0x88, 0x7A, 0x00 ' 0x6A j byte 0x00, 0xFE, 0x20, 0x50, 0x88 ' 0x6B k byte 0x00, 0x82, 0xFE, 0x80, 0x00 ' 0x6C l byte 0xF8, 0x08, 0x30, 0x08, 0xF0 ' 0x6D m byte 0xF8, 0x10, 0x08, 0x08, 0xF0 ' 0x6E n byte 0x70, 0x88, 0x88, 0x88, 0x70 ' 0x6F o byte 0xF8, 0x28, 0x28, 0x28, 0x10 ' 0x70 p byte 0x10, 0x28, 0x28, 0x30, 0xF8 ' 0x71 q byte 0xF8, 0x10, 0x08, 0x08, 0x10 ' 0x72 r byte 0x90, 0xA8, 0xA8, 0xA8, 0x40 ' 0x73 s byte 0x08, 0x7E, 0x88, 0x80, 0x40 ' 0x74 t byte 0x78, 0x80, 0x80, 0x40, 0xF8 ' 0x75 u byte 0x38, 0x40, 0x80, 0x40, 0x38 ' 0x76 v byte 0x78, 0x80, 0x60, 0x80, 0x78 ' 0x77 w byte 0x88, 0x50, 0x20, 0x50, 0x88 ' 0x78 x byte 0x18, 0xA0, 0xA0, 0xA0, 0x78 ' 0x79 y byte 0x88, 0xC8, 0xA8, 0x98, 0x88 ' 0x7A z byte 0x00, 0x10, 0x6C, 0x82, 0x00 ' 0x7B { byte 0x00, 0x00, 0xFE, 0x00, 0x00 ' 0x7C | byte 0x00, 0x82, 0x6C, 0x10, 0x00 ' 0x7D } byte 0x20, 0x10, 0x10, 0x20, 0x10 ' 0x7E ~ byte 0xF0, 0x88, 0x84, 0x88, 0xF0 ' 0x7FThat looks identical to the 5x7 I use for the Nokia 5110 LCD except it is left justified. I started to code a new version using this font table.
edit: looks like I can squeeze in a P8, Bluetooth, RTC, IMU and maybe some other stuff along with a small camera battery.
I set the time via a terminal, and in the case of the final unit, via Bluetooth. But there is no reason why I couldn't adjust it from the 5-way tactile switch (left,right,up,down,press). Actually I read the real RTC into the soft RTC and that's what the software transparently accesses just to cut down on the slower I2C access.
And if you order a greater number suddenly delivery costs go up significantly. So I regularly place multiple orders for multiple parts.
I totally agree! I just look at this thread and think "Are You Freaking kidding me!" Then I try to understand it! lol
Cogs don't like being told what to do by other cogs, you have to brain wipe them and start again with coginit. However if the software running in the cog could oblige then control can be passed (back) to IDLE since it is called via the ACALL and sits in a BEGIN...AGAIN loop.
: IDLE BEGIN !RP !SP COGID TASK 2+ C! BEGIN 8 ms COGID TASK W@! ?DUP UNTIL DUP 8>> IF ACALL THEN 0 COGID TASK W! AGAIN ;if you look into latest source you see it must be a typo
org ' align the label - needs to be passed in 14-bit PAR register ' idle loop for other Tachyon cogs IDLE_reset byte pInitRP ' cog reset entry ??????????? IDLE byte XOP,pInitRP id02 byte XCALL,xInitStack byte _1,XOP,pCOGID,XCALL,xTASK,INC,INC,CSTORE ' task+2 = 1 to indicate Tachyon running idlp byte _8,XCALL,xms ' do nothing for a bit - saves power byte XOP,pCOGID,XCALL,xTASK,WFETCH ' fetch cog's task variable byte QDUP,_UNTIL,@id00-@idlp ' until it is non-zero id00 byte DUP,_SHR8,_IF,01,ACALL ' Execute but ignore if task address is only 8-bits byte _0,XOP,pCOGID,XCALL,xTASK,WSTORE ' clear run address only if it has returned back to idle byte _AGAIN,@id01-@IDLE id01 { : IDLE BEGIN !RP !SP COGID TASK 2+ C! BEGIN 8 ms COGID TASK W@! ?DUP UNTIL DUP 8>> IF ACALL THEN 0 COGID TASK W! AGAIN ; }the original does only a WFETCH
there is no ! there
I want to print a message every 500 ms. I copied the example from source code and changed a bit but I can't get it running. Does anybody know what's wrong with this?
Thanks in advance,
proplem
The timer is running in another cog and can't control the transmit pin because it is left idling high. Cog outputs are OR'd so any cog can take the pin high but it can't force the pin low if another cog holds it high. The only way to do this is in hardware is to have a pullup on the pin and make sure that the cog floats the pin when it is left idling.
I wanted to emit messages in a timer task and redirect these to the socket and receive via telnet on the pc side. That seemed to become a simple solution with EASYNET's on board means but obviously it won't.
Hmm. Is it possible to do a LANSEND in the timer task? No same problem, the console cog and the timer cog wouldn't cooperate either.
Seems that I need an own cog for the socket communication to exchange data with the pc. Oh oh that's hard for me to implement ...
AFAIS, it's late in Brisbane, again thank you very very much, Good night :-)
the FTP, Telnet and Weberver 'tasks' run inside keypoll, so in the main Tachyon console COG ...
... really
... it helps to study the existing code ...
before inventing your own strategy / method ...
Study code: how much time it will take to study the code if new to Tachyon? any idea?
You can study code on a function by function basis interacting with these functions to help you understand how they work using the source code as a guide.
The keypoll loop is simply what the console cog calls when it is not receiving any serial console input. However as the network sockets are checked during keypoll the LAN layer may switch the console input from serial over to LAN where it can read data directly from the WIZnet chip buffers while implementing its own keypoll.
At present all hardware is accessed from the main console cog such as serial transmit but if pull-ups were used for lines that need to remain high I could modify the code so that when a cog was not using that pin it could float the line which would then remain high through the pullup. The net effect of this is that another cog could then call serial transmit or the WIZnet layer and directly control the I/O. If only the Prop had AND'd I/O instead of OR'd since active low has far more usefulness then the cogs would be free to access I/O pins that are not currently being used by another cog.
BTW, you can easily measure the time keypoll takes by measuring KEY when it is idle.
Has anyone figured out how to talk to the 32x32 LED matrix from Adafruit using Tachyon? They have a board they call a HAT, that takes care of the level shifting and is compatible with the Raspberry Pi. It would be nice to have the power of a Propeller talking to the HAT!
Hi Mike, welcome back and good to see that you are here a while longer! I know a thing or two about medical "absence" lately as well but it's enough to just worry about today while I try not to board any flights that start with MH....
Looking at that display I can't see any timing diagrams or datasheet anywhere, just "tutorials" and "examples" and a kind of fritzing diagram
Looks like pin-wise it needs:
6 pin - RRGGBB color
1 pin - OE display blanking (and PWM I guess)
4 pin - A B C D row pair select
2 pin - CLK & STB
Total of 13 pins.
I'm guessing that while we step through 16 row pairs with ABCD we just blank, clock 64 lots of 6-bits, strobe it, enable the display for a set time in a set period which will also be our brightness or shading control. If now we assume that if we refresh each row pair 100 times a second that means that 1600 times a second we need to clock out 64 bytes etc. The clocking of the next row can occur while a row pair is displayed but the OE may still occur whenever it needs to to effect brightness. That's 625us each cycle or just under 10us/byte, not at all a problem even with high-level Tachyon I would think. I could probably write a quick driver blindly that you could test.
Stepping through the "tutorial" I eventually find them discussing the operation of the array (in an Arduino way) but it is simply a bunch of 74HC595s which we clock. For some reason they say the only way to control the brightness/colors is by continually refreshing and I guess they mean the old dreaded frame rate modulation at a super fast rate. I would have thought that OE was perfect for this though. Guess I'd need a hands-on.
If they have used 74HCT595 chips (they say "like 74HC595s") then they can be driven easily from the Prop without the need for level shifting. If the Prop can't drive it directly then there is a very sneaky trick I use and that is to drop the voltage to the matrix using a diode (that can handle the current). Certainly this trick might at least be useful for a quick check.
(I try not to look at examples, they can confuse by making you think you need to do it the same way, which is not always the best way)
btw, I found a PDF, but sadly it's not a datasheet, just the tutorial complete with fritzing diagrams.
Thanks for the good words. I'm to the point that if I wake up on this side of the grass, it will be a good day!
There are some libraries (apparently written in Python) that have been developed by the good folks at Adafruit. I've not taken the time required to learn Python, so these files don't make much sense to me. In the bad old days, I could look at a properly documented schematic and timing diagram and using Forth to wiggle the requisite bits and have something happen. There is no documentation on the 32x32 LED matrix and precious little on the HAT interface from Adafruit (I've only seen the schematic), but it appears to mostly be only a level shifter.
Over the next few days, I'd like to sit down with your description above and see what I can do to light up something on this matrix.
If they have used a TPIC6C595 type chip then the Vih(min) is pretty high at 0.85Vcc = 4.25V so you would need level shifters, where I would use two 74HCT245 configured in one direction to provide this as you don't need anything special.
Thinking a bit more about the OE modulation to achieve more than 64-bit color won't work as we can only modulate 64 LEDs together at a time but the idea is fine for brightness control. Your bad old days ways are my favorite ways, just look at the schematic and timing and wiggle the bits.
AFAIU ORG and DS are used to make contiguous memory accessible with different names. I think of it as a kind of a struct but that seems not the right view.
Could anyone clarify what's wrong with the following code?
It is completely resetting tachyon. I also tried with U@ and U! but I didn't get it.
Thanks in advance,
proplem