And it looks like the PropTool compile report may have always had borked frequency report. Just tested it with another program and it's the same. I'd never really looked before. I barely touch it because it can't see my comports. Yet PNut has no issue finding the Prop2.
As you borrowed and modified one of my objects, I'm doing the same with yours. I'm very stingy with cogs, so I wanted to have change that part. I started with an inline PASM method. Once that worked (verified using LA), I moved the code to be loaded into the upper user RAM of the interpreter cog to be called. Here's the first part of the start() method that captures the IO pins used for the display, sets them up, then loads the SPI driver.
pub startx(cspin, dcpin, dopin, clkpin, rstpin) | m, x
'' Start oled driver
'' -- pins may be non-contiguous, but DO and CLK should be neighbors
longmove(@cs, @cspin, 5) ' copy pins
pinh(cs) ' configure pins
pinl(dc)
pinh(rst)
m := P_SYNC_TX | P_OE ' spi tx mode
m |= ((clk-dout) & %111) << 24 ' add clk offset (B pin)
x := %1_00111 ' start/stop mode, 8 bits
pinstart(dout, m, x, 0) ' activate smart pin
pinf(dout) ' reset/disable until used
m := P_PULSE | P_OE | P_INVERT_OUTPUT ' spi clock mode
x.word[0] := 2 #> (clkfreq / SPI_HZ) <# $FFFF ' ticks in period
x.word[1] := x.word[0] >> 1 ' ticks in low cycle (50%)
pinstart(clk, m, x, 0)
longmove(@_cs, @cs, 4) ' move pins to driver code
regload(@chunk) ' load driver into cog
' hard reset
' initialization
This is the shell method and PASM code that uses the configured SPI pins.
pub write(value, dcbit)
pr0 := value
pr1 := dcbit
call(#spi_write)
dat
chunk word spi_write, spi_finish-spi_write-1
org $110
' write pr1.[0] to dc pin, write low 8 bits of pr0 MSBFIRST to dout pin
spi_write drvl _cs
testb pr1, #0 wc
drvc _dc
ror pr0, #8
rev pr0
wypin pr0, _dout
drvl _dout
wypin #8, _clk
nop
testp _clk wc
if_nc jmp #$-1
fltl _dout
_ret_ drvh _cs
_cs long 0
_dc long 0
_dout long 0
_clk long 0
spi_finish
This, of course, is a WIP and I've only checked the SPI output with a logic analyzer. Once I get the display code ported and working I'll share.
Thanks @JonnyMac ! Much appreciated! Today's goal for me is to get the project into the DevOps repository. DM me your email if you would like R/W access.
Found a new bug. P1 font no longer works with FlexProp. Appears to have broken after FastSpin 4.1.3, back in the FlexGUI days. Works correctly with Proptool.
Found the issue. Not sure if this is something you want to look at @ersmith
''Write a 16x32 character to the screen at position 0-7 (left to right)
cbase:=@P1Font+((ch & $FE) << 6) ' Compute the base of the interleaved character
Works but....
''Write a 16x32 character to the screen at position 0-7 (left to right)
cbase:=@P1Font+((ch&$FE) << 6) ' Compute the base of the interleaved character
Does NOT work in FlexProp 5.9.12.
It does work with Propeller Tool 2.6.2.
@ke4pjw : When you say "Does NOT work" what do you mean by that? Does it give a syntax error, or does it compile incorrect code? Is this Spin1 or Spin2 code? I need some more context to figure this out, because for me the following two functions generate identical assembly code:
@ersmith The P1 font was being mangled. I cannot reproduce the problem, now. Sigh. I apologize. I tested before and after and it was reproducible, more than once. It only worked correctly in an old version of flexGUI. It may be where I have some of the libraries pointed to in FlexProp that caused the issue. I can't make it do it now. Again I apologize.
There was different editions of the font. I made a point of eliminating all copies of one edition I had a couple of years back because it caused me grief. Err, I've found both again! I probably couldn't remember which one to delete, same as now.
@ke4pjw said:
@ersmith The P1 font was being mangled. I cannot reproduce the problem, now. Sigh. I apologize. I tested before and after and it was reproducible, more than once. It only worked correctly in an old version of flexGUI. It may be where I have some of the libraries pointed to in FlexProp that caused the issue. I can't make it do it now. Again I apologize.
No worries, Terry. If you do find out what was going on please let me know and I'll look into it!
Updated to run in a single cog.
Updated write1x6String() and write1x16String() to process string length automatically.
This version does not work in FlexProp 5.9.12. This is most likely related to the quick hack of moving the SPI code to inline PASM.
Comments
Okay.
And it looks like the PropTool compile report may have always had borked frequency report. Just tested it with another program and it's the same. I'd never really looked before. I barely touch it because it can't see my comports. Yet PNut has no issue finding the Prop2.
I found the bug in this code. Was referencing legacy code and was not releasing the RST line.
It now works with the Parallax Propeller Tool.
I updated the "To Do" and will spend some time this week trying to get those items completed.
Code is attached on the first post.
Another quick update. Moved the 5x7 font into a file and out of code.
Version 0.9.2 Released at top of thread.
As you borrowed and modified one of my objects, I'm doing the same with yours. I'm very stingy with cogs, so I wanted to have change that part. I started with an inline PASM method. Once that worked (verified using LA), I moved the code to be loaded into the upper user RAM of the interpreter cog to be called. Here's the first part of the start() method that captures the IO pins used for the display, sets them up, then loads the SPI driver.
This is the shell method and PASM code that uses the configured SPI pins.
This, of course, is a WIP and I've only checked the SPI output with a logic analyzer. Once I get the display code ported and working I'll share.
Thanks @JonnyMac ! Much appreciated! Today's goal for me is to get the project into the DevOps repository. DM me your email if you would like R/W access.
That SPI code in the interpreter cog works with the display. I have the basics running: clear(), line(), and rectangle() are working as expected.
Found a new bug. P1 font no longer works with FlexProp. Appears to have broken after FastSpin 4.1.3, back in the FlexGUI days. Works correctly with Proptool.
Found the issue. Not sure if this is something you want to look at @ersmith
Works but....
Does NOT work in FlexProp 5.9.12.
It does work with Propeller Tool 2.6.2.
@ke4pjw : When you say "Does NOT work" what do you mean by that? Does it give a syntax error, or does it compile incorrect code? Is this Spin1 or Spin2 code? I need some more context to figure this out, because for me the following two functions generate identical assembly code:
EDIT: I downloaded your repo and tried both variations in oled_AsmDrv.spin2, and again, the generated assembly was the same in both cases.
@ersmith The P1 font was being mangled. I cannot reproduce the problem, now. Sigh. I apologize. I tested before and after and it was reproducible, more than once. It only worked correctly in an old version of flexGUI. It may be where I have some of the libraries pointed to in FlexProp that caused the issue. I can't make it do it now. Again I apologize.
--Terry
There was different editions of the font. I made a point of eliminating all copies of one edition I had a couple of years back because it caused me grief. Err, I've found both again! I probably couldn't remember which one to delete, same as now.
No worries, Terry. If you do find out what was going on please let me know and I'll look into it!
Version 0.9.4 released.
Updated to run in a single cog.
Updated write1x6String() and write1x16String() to process string length automatically.
This version does not work in FlexProp 5.9.12. This is most likely related to the quick hack of moving the SPI code to inline PASM.
Many, MANY things need to be cleaned up.
For a nice clean implementation for the SSD1331, please see Jon's code at https://forums.parallax.com/discussion/174665/spin2-interpreter-tricks-for-cogless-96x64-oled-driver-now-works-w-flexprop
Version 0.9.5 released.
A terminal string interface added. Includes scrolling and wraparound.
Nice!
Version 0.9.6 released.
SEND() method has been implemented.
I want to add ANSI escape sequences to manipulate colors and cursor position. Maybe later this weekend.
I want to thank @cgracey for implementing the SEND() method. The utility of that is incredible!