I had rather supposed that doing circles parametrically would automatically create closed circles, and it does.
Here's the code for my initial trial. I haven't generalized it yet, nor worked in the rounding and optimization for speed, but the results are very good. This demo simply prints a single, centered circle of radius 20. I'm using sine and cosine values to two decimal places.
See what you think. It runs on the simulator and the real LCD nicely.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-04-16
Okay, things are coming along. I worked in the rounding now, and some error detection to keep within the bounds of the screen, and have also made a filled circle command. See the attached figure.
I tried to run your software (the second post) but it would not compile. It gave me two "Else outside End If block" errors and two "End If without If" errors. I traced this to the 'function ref" section. Since I couldn't find anything wrong with the code I removed the "ELSEs" and then it compiled.
I may have made some mistakes by removing these else statments because all I got on my display was a bunch of horizontal lines.
Any ideas?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
table sineTab store data
Should be:
table sineTab 'store data
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-04-17
MBB, unless I did something funny with cut and paste, I can't understand why it doesn't compile for you. Just to make sure, I've attached the program here. And I tested it again just now, and it compiles and runs for me.
Kent, that won't hurt anything to comment out "store data" option, but by leaving it in, the table goes to EEPROM. Commenting it out puts the table in program memory.
Thomas, I was having a similar problem to what MBB had, only I got some random pixels.
My bad on the store data command, hadn't used that before. But "as is" code for me, the compile went O.K. sorta, as PicKit2 complained about the hex file being too big for my 16f1783, which shouldn't be the case. Commented out the "store data", thinking it was in need of commenting (hah), and all good for PicKit2. Output got some semblance of circles, but experiencing detached arcs of approx. 45 degrees.
I'm using Steini's GCB SYNWrite, with 0.9 22/9/2013. What are you using?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-04-17
I'm using 0.9 17/02/2014, which I think is the version in the Hot Release package.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried your GLCD.gcb post but I still couldn't compile it.
I'm using version 1.0 21/9/2013.
Something else I had a problem with is this line in your program:
chip 16F88, 8 ;PIC16F88 running at 8 MHz
I get a Microsoft.NET Framework unhandled exception saying
Conversion from string "8 ;PIC1F88 run" to type Double is
not valid
If I delete the comment so I have only: #chip 16F88, 8
then GCB can open the file. This makes no sense.
I had the same problem when I downloaded your Sine program.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-04-18
Hey guys,
I'm sorry to learn that this is causing you grief. I just got a real GLCD and tried it. It sure works for me. (See the attached pic). It really does sound like it's a GCB Version problem. I think Anobium manages to keep the versions straight; maybe he'll weigh in with a comment. Wasn't there a problem with integer arithmetic previously?
I've attached the code I used for the picture. It's very short and sweet, since it now calls upon the trig include file I've described in another thread. And I added some explanatory comments. I'm not sure who is maintaining the GLCD include file, but maybe this would be suitable for inclusion (circle and filled circle commands).
Since MBB seems to be having a PC related problem, I'll mention that I've done this on two separate laptops, both XP, and using both MPASM and GCASM.
I'll be working on some diagonal line and triangle commands next.
I have watching.... and reading with interest. Well done. This is excellent work. I will just tried on the new GCLD code - compiles with no issues.
Then, I tried on the Simulator.... no issues. Worked as expected.
Then, the I tried on the new ST7920 GLCD driver code.... no issues. EXCELLENT!!
Great job. (I am please too... this is the first piece of external code to be tested on the ST7920 uber cheapo GLCD device...! It was £4.00 GBP)
My thoughts on the @MBB issues. The release from Sept 13 did have some stack issues where the stack was not handled correctly. I would advise using the Hot Release. Just backup you existing config. FYI: When I was using the Sept 13 release I was getting very odd results during runtime (when the Pic is running) with stack errors - this would show up as corruption on.... the LCD......
I want to apologize to everyone for reporting some problems which were of my own doing. I'm going to sit in the corner with the dunce cap one.
When I moved the GLCD data lines over to PortC, so as not to conflict with programming, I had crossed two adjacent data wires, no wonder I was seeing goofy results.
I did upgrade to the newest Hot release, but may not have made any difference.
I had rather supposed that doing circles parametrically would automatically create closed circles, and it does.
Here's the code for my initial trial. I haven't generalized it yet, nor worked in the rounding and optimization for speed, but the results are very good. This demo simply prints a single, centered circle of radius 20. I'm using sine and cosine values to two decimal places.
See what you think. It runs on the simulator and the real LCD nicely.
Oh, here's a pic.
Okay, things are coming along. I worked in the rounding now, and some error detection to keep within the bounds of the screen, and have also made a filled circle command. See the attached figure.
Thomas,
I tried to run your software (the second post) but it would not compile. It gave me two "Else outside End If block" errors and two "End If without If" errors. I traced this to the 'function ref" section. Since I couldn't find anything wrong with the code I removed the "ELSEs" and then it compiled.
I may have made some mistakes by removing these else statments because all I got on my display was a bunch of horizontal lines.
Any ideas?
Check this line for the Table:
MBB, unless I did something funny with cut and paste, I can't understand why it doesn't compile for you. Just to make sure, I've attached the program here. And I tested it again just now, and it compiles and runs for me.
Kent, that won't hurt anything to comment out "store data" option, but by leaving it in, the table goes to EEPROM. Commenting it out puts the table in program memory.
Thomas, I was having a similar problem to what MBB had, only I got some random pixels.
My bad on the store data command, hadn't used that before. But "as is" code for me, the compile went O.K. sorta, as PicKit2 complained about the hex file being too big for my 16f1783, which shouldn't be the case. Commented out the "store data", thinking it was in need of commenting (hah), and all good for PicKit2. Output got some semblance of circles, but experiencing detached arcs of approx. 45 degrees.
I'm using Steini's GCB SYNWrite, with 0.9 22/9/2013. What are you using?
I'm using 0.9 17/02/2014, which I think is the version in the Hot Release package.
I tried your GLCD.gcb post but I still couldn't compile it.
I'm using version 1.0 21/9/2013.
Something else I had a problem with is this line in your program:
chip 16F88, 8 ;PIC16F88 running at 8 MHz
I get a Microsoft.NET Framework unhandled exception saying
Conversion from string "8 ;PIC1F88 run" to type Double is
not valid
If I delete the comment so I have only: #chip 16F88, 8
then GCB can open the file. This makes no sense.
I had the same problem when I downloaded your Sine program.
Hey guys,
I'm sorry to learn that this is causing you grief. I just got a real GLCD and tried it. It sure works for me. (See the attached pic). It really does sound like it's a GCB Version problem. I think Anobium manages to keep the versions straight; maybe he'll weigh in with a comment. Wasn't there a problem with integer arithmetic previously?
I've attached the code I used for the picture. It's very short and sweet, since it now calls upon the trig include file I've described in another thread. And I added some explanatory comments. I'm not sure who is maintaining the GLCD include file, but maybe this would be suitable for inclusion (circle and filled circle commands).
Since MBB seems to be having a PC related problem, I'll mention that I've done this on two separate laptops, both XP, and using both MPASM and GCASM.
I'll be working on some diagonal line and triangle commands next.
I have watching.... and reading with interest. Well done. This is excellent work. I will just tried on the new GCLD code - compiles with no issues.
Then, I tried on the Simulator.... no issues. Worked as expected.
Then, the I tried on the new ST7920 GLCD driver code.... no issues. EXCELLENT!!
Great job. (I am please too... this is the first piece of external code to be tested on the ST7920 uber cheapo GLCD device...! It was £4.00 GBP)
My thoughts on the @MBB issues. The release from Sept 13 did have some stack issues where the stack was not handled correctly. I would advise using the Hot Release. Just backup you existing config. FYI: When I was using the Sept 13 release I was getting very odd results during runtime (when the Pic is running) with stack errors - this would show up as corruption on.... the LCD......
I want to apologize to everyone for reporting some problems which were of my own doing. I'm going to sit in the corner with the dunce cap one.
When I moved the GLCD data lines over to PortC, so as not to conflict with programming, I had crossed two adjacent data wires, no wonder I was seeing goofy results.
I did upgrade to the newest Hot release, but may not have made any difference.
With the AGM1264F: