Got the RX side of this esp8266 client working, need to breadboard a module to remove the FTDI conflict from the TX side.
Great, let me know how it goes. You shouldn't need to do much if the FT232 chip is still connected, may just diode couple them with a pullup so they both can talk to the Prop.
Now, if the transmit data from the ESP goes into a PPNET rxtx line through a resistor and back out again into the ESP rxd line we should be able to access a network of these devices.
Got the RX side of this esp8266 client working, need to breadboard a module to remove the FTDI conflict from the TX side.
Great, let me know how it goes. You shouldn't need to do much if the FT232 chip is still connected, may just diode couple them with a pullup so they both can talk to the Prop.
Now, if the transmit data from the ESP goes into a PPNET rxtx line through a resistor and back out again into the ESP rxd line we should be able to access a network of these devices.
Can you sketch what you mean by "diode couple them both" plz.
Can you sketch what you mean by "diode couple them both" plz.
The TXD lines of the FT232 and ESP chip (their outputs) can be diode OR'd together since they are active low we then add a pullup on the Prop's RXD pin. That way one OR the other can be talking to the Prop, but obviously not at the exact same time.
Well I have to say this is really cool. A 5$ olimex esp8266 module hooked to a prop with tachyon. https is included in the build for the olimex board. Thanks for the diagram Peter, works great!
Well I have to say this is really cool. A 5$ olimex esp8266 module hooked to a prop with tachyon. https is included in the build for the olimex board. Thanks for the diagram Peter, works great!
@D.P
what do you run on the ESP?
is the 'Microcontroller Console' a page / applet served by the ESP?
Where can I get it?
Will be great to run PPNET over ESP in addition to telnet / http ...
It was difficult to determine (for me at least) the proper flashing and settings for the Olimex board and propeller to work.
Flash with this command after installing the project.
//flash the module, replace with your serial port
esptool.py --port /dev/tty.usbserial-A700fKOV --baud 460800 write_flash -fs 16m -ff 80m \
0x00000 boot_v1.5.bin 0x1000 user1.bin \
0x1FC000 esp_init_data_default.bin 0x7E000 blank.bin
If something goes bonkers or you want to erase bad settings erase the entire flash using this CLI
//eraase entire flash, replace with your serial port setting
esptool.py --port /dev/tty.usbserial-A700fKOV erase_flash
I have included the esp_init_data_default.bin because for some reason it is not included in the project? Just drop in the same folder as the project. On the home page of the system after boot set the TX/RX lines for the uc (prop with tachyon loaded) to swapped, 13, 15 and hook them up to 30, 31 on the prop.
I'm using MacTerm to telnet at 115200, for some reason the standard telnet client in OSX was causing the prop to reset on connect, MacTerm works absolutely great so far.
It was difficult to determine (for me at least) the proper flashing and settings for the Olimex board and propeller to work.
Flash with this command after installing the project.
//flash the module, replace with your serial port
esptool.py --port /dev/tty.usbserial-A700fKOV --baud 460800 write_flash -fs 16m -ff 80m \
0x00000 boot_v1.5.bin 0x1000 user1.bin \
0x1FC000 esp_init_data_default.bin 0x7E000 blank.bin
If something goes bonkers or you want to erase bad settings erase the entire flash using this CLI
//eraase entire flash, replace with your serial port setting
esptool.py --port /dev/tty.usbserial-A700fKOV erase_flash
I have included the esp_init_data_default.bin because for some reason it is not included in the project? Just drop in the same folder as the project. On the home page of the system after boot set the TX/RX lines for the uc (prop with tachyon loaded) to swapped, 13, 15 and hook them up to 30, 31 on the prop.
I'm using MacTerm to telnet at 115200, for some reason the standard telnet client in OSX was causing the prop to reset on connect, MacTerm works absolutely great so far.
Have fun
I have only used NodeMCU / Lua so far to write little applications.
So you are using a predefined SW which just acts as a HTTP / Telnet?? to Serial Gateway ?
EDIT: thanks, read the documentation - looks nice ...
My idea was to implement the ppnet on ESP8266/NodeMCU/Lua to use the ESPs as additional sensor / actor nodes in a Tachyon-ppnet ...
Apologies if this has been posted before or if I'm using the wrong files. I'm a newbie to TACHYON and am working my way through the introduction. I've not read the whole of this giant thread.
I've been using the PING sensor and found it would sometimes lock up. This seems to be due to the PING definition in EXTEND.FTH which generates the trigger pulse:
DUP HIGH >R R> LOW --- 10us trigger (dummy cycles)
Apologies if this has been posted before or if I'm using the wrong files. I'm a newbie to TACHYON and am working my way through the introduction. I've not read the whole of this giant thread.
I've been using the PING sensor and found it would sometimes lock up. This seems to be due to the PING definition in EXTEND.FTH which generates the trigger pulse:
DUP HIGH >R R> LOW --- 10us trigger (dummy cycles)
On my (96 MHz) prop:
LAP >R R> LAP .LAP 1.833us ok
so perhaps the definition should be changed to:
DUP HIGH 10 us LOW --- 10us trigger pulse
Hi,
You are only measuring the push and pop instructions onto the R stack and not the DUP, HIGH, LOW and original pin number being pushed onto the stack to begin with.
LAP 5 DUP HIGH >R R> LOW LAP .LAP 6.500us ok
Post up your code so we can help if there is another "problem" to find.
Yes, but 1) 6.5 uS is still too short to reliably trigger the PING sensor, and 2) it's wrong to include the time for both the HIGH and LOW instructions plus the DUP. The DUP happens before the pulse even starts and we're interested in the actual length of the pulse not the time from when HIGH starts till LOW finishes. I suppose it is fair to include either HIGH or LOW though - assuming they both execute in the same time.
on my 96MHz prop:
0 LAP >R R> LOW LAP .LAP 3.166us ok
The code is just what's in Peter's Introduction and in the latest EXTEND.FTH
PING sometimes locked up with it as written - because it's waiting for a 'Echo' from the sensor but the sensor never sends one because it missed the too-short 'Trig'. Once I replaced the >R R> with 10 us it's working fine. I suppose I could put multiple >R R> instructions in until LAP times it at 10us or more - but it's better to have a solution that will work regardless of the prop clock speed (within reason).
Yes, but 1) 6.5 uS is still too short to reliably trigger the PING sensor, and 2) it's wrong to include the time for both the HIGH and LOW instructions plus the DUP. The DUP happens before the pulse even starts and we're interested in the actual length of the pulse not the time from when HIGH starts till LOW finishes. I suppose it is fair to include either HIGH or LOW though - assuming they both execute in the same time.
on my 96MHz prop:
0 LAP >R R> LOW LAP .LAP 3.166us ok
The code is just what's in Peter's Introduction and in the latest EXTEND.FTH
PING sometimes locked up with it as written - because it's waiting for a 'Echo' from the sensor but the sensor never sends one because it missed the too-short 'Trig'. Once I replaced the >R R> with 10 us it's working fine. I suppose I could put multiple >R R> instructions in until LAP times it at 10us or more - but it's better to have a solution that will work regardless of the prop clock speed (within reason).
with all the speedups Peter implemented recently (and maybe in the future)
the
10 us
is definitely the save way to go.
I used the old code in V2.7 and it worked OK
Yes, that is a good point about the PING sensor, I haven't worked with it in a while and the older software probably worked fine. But small values of microseconds delays will have some overhead anyway although I just checked this in V4 and 10us comes out as 10.5us so I could trim the overhead but I wouldn't try to to use delays less than 10us using the "us" word.
DUP HIGH 10 us LOW will be slightly over 10us but as HIGH or LOW take 3us in V4 because they are coded in high level but OUTSET and OUTCLR and much faster if you need precise control.
I've updated EXTEND with this line in PING
MASK DUP OUTSET 9 us OUTCLR
which I will check should deliver a 10.5us pulse.
In fact if you time a single I/O operation plus the delay this will give you a better idea of the width of the pulse. In V4 I can do this:
( 0034 $33B2 PBJ ) 0 LAP OUTSET 18 FOR NEXT LAP .LAP
960 cycles at 96000000Hz or 10.000us
I guessed it was the speed improvements made in updates to TACHYON that had 'broken' PING. Main reasons I posted were: 1) To make sure I wasn't doing something stupid, and 2) If I wasn't doing something stupid then it's a good idea to update the Introduction document so that newbies like me don't hit a hurdle really early on causing them to give up on TACHYON!
@ceptimus
If we all gave up whenever we hit hurdles we would do the same with other hurdles. Anything worthwhile is worthwhile doing. I figure if I've made all this effort to come this far I'm certainly not going to let it go to waste but make it count.
Know that if you persevere with this path then it will certainly be very rewarding and well worth the effort. You will be able to do simple things with ease, and you will be able to do complicated things with ease also. But like spoken languages you must learn to think in that language to become fluent rather than translating and comparing which will only hinder you.
Talking about PING, I was thinking the other day that rather than calling my ping-pong network PPNET, which doesn't sound that good when spoken that I should call it PINGNET instead. as the word ping has a ring to it (pun). I want to formalize it and make it a standard object that can be included as needed into any Spin/PASM project, even a bitmap VGA object that I have used in the past that is a bit of a memory hog at over 24kB. This means I can hang a VGA Prop off the bus and do some remote graphics easily.
Talking about PING, I was thinking the other day that rather than calling my ping-pong network PPNET, which doesn't sound that good when spoken that I should call it PINGNET instead. as the word ping has a ring to it (pun).
sounds good
"give me a PING ... just one PING ..."
Ramius in 'Hunt for red october' ...
Hi all,
as some of you remember I'm currently fighting with a tachyon parallel lcd graphics driver for the LameStation.
I have the simple exercise of setting some bits in a long variable and it costs me much time to figure it out.
I made a register with maybe the following value
long lcd
%1101_1011_1001 lcd !
Later I want to manipulate maybe the upper two bits (but it could differ)
%10XX_XXX_XXXX
How do I solve this (efficiently) in FORTH? In C I would use a bit array.
BTW I feel sick and maybe my brain isn't fully working (if the solution is too silly).
I looked in the introduction and glossary but didn't find it - this could be a hint to add a bit manipulation paragraph to the introduction.
Hi all,
as some of you remember I'm currently fighting with a tachyon parallel lcd graphics driver for the LameStation.
I have the simple exercise of setting some bits in a long variable and it costs me much time to figure it out.
I made a register with maybe the following value
long lcd
%1101_1011_1001 lcd !
Later I want to manipulate maybe the upper two bits (but it could differ)
%10XX_XXX_XXXX
How do I solve this (efficiently) in FORTH?
BTW I feel sick and maybe my brain isn't fully working (if the solution is too silly).
I looked in the introduction and glossary but didn't find it - this could be a hint to add an bit manipulation paragraph to the introduction.
Thanks in advance,
proplem
There is a clear and set operation in Tachyon but it is currently used for bytes, not longs. You could create the long equivalent:
But of course you could use the byte set and clear easily by referring to the offset of the variable, that is lcd+1. So to write to certain bits the idea is that you clear all the relevant bits and then set them with the data that you want. Writing directly to the byte in the long though is easier than trying to apply a mask.
However I think you don't need these operations, the LCD driver is probably simpler than you think. I could write one "blind" in the sense that I can't try it out but you could try it out and debug and tweak it if you like.
Hi all,
as some of you remember I'm currently fighting with a tachyon parallel lcd graphics driver for the LameStation.
I have the simple exercise of setting some bits in a long variable and it costs me much time to figure it out.
I made a register with maybe the following value
long lcd
%1101_1011_1001 lcd !
Later I want to manipulate maybe the upper two bits (but it could differ)
%10XX_XXX_XXXX
How do I solve this (efficiently) in FORTH?
BTW I feel sick and maybe my brain isn't fully working (if the solution is too silly).
I looked in the introduction and glossary but didn't find it - this could be a hint to add an bit manipulation paragraph to the introduction.
Thanks in advance,
proplem
There is a clear and set operation in Tachyon but it is currently used for bytes, not longs. You could create the long equivalent:
But of course you could use the byte set and clear easily by referring to the offset of the variable, that is lcd+1. So to write to certain bits the idea is that you clear all the relevant bits and then set them with the data that you want. Writing directly to the byte in the long though is easier than trying to apply a mask.
However I think you don't need these operations, the LCD driver is probably simpler than you think. I could write one "blind" in the sense that I can't try it out but you could try it out and debug and tweak it if you like.
@Peter ... sure you can do it blind ;-) ...
happened with me a few times in the past as well ...
I ask here some thing I don't understand fully ..
and when I check back Peter provided the full blown solution
so maybe give @Problem a little bit of a chance to develop it himself ;-)
@Proplem
as for the bit in long ...
to me sounds overcomplicating things.
I don't think this will even be required to drive this little LCD.
If you align the 8 data bits at a byte border 0..7, 8..15, 16..23 ...
then there are only a few control lines to manipulate
define a mask for each control pin
9 MASK == yxPin
my lamestation graphics driver is growing to a huge project. But it is in a state where nobody else can help - everything is already lying in front of me but the puzzle doesn't want to fit together. Grrrr. "No effort, no joy." I fully agree with this but sometimes ...
A friend told me: "The way is going from dilletantic, to complicated to simplicity." I hope I'm advancing to the complicated phase, but still no joy.
Nevertheless I'm looking forward when it's working. Good night,
proplem(s) :-))
@proplem - those two routines I gave you are the heart of the driver. Use those and interactively bring the LCD to life which will help you understand just what you need, and what you don't need. Don't make the mistake of trying to convert code, just keep it simple and it will be simple.
The problem is the datasheet. If I knew what this LCD is waiting for I could go forward step by step and implement it in Forth. Because I'm lacking assembler know how, I can't understand the driver presented by LameStation (https://github.com/lamestation/lamestation-sdk/blob/master/library/LameLCD.spin). I don't want to over stress your help in this thread. Should I open a different thread asking for help with the LCD datasheet?
The problem is the datasheet. If I knew what this LCD is waiting for I could go forward step by step and implement it in Forth. Because I'm lacking assembler know how, I can't understand the driver presented by LameStation (https://github.com/lamestation/lamestation-sdk/blob/master/library/LameLCD.spin). I don't want to over stress your help in this thread. Should I open a different thread asking for help with the LCD datasheet?
despairing, proplem
Don't read the assembly language driver and you won't despair. As I keep saying, these two words will allow you to interact with the hardware, the datasheet is useful as a guide but the interaction will confirm what it actually does. For example when you write data and the Y pointer increments you should be able to see it happening. Looking at the basic functions which I have shortened to DAT and CMD you can try these few things.
I've just checked the lamestation schematics and RC2 seems to have D0..D7 on P2..P9, so I will make adjustments here. Is that the version you have?
Using these functions after you have defined the pins *rs *E
0 == *rs
1 == *E
10 == *CS1
11 == *CS2
--- Output a byte of data to the LCD
pri DAT ( ch -- )
*rs HIGH
pri WRLCD ( data -- )
--- shift data left two bits to P2..P9
2* 2*
--- write data (set after clear)
$3FC OUTCLR OUTSET
--- pulse chip enable
*E HIGH *E LOW
;
--- Output a byte to the LCD as an instruction
pri CMD ( cmd -- )
*rs LOW WRLCD
;
try this interactively - one line at a time as if you are typing them in.
*CS1 HIGH *CS2 HIGH --- why not
$3F CMD --- enables display
$FF DAT --- write some data, should be 8 pixels wide
$55 DAT --- dots are written, should be next lot of 8 pixels down.
$FF80 64 ADO I C@ DAT LOOP --- copy 64 bytes of data from ROM - just to see
@Peter,
that's what I wasn't able to do myself. Some pixels are switching on and off.
I don't know what I can say.
The journey to shake your hands would last about 23:10 hours and would be very expensive. So I just can write: thank you, you extaordinary person from the other side of the planet.
hooray!!! This is fun again. LCDITER to write any byte to the display within minutes, and LCDCLS clears the screen.
I want to implement some simple drawing methods PLOT, LINE, CIRCLE or make them usable if you already wrote some before. Any tips which way I should go?
hooray!!! This is fun again. LCDITER to write any byte to the display within minutes, and LCDCLS clears the screen.
I want to implement some simple drawing methods PLOT, LINE, CIRCLE or make them usable if you already wrote some before. Any tips which way I should go?
Thanks,
proplem
Yay!
Looking at that information from that site seems to indicate that the not only do you have to deal with pages but you also have to decide which of the two LCD controllers to access via CS1 and CS2 that the pixels appear on. I would therefore dedicate a buffer to do all your drawing in, nice and simple but then have the screen updater picks out the pixels in the correct order to display it.
You can have a look in extras and besides the various LCD drivers, some that write directly to the LCD etc, you will find VGA.FTH which of course writes to a buffer. So first however I would write the convoluted algorithm that reads the buffer in a linear XY fashion and works out how to write that to the screen.
Eight pages of 64 bytes where each byte is represented as a vertical column but the next byte writes to the right of that via the "Y" counter (they don't even know X from Y axis). The other 64 pixels on the right hand side are via CS2 in the second controller chip inside the same kludgy chip.
Funny thing is I have use similar displays but based on ST7920 controller and it is very easy to draw directly to the screen, but as I said I feel that having a 128bitx64bit buffer and updating the display from that might be easier.
Comments
Great, let me know how it goes. You shouldn't need to do much if the FT232 chip is still connected, may just diode couple them with a pullup so they both can talk to the Prop.
Now, if the transmit data from the ESP goes into a PPNET rxtx line through a resistor and back out again into the ESP rxd line we should be able to access a network of these devices.
The TXD lines of the FT232 and ESP chip (their outputs) can be diode OR'd together since they are active low we then add a pullup on the Prop's RXD pin. That way one OR the other can be talking to the Prop, but obviously not at the exact same time.
@D.P
what do you run on the ESP?
is the 'Microcontroller Console' a page / applet served by the ESP?
Where can I get it?
Will be great to run PPNET over ESP in addition to telnet / http ...
It was difficult to determine (for me at least) the proper flashing and settings for the Olimex board and propeller to work.
Flash with this command after installing the project.
If something goes bonkers or you want to erase bad settings erase the entire flash using this CLI
I have included the esp_init_data_default.bin because for some reason it is not included in the project? Just drop in the same folder as the project. On the home page of the system after boot set the TX/RX lines for the uc (prop with tachyon loaded) to swapped, 13, 15 and hook them up to 30, 31 on the prop.
I'm using MacTerm to telnet at 115200, for some reason the standard telnet client in OSX was causing the prop to reset on connect, MacTerm works absolutely great so far.
Have fun
I have only used NodeMCU / Lua so far to write little applications.
So you are using a predefined SW which just acts as a HTTP / Telnet?? to Serial Gateway ?
EDIT: thanks, read the documentation - looks nice ...
My idea was to implement the ppnet on ESP8266/NodeMCU/Lua to use the ESPs as additional sensor / actor nodes in a Tachyon-ppnet ...
Complete source is in just plain C (
I've been using the PING sensor and found it would sometimes lock up. This seems to be due to the PING definition in EXTEND.FTH which generates the trigger pulse:
DUP HIGH >R R> LOW --- 10us trigger (dummy cycles)
On my (96 MHz) prop:
LAP >R R> LAP .LAP 1.833us ok
so perhaps the definition should be changed to:
DUP HIGH 10 us LOW --- 10us trigger pulse
Hi,
You are only measuring the push and pop instructions onto the R stack and not the DUP, HIGH, LOW and original pin number being pushed onto the stack to begin with.
Post up your code so we can help if there is another "problem" to find.
on my 96MHz prop:
0 LAP >R R> LOW LAP .LAP 3.166us ok
The code is just what's in Peter's Introduction and in the latest EXTEND.FTH
PING sometimes locked up with it as written - because it's waiting for a 'Echo' from the sensor but the sensor never sends one because it missed the too-short 'Trig'. Once I replaced the >R R> with 10 us it's working fine. I suppose I could put multiple >R R> instructions in until LAP times it at 10us or more - but it's better to have a solution that will work regardless of the prop clock speed (within reason).
with all the speedups Peter implemented recently (and maybe in the future)
the is definitely the save way to go.
I used the old code in V2.7 and it worked OK
DUP HIGH 10 us LOW will be slightly over 10us but as HIGH or LOW take 3us in V4 because they are coded in high level but OUTSET and OUTCLR and much faster if you need precise control.
I've updated EXTEND with this line in PING which I will check should deliver a 10.5us pulse.
In fact if you time a single I/O operation plus the delay this will give you a better idea of the width of the pulse. In V4 I can do this:
it definitely worked fine :-) !!
and in this case the timing does not need to be exact anyhow - just loooong enough.
I guessed it was the speed improvements made in updates to TACHYON that had 'broken' PING. Main reasons I posted were: 1) To make sure I wasn't doing something stupid, and 2) If I wasn't doing something stupid then it's a good idea to update the Introduction document so that newbies like me don't hit a hurdle really early on causing them to give up on TACHYON!
If we all gave up whenever we hit hurdles we would do the same with other hurdles. Anything worthwhile is worthwhile doing. I figure if I've made all this effort to come this far I'm certainly not going to let it go to waste but make it count.
Know that if you persevere with this path then it will certainly be very rewarding and well worth the effort. You will be able to do simple things with ease, and you will be able to do complicated things with ease also. But like spoken languages you must learn to think in that language to become fluent rather than translating and comparing which will only hinder you.
Talking about PING, I was thinking the other day that rather than calling my ping-pong network PPNET, which doesn't sound that good when spoken
"give me a PING ... just one PING ..."
Ramius in 'Hunt for red october' ...
does it ring ??
My mother sang to me
It's a little muddled after all these years
since I was ninety three
"Ping pong iddle I po"
Please let me know if there is anything I can do to improve the Intro pages. There are some things I take for granted but I try to keep it simple.
as some of you remember I'm currently fighting with a tachyon parallel lcd graphics driver for the LameStation.
I have the simple exercise of setting some bits in a long variable and it costs me much time to figure it out.
I made a register with maybe the following value Later I want to manipulate maybe the upper two bits (but it could differ) How do I solve this (efficiently) in FORTH? In C I would use a bit array.
BTW I feel sick and maybe my brain isn't fully working (if the solution is too silly).
I looked in the introduction and glossary but didn't find it - this could be a hint to add a bit manipulation paragraph to the introduction.
Thanks in advance,
proplem
There is a clear and set operation in Tachyon but it is currently used for bytes, not longs. You could create the long equivalent:
But of course you could use the byte set and clear easily by referring to the offset of the variable, that is lcd+1. So to write to certain bits the idea is that you clear all the relevant bits and then set them with the data that you want. Writing directly to the byte in the long though is easier than trying to apply a mask.
However I think you don't need these operations, the LCD driver is probably simpler than you think. I could write one "blind" in the sense that I can't try it out but you could try it out and debug and tweak it if you like.
@Peter ... sure you can do it blind ;-) ...
happened with me a few times in the past as well ...
I ask here some thing I don't understand fully ..
and when I check back Peter provided the full blown solution
so maybe give @Problem a little bit of a chance to develop it himself ;-)
@Proplem
as for the bit in long ...
to me sounds overcomplicating things.
I don't think this will even be required to drive this little LCD.
If you align the 8 data bits at a byte border 0..7, 8..15, 16..23 ...
then there are only a few control lines to manipulate
define a mask for each control pin
9 MASK == yxPin
then later
yxPin OUTSET ... yxPin OUTCLR ...
or a bit slower, but really nice to read
9 == xyPin
xyPin HIGH .... .... xyPin LOW ...
my lamestation graphics driver is growing to a huge project. But it is in a state where nobody else can help - everything is already lying in front of me but the puzzle doesn't want to fit together. Grrrr. "No effort, no joy." I fully agree with this but sometimes ...
A friend told me: "The way is going from dilletantic, to complicated to simplicity." I hope I'm advancing to the complicated phase, but still no joy.
Nevertheless I'm looking forward when it's working. Good night,
proplem(s) :-))
despairing, proplem
Don't read the assembly language driver and you won't despair. As I keep saying, these two words will allow you to interact with the hardware, the datasheet is useful as a guide but the interaction will confirm what it actually does. For example when you write data and the Y pointer increments you should be able to see it happening. Looking at the basic functions which I have shortened to DAT and CMD you can try these few things.
I've just checked the lamestation schematics and RC2 seems to have D0..D7 on P2..P9, so I will make adjustments here. Is that the version you have?
Using these functions after you have defined the pins *rs *E
--- Output a byte of data to the LCD pri DAT ( ch -- ) *rs HIGH pri WRLCD ( data -- ) --- shift data left two bits to P2..P9 2* 2* --- write data (set after clear) $3FC OUTCLR OUTSET --- pulse chip enable *E HIGH *E LOW ; --- Output a byte to the LCD as an instruction pri CMD ( cmd -- ) *rs LOW WRLCD ;try this interactively - one line at a time as if you are typing them in.
edit - just found a link discussing the geometry of the LCD - how the pixels are arranged and addressed. Typical datasheets from this region are absolute rubbish and the design of the controller is the same.
that's what I wasn't able to do myself. Some pixels are switching on and off.
I don't know what I can say.
The journey to shake your hands would last about 23:10 hours and would be very expensive. So I just can write: thank you, you extaordinary person from the other side of the planet.
hooray!!! This is fun again. LCDITER to write any byte to the display within minutes, and LCDCLS clears the screen.
I want to implement some simple drawing methods PLOT, LINE, CIRCLE or make them usable if you already wrote some before. Any tips which way I should go?
Thanks,
proplem
Yay!
Looking at that information from that site seems to indicate that the not only do you have to deal with pages but you also have to decide which of the two LCD controllers to access via CS1 and CS2 that the pixels appear on. I would therefore dedicate a buffer to do all your drawing in, nice and simple but then have the screen updater picks out the pixels in the correct order to display it.
You can have a look in extras and besides the various LCD drivers, some that write directly to the LCD etc, you will find VGA.FTH which of course writes to a buffer. So first however I would write the convoluted algorithm that reads the buffer in a linear XY fashion and works out how to write that to the screen.
Eight pages of 64 bytes where each byte is represented as a vertical column but the next byte writes to the right of that via the "Y" counter (they don't even know X from Y axis). The other 64 pixels on the right hand side are via CS2 in the second controller chip inside the same kludgy chip.
Funny thing is I have use similar displays but based on ST7920 controller and it is very easy to draw directly to the screen, but as I said I feel that having a 128bitx64bit buffer and updating the display from that might be easier.