Activity for GCBASIC
-
Anobium posted a comment on discussion Help
I am not aware of any BASCOM functional comparisons. Enjoy. Not all fixes are so fast. I get very busy on other projects. :-)
-
miniTesla posted a comment on discussion Help
I am happy this got fixed so fast. I have only started to work with GCBASIC. I have used BASCOM (another BASIC compiler for AVRs) in the past but am thinking to migrate my work to GCBASIC. Has anybody done some benchmarking against BASCOM to evaluate which one optimizes better? I do most of my programming on smaller AVRs which often means optimizing code to fit it into flash.
-
And, look... Program Memory 57words.. 114 bytes. It is reporting the correct values now! Your good catch!! Evan GCBASIC (2026.04.27 (Windows 64 bit) : Build 1574) Compiling: blinker_minimal.gcb Program compiled successfully (Compile time: 1.5 seconds) Summary: Compiled: Program lines: 6 Subroutines: User: 0 ; System: 2 of 485 ; Total: 2 Chip resource usage: Program Memory: 57/4096 words (1.39%) RAM: 0/512 bytes (0%) OSC: 1Mhz Assembling program using GCASM Program assembled successfully (Assembly...
-
Good catch!
-
New:Change Preferences Editor position and movement controls.
-
New: Improved program calculation size via RecalcSubSizes(), and change variable types to prevent overflow.
-
I did spot another issue... I took the blinker_mininal.gcb soruce and made it big, ( copied and copied) until the compiler said it would not fit the Program Memory... then, i deleted enough to make it compiler. When I loaded into AVRDude... it was not 99.99% !! The Problem On AVR targets, the compiler's reported Program Memory usage was significantly higher than the actual flash consumed. For example, compiling for an ATtiny841 (4096 words): Program Memory: 4026/4096 words (98.29%) ← compiler (wrong)...
-
Hello, Can you share more information? Operating system? Screenshots? Code. Thanks
-
charles silva posted a comment on discussion Open Discussion
dir port b frankfurt or anything we write ; compile and is everything ok without errors. the colors when the compiler finish the job does not show up ,and the debugger is off something is missing .....an extension
-
Roger Jönsson posted a comment on discussion Help
Yes, excellent!
-
Excellent. I will commit to the release. There will be a release very soon that will include these changes. There may/will be other issues like this. We can change the toolchain, I just need the time to do it. :-)
-
Perfect. There should now be no question anymore if the program fits into flash or not.
-
How about ? GCBASIC (2026.04.26 (Windows 64 bit) : Build 1573) Compiling: blinker_minimal.gcb Program compiled successfully (Compile time: 1.5 seconds) Summary: Compiled: Program lines: 6 Subroutines: User: 0 ; System: 2 of 485 ; Total: 2 Chip resource usage: Program Memory: 36/4096 words (.88%) RAM: 0/512 bytes (0%) OSC: 1Mhz Assembling program using GCASM Program assembled successfully (Assembly time: 0 seconds) Code Segment: 64/4096 words (1.56%) Done
-
I would write 64/4096 to show the limit, too, but that is a minor point. The key is to know if one has run out of flash memory or not, and your change makes it clear.
-
Great. Check the properties of the application..are they set to maximise on open. But, all good changes.
-
Thanks. That fixed it. While the window still opens maximized, the OK and Cancel buttons are visible and I can un-maximize the window, too.
-
This is what I recommend. This is real and not a mock up. Note the hex allocation comes from GCASM or AVRASM2, so this ( correctly ) is shown in the GCASM section. And, if using AVRASM2 then there will be nothing shown as this information in the LST file produced by AVRASM2. This shows the real extent of the progmem used. Evan GCBASIC (2026.04.23 (Windows 64 bit) : Build 1573) Compiling: blinker_minimal.gcb Program compiled successfully (Compile time: 1.5 seconds) Summary: Compiled: Program lines:...
-
This is what I recommend. This is real and not a mock up. Note the hex allocation comes from GCASM or AVRASM2, so this ( correctly ) is shown in the GCASM section. And, if using AVRASM2 then there will be nothing shown as this information in the LST file produced by AVRASM2. This shows the real extent of the progmem used. Evan GCBASIC (2026.04.23 (Windows 64 bit) : Build 1571) Compiling: blinker_minimal.gcb Program compiled successfully (Compile time: 1.5 seconds) Summary: Compiled: Program lines:...
-
Before I made any changes. I changed the Assember from GCASM to AVR2ASM ( you easily do the same ). It reports the memory usages as 114 bytes - which is correct based on my previous analysis. "ATtiny841" memory use summary [bytes]: Segment Begin End Code Data Used Size Use% .cseg 0x000000 0x000080 114 0 114 8192 1.4% This show the information is a clear way. Does this help the best way to show?
-
Please download and replace the existing Programmer Editor.exe from https://1drv.ms/u/c/2f87ffe77f3dbec7/IQCjuayRtj9LQZ6GrN5HcTIZAcyIs8u9GfUB8vRGB-L4cHc?e=uZAA5U Hopefully, this resolves. Here's the changelog document. It covers all 14 changes made from v4.01 to v4.02 File header & version number Form border, resize and window control behaviour DPI/4K scaling fix MinimumSize recalculation for Add/Edit/Delete visibility OK & Cancel button centring New Reset Size button and its click handler
-
I will have a look tomorrow to see how to resolve. There is max/min on this application. Hugh never implemented those functions. I am not sure how to resolve but I will try. :-)
-
I agree. It would be a good thing if reported back how much memory will be used by the program in the chip. In this case 128 bytes. If I look at the Program Memory figures, I do it to get an estimate on how much memory is still available. I learned by observing that it is what is presented, plus "some more" :) .
-
I think it is better to report 128 bytes (or 64 words) because that is the number that matters. Or report both. It doesn't have to be an either or. But the way it is reported right now is highly misleading because it not only states 36 words but 36 out of 4096 by writing "36/4096 words" suggesting that it could fit 4096 into the chip. However, that would be wrong, because that is not all the space required. It would therefore be much better in my opinion to report 64/4096 so that one knows how much...
-
Resolution is 3840 x 2160. Screenshot is attached.
-
Never seen this. Got a screen shot? What is your screen resolution?
-
I am failing to get the point across. The reported 72 is real. 114 is incorrect. So, if the compiler reported 128 ( the true full extent of the program in the chip ) is this better? I remember this same discussion with Hugh when I discovered this disparity. The result was that we changed nothing. We should discuss to sort this time around.
-
I have just installed GCSTUDIO on Windows 11. When I open the program, and click on the wrench symbol to get into settings and then click on "Edit Programmer Preferences" the window I get is maximized without a way to make it smaller. The main problem is that this hides the save button. So I can't make any changes and save them.
-
GCSTUDIO is "Generating machine code ..." which is saved in the HEX file. That is the data that actually gets loaded into the flash memory. Couldn't it at that point report how much actual flash memory has been used by simply looking at the HEX file? My point is, how would one know if whatever code one has generated for the chip goes beyond what is available?
-
The issue is in the programming software. Just to clarify the apparent discrepancy — GCBASIC is actually reporting correctly. It reports 36 words, which is the number of instruction words it actually assembled. The programming software is showing 114 bytes, which is the byte-addressed span of the Intel HEX file from the first to the last record, minus the 7 unpopulated interrupt vector slots in the ATtiny841 vector table that GCBASIC correctly leaves out of the HEX file. The maths in the programmer:...
-
Thanks for the explanation. So the actual flash memory used on the chip is 128 bytes. First the interrupt vector table and then the program code. If that is so, wouldn't it make sense to also report the total, meaning 128 bytes, so that one knows if one has exhausted the available flash memory?
-
Hello, The difference is the code that is generated verses the code in the hex when loaded into a programmer. The LST generated shows what is happening. There is a vector at 0x0000 There are a series of vectors There is your program. Summary What Count Why Assembler "words of hex" 36 words Only the instructions actually emitted Byte equivalent of those 36 words 72 bytes 36 × 2 Programmer "bytes loaded" 114 bytes Byte-addressed span including gaps in the vector table region The short version: the...
-
I am compiling a simple blinking LED on PORTA.5 code for a tiny841 chip. The compiler states: Program Memory: 36/4096 words If I understand this correctly, this means 72 bytes used of the flash memory. However, when I look at the HEX file, I see data for 114 bytes. They are not consecutive either. With the gaps added it uses 128 bytes. (GCB and HEX files are attached if anybody wants to take a look.) What am I misunderstanding?
-
I just wrote a word into a pre erased memory block in Program Memory: Reading it back with Pickit+ confirms it worked. The program is based on the example in the 18FXXQ84 manual. Since the memory block is not erased for every word there is less wear on the memory when not writing complete blocks. One needs to handle the fact that you can not write to a memory cell more than once, without erasing the whole memory block. For quick sampling, this should work at 10kHz or so with no erases being done...
-
I just wrote a word into a pre erased memory block in Program Memory: Reading it back with Pickit+ confirms it worked. The program is based on the example in the 18FXXQ84 manual. Since the memory block is not erased for every word there is less wear on the memory when not writing complete blocks. One needs to handle the fact that you can not write to a memory cell more than once, without erasing the whole memory block. For quick sampling, this should work at 10kHz or so with no erases being done...
-
I just wrote a word into a pre erased memory block in Program Memory: Reading it back with Pickit+ confirms it worked. The program is based on the example in the 18FXXQ84 manual. Since the memory block is not erased for every word there is less wear on the memory when not writing complete blocks. One needs to handle the fact that you can not write to a memory cell more than once, without erasing the whole memory block. For quick sampling, this should work at 10kHz or so with no erases being done...
-
I just wrote a word into a pre erased memory block in Program Memory: Reading it back with Pickit+ confirms it worked. The program is based on the example in the 18FXXQ84 manual. Since the memory block is not erased for every word there is less wear on the memory when not writing complete blocks. One needs to handle the fact that you can not write to a memory cell more than once, without erasing the whole memory block. For quick sampling, this should work at 10kHz or so with no erases being done...
-
I just wrote a word into a pre erased memory block in Program Memory: Reading it back with Pickit+ confirms it worked. The program is based on the example in the 18FXXQ84 manual. Since the memory block is not erased for every word there is less wear on the memory when not writing complete blocks. One needs to handle the fact that you can not write to a memory cell more than once, without erasing the whole memory block. For quick sampling, this should work at 10kHz or so with no erases being done...
-
I just wrote a word into a pre erased memory block in Program Memory: Reading it back with Pickit+ confirms it worked. The program is based on the example in the 18FXXQ84 manual. Since the memory block is not erased for every word there is less wear on the memory when not writing complete blocks. One needs to handle the fact that you can not write to a memory cell more than once, without erasing the whole memory block. For quick sampling, this should work at 10kHz or so with no erases being done...
-
I just wrote a word into a pre erased memory block in Program Memory: Reading it back with Pickit+ confirms it worked. The program is based on the example in the 18FXXQ84 manual. Since the memory block is not erased for every word there is less wear on the memory when not writing complete blocks. One needs to handle the fact that you can not write to a memory cell more than once, without erasing the whole memory block. For quick sampling, this should work at 10kHz or so with no erases being done...
-
I just wrote a word into a pre erased memory block in Program Memory: Reading it back with Pickit+ confirms it worked. The program is based on the example in the 18FXXQ84 manual. Since the memory block is not erased for every word there is less wear on the memory when not writing complete blocks. One needs to handle the fact that you can not write to a memory cell more than once, without erasing the whole memory block. For quick sampling, this should work at 10kHz or so with no erases being done...
-
Thank you for the info. Maybe there are safety margins and tolerances. If this right on the edge rasing the voltage slightly shouldn't be a too difficult adaptation.
-
c-conversion posted a comment on discussion Open Discussion
I'm back on this today. I have to say that using the MC14562 as the capture and storage device is working on first test. I have wired the original data in to the data in on the 14562. The original clock is wired to the clock in of the 14562 through a diode mixer. The original ChipSelect is connected to a 12F1840. The 12F1840 waits for the ChipSelect input to go high, indicating end of transmission from the host. At that point, following a delay, the 12F1840 lowers a pin which is wired to the display...
-
These microcontrollers are supported by GCBASIC compliler. Microchip PIC-AS ( as of version 3.10 ) do not support. The microcontrollers will require validation in terms of all the capabilities but the basic complilation process is supported.
-
New microcontrollers added!! PIC16F (13276 family) 16f13276 16f13275 16f13256 16f13255 16f13254 PIC18F (Q35 family) 18f56q35 18f55q35 18f54q35 18f46q35 18f45q35 18f44q35 18f26q35 18f25q35 18f24q35
-
New microcontrollers added!! PIC16F (13276 family) 16f13276 16f13275 16f13256 16f13255 16f13254 PIC18F (Q35 family) 18f56q35 18f55q35 18f54q35 18f46q35 18f45q35 18f44q35 18f26q35 18f25q35 18f24q35
-
I had a weak memory about Word Write and found it mentioned in the manual for PIC18F27/47/57Q84 (DS40002213D-page 105) 10.3.5 Word Write PFM can be written one word at a time to a pre-erased memory location. Example 10-6. Writing a Word of Program Flash Memory Maybe I will test later and see if I can make it tick. Likely way over my capabilities. :) I get that it is not supported in GCbasic and I am perfectly fine with that.
-
So now I measured program memory block write speed on an 18F27Q84, 64: Running 100x _PFMwriteBlock takes 1,8s =18ms on average for blocks of 256bytes. Filling the buffer + _PFMwriteBlock takes about the same time :18.5ms on average for a block.
-
You have to write a block. That is the only method.
-
Or is PFM writing single words not even possible in hardware?
-
Asm would be required writing single words without block operations and erase for every word?
-
And, no ASM. To write this in ASM would take weeks, months. There are very very few cases where ASM is the answer in GCBASIC. With that said, there will be some edge cases where i would recommend/approve.
-
Aha. So the bytes that I recognised as remaining from last program, was still in the buffer and got written again. Ahh! That makes sense. No problem as I intend to always fill the buffer. This is great! :)
-
Using your methid.You would need to clear the buffer tyuningYou would need to clear the buffer to ensure it was at a known value. The buffer ram will be random values.
-
At first this was very over whealming- Then after a good while, nah it can't be, hm... no ..., but what if? -Wow! So in my case I only need to send my bytes to the _PFM_Buffer() then to use _PFMwriteBlock. Since I am not interested in what was in the program memory block before, I could skip reading and modifying and I ended up with this: #CHIP 18F27Q84, 64 #OPTION Explicit DIM AAA as byte = 0 Dim _PFM_Buffer(256) //18F27Q84 block size=256 //Fill buffer Repeat 256 _PFM_Buffer(AAA+1)=AAA //saves byte...
-
Take this sub from system.h and adapt. Sub PFMWrite (in _PFM_ADDR as long , in _PFM_DataWord as Word ) //~ Tested on 18F16Q41;q43 Dim _PFM_BlockNum, _PFM_Offset as long Dim _PFM_Buffer(SAF_ROWSIZE_BYTES) //~ Writes a Word of data [_PFM_PFM_DataOut] //~ at relative location [_PFM_Address] between 0 and extent of page //~ //~ The existing data in the row of [_PFM_Address] is preserved ; Calculate block number _PFM_BlockNum = _PFM_ADDR / SAF_ROWSIZE_BYTES ; Calculate offset in block/row _PFM_Offset...
-
I meant, make the calculation for a block's size and then transfer and write the full block (128 words) to program memory in one go. How do I fill the buffer without asm? And then when I have filled the buffer how do I write it to program memory, without asm?
-
That would be a strange approach. Why not update the buffer directly and write the buffer? No need for Asm.
-
Very weird. From no need for delay (added looptime is us) for 10-20 words, then the need for 30-50ms delay after that. I do accept that it is the reality of the unknown territory, but still. To get some speed I would probably have to dig into assembler and transfer whole blocks via RAM. GC basic has no routines for that, right? In many cases PFMWrite is fine and easy to use, but I'm also looking at transferring around 64kB in one go and then it will be very slow to write word by word to program ...
-
There is nothing that impacts the operation apart all the internal operations of the microcontroller which we have no knowledge of. You could check the datasheet for a register.bit the indicated that everything is settled/complete with previous NVCON operations. We would not check this in a library as this would be a blocking operation ( where there was no way out of the register.bit inspection). As an expert on writing to Progmem. This is all about timing. My guess is that your current delays are...
-
Why can I write 20 words without adding any delay? Is there some buffer involved than makes the compiler making different decisions for how to handle the blocks or is this how the hardware just works? Finding the delay time needed, is about trial and error (with the rest of the code used)?
-
Adding a 50ms wait after each PFMWrite it seems to work 10ms is not always enough. I sometimes get fewer words back, sometimes none. Pickit+ runs the program at every read, so probably writing is not always complete. So, PFMWrite (and all the related calls) do not have any delays ( wait ) to keep the code as fast as practical. You would need to handle if you are writing back to block at speed.
-
Makes sense. The read block, update word, write block has an execution time ( the write block specifically). We have the same issue when write via the PICKit+ software - the intrablock write is very critical.
-
Adding a 50ms wait after each PFMWrite it seems to work 10ms is not always enough. I sometimes get fewer words back, sometimes none. Pickit+ runs the program at every read, so probably writing is not always complete.
-
As far as I understand, block start addresses for 18F27Q84 is 0x100, 0x200 etc? If I do the below, Pickit+ reads it back ok with Repeat 10 and Repeat 20. If I increase to Repeat 30, then it sometimes returns just a few of these and if I read back again (without writing), sometimes a few more AAAA or nothing, with further reads I tend to get all FFFF FFFF FFFF FFFF (no trace of the words I intended to write) and no more AAAA.... If I decrease to Repeat 20 it again returns 20 words. Any idea what is...
-
I tried programwrite without effect, so for the 18F27Q84 I guess that PFMwrite is the right way. #CHIP 18F27Q84, 64 #OPTION Explicit //Write to Program Flash Memory PFMWrite (0x600,0) //block start adresses if unused: 0x100, 0x200 0x300 etc (page size 128 Words) PFMWrite (0x602,0xA) PFMWrite (0x604,0xAB) PFMWrite (0x606,0xABC) PFMWrite (0x608,0xABCD) Reading the program memory back with Pickkit+ I see: 00600 FF00 FF0A FFAB 0ABC ABCD Is this a correct? Should I clear the high bytes manually for small,...
-
Correct.
-
Sorry. I scratched my head a good while, then right after posting... Ofcourse: PFMWrite (0x600,[word]0)
-
I tried programwrite without effect, so for the 18F27Q84 I guess that PFMwrite is the right way. #CHIP 18F27Q84, 64 #OPTION Explicit //Write to Program Flash Memory PFMWrite (0x600,0) //legal addresses if available: 0x100, 0x200 0x300 etc (page size 128 Words) PFMWrite (0x602,0xA) PFMWrite (0x604,0xAB) PFMWrite (0x606,0xABC) PFMWrite (0x608,0xABCD) Reading the program memory back with Pickkit+ I see: 00600 FF00 FF0A FFAB 0ABC ABCD Is this a correct? Should I clear the high bytes manually for small,...
-
I tried programwrite without effec,t so for the 18F27Q84 I guess that PFMwrite is the right way. #CHIP 18F27Q84, 64 #OPTION Explicit //Write to Program Flash Memory PFMWrite (0x600,0) //legal addresses if available: 0x100, 0x200 0x300 etc (page size 128 Words) PFMWrite (0x602,0xA) PFMWrite (0x604,0xAB) PFMWrite (0x606,0xABC) PFMWrite (0x608,0xABCD) Reading the program memory back with Pickkit+ I see: 00600 FF00 FF0A FFAB 0ABC ABCD Is this a correct? Should I clear the high bytes manually for small,...
-
This would make sense. You do need to keep tight change/release control of you setup if I give you 'out of release process' fixes. I should have made this a lot clearer,
-
I found Build 1569 in my waste bin and replaced. Now the numbers come out ok in the HEX. So, yes it was the recent auto update that reintroduced old build with the bug. I may now have the timer0+Timer2 cooperation busted again. I will check that later.
-
When you fixed this bug two months ago it was about GCASM not working perfectly with the next stage toward HEX(?). Something about text formattig or something like that. You were not using GCASM in your end so you did not at first understand how I could have the problem that problem I had. Something like that. I don't remember 100%.
-
Ahh. The autoupdate returned bug that you killed? I now have build 1523, reading above it was resolved on build 1568. The asm shows the numbers as I would have expected them to. ; Number of items 15 dw 0x0000, 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 0x0006, 0x0007, 0x0008, 0x0009, 0x000A, 0x0200, 0x0201, 0x0202, 0x0203 ; End of DATA_BLOCK END
-
There is no trick. But, what does the ASM show?
-
Out of curiosity I made a test program, then examined the compiled hex with Pickit+. #CHIP 18F27Q84, 64 #OPTION Explicit Data TEST as word 0,1,2,3,4,5,6,7,8,9,10,512,513,514,515 //0x0000, 0x0001, 0x0002, 0x0003, 0x000A, 0x0200 End data The complied hex in Pickit+: ... 0100 0302 0504 0706 0908 2000 0201 0202 0203 ... -What happens with data ...10 , 512... How does it become hex 2000? -How does the microprocessor know if the data is a byte or word ? (small numbers seems to be stored using bytes, larger...
-
I will move these to the release. So, the .h will be in the next release. And, your demo will be in the demo pack. Well done.
-
Chris S posted a comment on discussion Contributors
Good morning! Ive copied those files and verified that it does still work. Sleep also works.
-
A bit of tweak by me. You can control the SPI mode and have the library handle it (recommended): The GCBASIC library's HWSPIClockModeSCRIPT will set the appropriate mode. You can override it yourself (if the default doesn't work for your hardware) #define HWSPIClockMode SPI_CPOL_1 + SPI_CPHA_0 ' Force Mode 2, for example Put this your main program. The script in the library will usually respect your define. Then configure SPI normally. #define HWSPIClockMode SPI_CPOL_1 + SPI_CPHA_0 #define HWSPIMode...
-
Updated GLCD_ST7567 adding new power control methods
-
Finally, here is my working demo code for any one else to play with. I cleaned it up as best as I could. The large wait delays are so I can measure current consumption.
-
Final Changes confirmed. I added the following code for the sub routines: For SetLowPower_ST7567 #IFDEF HW4Wire_Data CS_ST7567 = 0 DC_ST7567 = 0 FastHWSPITransfer 0xAE FastHWSPITransfer 0xA5 DC_ST7567 = 1 CS_ST7567 = 1 #ENDIF For ExitLowPower_ST7567 #IFDEF HW4Wire_Data CS_ST7567 = 0 DC_ST7567 = 0 FastHWSPITransfer 0xA4 FastHWSPITransfer 0xAE DC_ST7567 = 1 CS_ST7567 = 1 #ENDIF Finally, since I added in a longer wait, we have a final sleep current of 33uA! (LED OFF). To recap: I dont think all of the...
-
I will gather up and put into the next release. Never want to lose good work. :-)
-
Good! And great news about the low power use. I'm going to order this GLCD. I have some ideas where to insert it into an old project and maybe some new stuff as well. Please upload a GCB file with the changes made when you finished basic testing, it would simplyfy things for me.
-
Thanks for the suggestion. I just tried this code: SPIMode ( MasterFast, SPI_SS_0 + SPI_CPOL_0 + SPI_CPHA_0 ) Removed my cap, unplugged power and plugged it back in, and all seems to be well. Thanks for the suggestion! I now have a counter counting up such that the display changes a bit and isnt static.
-
That is odd. If the caps resolve then OK. A thought. Check the datasheet for anything that controls the SPI signal.
-
Would chainging Clock polarity (CPOL) and/or clock phase (CPHA) help (without delaing the clock signal with a capacitor)?
-
So before I left (have a little bit of my lunch left) I forgot I let my scope hooked up. Well, as it turns out, that makes a difference! When I removed my scope, the display wouldnt work. I noticed that the clock edges were all nice and sharp, which is what we would want. I even slowed SPI down by using "MasterSlow". Im not sure why I chose to do this, but I had a feeling those sharp edges might be whats causing issues. Currently, I have 2nF (1nF x two in parallel) worth of capacitance on just the...
-
Yes. Good stuff.
-
So I was on the right track of thinking, since I had gone through the other working GLCDs that use SPI and found that tid bit. I just had it in the wrong spot :). Thanks for the help, I knew it was something I couldnt see. Will update with the low power code later tonight (Im on EST time).
-
Yes. You had it near the memory allocation which does not need to be within a method.
-
So the code: SPIMode HWSPIMODESCRIPT, 0 On line 308 is all that was needed?
-
Wow. Considering I am just doing this by reading the ASM! Your call was not within a method, so, it was never called. it was hanging in the unprocessed/ignored code.
-
Fantastic. It works. Thanks for the remote developing :D For anyone else reading this: Setting the bias to 9 seems work really well in low light settings. Where was it placed to cause an issue? TO DO: Test the low power function. It should still work but I have to log on for actual work now :)/
-
I missed off! GLCDCLS Line 0,0,10,10
-
The SPIMode was incorrectly placed in the .h, it was never called. Evan Use this code as the baseline, so we have the same code. #chip 18F26Q10,8 #OPTION Explicit // PIC PPS Tool version: 0.0.6.5 #startup InitPPS, 85 #define PPSToolPart 18F26Q10 Sub InitPPS UNLOCKPPS #ifdef HW4Wire_Data SSPDATPPS = 0x14; //RC4->MSSP1:SDI1; RC5PPS = 0x10; //RC5->MSSP1:SDO1; RC6PPS = 0x0F; //RC6->MSSP1:SCK1; SSPCLKPPS = 0x16; //RC6->MSSP1:SCK1; #else SSPDATPPS = 0 RC5PPS = 0 RC6PPS = 0 SSPCLKPPS = 0; //RC6->MSSP1:SCK1;...
-
Hmmm. So If I keep the following code: FastHWSPITransfer 0x75 //test sequnce for spi in my main do loop, it will work with the above code as long as I have HW4WIRE_Data defined. However as soon as I add in GLCDCLS in the line before it, it breaks. I can uncomment glcd.h, and define the LCD type but as soon as I make a call to the LCD, it doesnt seem to initiate the SPI transfer. But if I comment #define HW4Wire_Data out so its not included, it also doesnt work.
-
Remove the HW4Wire_Data constant. You see the signals and the screen works? But, to test change to this. Sub InitPPS UNLOCKPPS ' // Module: MSSP1 ' RC5PPS = 0x0010 // SDO1 > RC5 ' RC6PPS = 0x000F // SCK1 > RC6 ' SSPCLKPPS = 0x0016 // RC6 > SCK1 (bi-directional) #ifdef HW4Wire_Data SSPDATPPS = 0x14; //RC4->MSSP1:SDI1; RC5PPS = 0x10; //RC5->MSSP1:SDO1; RC6PPS = 0x0F; //RC6->MSSP1:SCK1; SSPCLKPPS = 0x16; //RC6->MSSP1:SCK1; #else SSPDATPPS = 0 RC5PPS = 0 RC6PPS = 0 SSPCLKPPS = 0; //RC6->MSSP1:SCK1; #endif...
-
Negative on that. My scope shows no SPI transfer, no clock, no data.
-
You are not calling any GLCD functions. Try this. Dont change TRISC in InitPPS. Let the init routine in the .h sort this - the init must sort this, port by port. Else you will break things. #chip 18F26Q10,8 #OPTION Explicit // PIC PPS Tool version: 0.0.6.5 #startup InitPPS, 85 #define PPSToolPart 18F26Q10 Sub InitPPS UNLOCKPPS SSPDATPPS = 0x14; //RC4->MSSP1:SDI1; RC5PPS = 0x10; //RC5->MSSP1:SDO1; RC6PPS = 0x0F; //RC6->MSSP1:SCK1; SSPCLKPPS = 0x16; //RC6->MSSP1:SCK1; LOCKPPS End Sub ; ----- Define...
-
Hardware Test that has init codes/sequences using HW SPI. Its commented out.
1 >
