Thread: [Flashforth-devel] pic18f66k22
Brought to you by:
oh2aun
Menu
▾
▴
flashforth-devel
|
From: <zd...@al...> - 2016-02-22 17:20:50
|
Hi, everyone,
It was easy to import files to MPLAB, and I expected that after my
hardware was soldered only 1 download to PIC will be enough to start
working in FlashForth. Well, I started programming in Forth in 1984 and
I have 20 years of experience with PICs and shouldn't describe myself as
an begginer, but still I needed almost a week to make FF work.
I'm afraid most people could just give up. That's why I would like to
discuss my problems here and make whole package more user frendly. MPLAB
project has many files included, some of them non existent. Obviously, I
had to include p18f66k22.cfg, but it wasn't clear that I have to exclude
most of files because baud rate calculation didn't work correct.
Apparently it was calculating for 48MHz although in p18f66k22.cfg it was
correct 64MHz.
Finally, I got some "FlashForth" response on my terminal but it was
impossible to work as it didn't accept command line and kept restarting
every couple of seconds. After one day with in-circuit emulator I wasn't
smarter as it didn't behave the same way every time I tried to trace it,
so the next day I conected a beeper and turned it on from different
points in code to see how far it gets. In the end of the second day it
was obvious it is freezing on attempt to write into EEPROM. No wonder,
as EEIF flag is not in PIR2, but PIR6 on 18F66K22.
ECSTORE1:
bcf EECON1, EEPGD, A
bcf EECON1, CFGS, A
bcf PIR2, EEIF, A
bsf EECON1, WREN, A
bcf INTCON, GIE, A
movlw h'55'
movwf EECON2, A
movlw h'aa'
movwf EECON2, A
bsf EECON1, WR, A
bsf INTCON, GIE, A
ECSTORE2:
btfss PIR2, EEIF, A
bra ECSTORE2
bcf EECON1, WREN, A
bcf PIR2, EEIF, A
There are 2 conclusions. First, some important pointers have to be
written into EEPROM before anything starts to work. Second, nobody ever
tried this code on any 65K22, 66K22, 85K22 or 86K22.
Now FF started working, but only until first colon definition and then
everything fell apart. Few more days of reprogramming, reading code,
reprogramming, reading "manual", reprogramming, reading dump, comparing
until I found error in p18f66k22.cfg.
constant flash_write_inner_loop = d'128'
Only 18x7K22 has 128 byte buffer and as a result all attempts to write
to flash memory were fatal.
As I can see now, Forth works but I'm still confused with words that
exist in "Hitchhiker's Guide to FlashForth" but not in FF (forget) or
vice versa (iflush).
To patch the file i suggest copying this 3 times into FF assembler code:
#ifdef PIR6
bcf PIR6, EEIF, A
#else
bcf PIR2, EEIF, A
#endif
... and change d'128' into d'64' in .cfg for 18F65K22, 18F66K22,
18F85K22 & 18F86K22.
Has anyone tried to use USART2 instead of USART1?
Zdravko
|
|
From: Peter J. <pe...@me...> - 2016-02-22 20:21:40
|
For the PIC18 and AVR, the definition of forget is in core.txt, which can be loaded once FF is up and running. For the PIC24-30-33, the definition is in the main assembly program. I've been thinking that I should put the guide and tutorial source files up on bitbucket to give people better access and make it easier to accept patches. I've used DIP28 and DIP40 processors mainly and have not tried any of the high pin-count parts. I've found FF very reliable on the pic18F2520, pic18F46k22 and pic18f26k22 parts. In one of the teaching labs, we have pressure indicator box that uses a pic18f2520 running FF. It's been running continuously for a couple of years. Also, haven't tried USART2. Cheers, Peter J. On 23/02/16 02:52, zd...@al... wrote: > Hi, everyone, > > It was easy to import files to MPLAB, and I expected that after my > hardware was soldered only 1 download to PIC will be enough to start > working in FlashForth. Well, I started programming in Forth in 1984 and > I have 20 years of experience with PICs and shouldn't describe myself as > an begginer, but still I needed almost a week to make FF work. > I'm afraid most people could just give up. That's why I would like to > discuss my problems here and make whole package more user frendly. MPLAB > project has many files included, some of them non existent. Obviously, I > had to include p18f66k22.cfg, but it wasn't clear that I have to exclude > most of files because baud rate calculation didn't work correct. > Apparently it was calculating for 48MHz although in p18f66k22.cfg it was > correct 64MHz. > Finally, I got some "FlashForth" response on my terminal but it was > impossible to work as it didn't accept command line and kept restarting > every couple of seconds. After one day with in-circuit emulator I wasn't > smarter as it didn't behave the same way every time I tried to trace it, > so the next day I conected a beeper and turned it on from different > points in code to see how far it gets. In the end of the second day it > was obvious it is freezing on attempt to write into EEPROM. No wonder, > as EEIF flag is not in PIR2, but PIR6 on 18F66K22. > > ECSTORE1: > bcf EECON1, EEPGD, A > bcf EECON1, CFGS, A > bcf PIR2, EEIF, A > bsf EECON1, WREN, A > bcf INTCON, GIE, A > movlw h'55' > movwf EECON2, A > movlw h'aa' > movwf EECON2, A > bsf EECON1, WR, A > bsf INTCON, GIE, A > ECSTORE2: > btfss PIR2, EEIF, A > bra ECSTORE2 > bcf EECON1, WREN, A > bcf PIR2, EEIF, A > > There are 2 conclusions. First, some important pointers have to be > written into EEPROM before anything starts to work. Second, nobody ever > tried this code on any 65K22, 66K22, 85K22 or 86K22. > Now FF started working, but only until first colon definition and then > everything fell apart. Few more days of reprogramming, reading code, > reprogramming, reading "manual", reprogramming, reading dump, comparing > until I found error in p18f66k22.cfg. > constant flash_write_inner_loop = d'128' > Only 18x7K22 has 128 byte buffer and as a result all attempts to write > to flash memory were fatal. > As I can see now, Forth works but I'm still confused with words that > exist in "Hitchhiker's Guide to FlashForth" but not in FF (forget) or > vice versa (iflush). > > To patch the file i suggest copying this 3 times into FF assembler code: > #ifdef PIR6 > bcf PIR6, EEIF, A > #else > bcf PIR2, EEIF, A > #endif > > ... and change d'128' into d'64' in .cfg for 18F65K22, 18F66K22, > 18F85K22 & 18F86K22. > > Has anyone tried to use USART2 instead of USART1? > > Zdravko > > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2016-02-22 20:58:43
|
Zdravko, Since you seem to be the first one to use these chips, you get the honour of debugging, contributing to this open source project. I will include your findings into FF as soon as I have time. The clock frequency needs to specified in p18fmain.cfg in order to get the baud rate calculation correct. BR Mikael |
|
From: <zd...@al...> - 2016-04-25 22:01:39
|
Hi, everyone, Two months after my start with FF I finally have the combination I've been looking for: PIC18F65K90 working in FF. http://www.alara.hr/images/K90.jpg Debugging with 66K22 has paid off and this time it worked on the first try. There is FTDI USB to UART which also supplies 3.3V for PIC, and just 10 capacitors + 5 resistors. Totally Plug@Play. It can be used for anything as the most of PIC pins can be accesed via 2 x 16 pin connectors. I'll put a custom LCD on it, battery supply, quartz for real time clock, and move communication to UART2 because LCD needs UART1 pins. As the PICs 24 and bigger have support for both UART, hope this will not be a big problem to implement. There is one thing that I'm not happy with: FF error reporting. It is hard to notice a question mark(s) when you compile 200 lines, and I would like to have a 'beep' for each error. Is it possible to make a vector which is executed on each error so I can choose if it just prints "?" (by default) or add a character like ctrl-g which makes sound on terminal, or attributes for inverted or flashing letters? Does it make sense? Zdravko |
|
From: Mikael N. <mik...@fl...> - 2016-04-26 20:01:54
|
There is no support in FF-PIC18 for the second UART. It should be easy to change the uart1 registers to uart2 registers in the source code. Some support in the config could even be introduced for that. I am reluctant to increase the code size in FF-PIC18 because then users have to select between multiple linker files. There has been a request before to add better error handling. There was suggestion to have a unique error string like ??? so that the uploader script could pause and ask if the upload should be abandoned. Igor wrote a Teraterm uploader script for that. https://github.com/igor-m/EXPERIMENTAL_ZZ/blob/master/shell/Upload2FF.ttl A deferred word is flexible and it could have a default value of "emit ?" I could put in a deferred word for the error printout. It would be global a ram defer initialized at warm start. You would need to defer it again in turnkey if you want to have automatic initialization. It could also have a default string to be set at compilation time. One problem with the bell is that it will sound once for every missing marker, which not an error as such. It will also sound for redefinition of words. BR Mikael On 26.04.2016 01:01, zd...@al... wrote: > Hi, everyone, > > Two months after my start with FF I finally have the combination I've > been looking for: PIC18F65K90 working in FF. > http://www.alara.hr/images/K90.jpg > Debugging with 66K22 has paid off and this time it worked on the > first > try. There is FTDI USB to UART which also supplies 3.3V for PIC, and > just 10 capacitors + 5 resistors. Totally Plug@Play. It can be used > for > anything as the most of PIC pins can be accesed via 2 x 16 pin > connectors. I'll put a custom LCD on it, battery supply, quartz for > real > time clock, and move communication to UART2 because LCD needs UART1 > pins. > As the PICs 24 and bigger have support for both UART, hope this will > not > be a big problem to implement. > > There is one thing that I'm not happy with: FF error reporting. It is > hard to notice a question mark(s) when you compile 200 lines, and I > would like to have a 'beep' for each error. Is it possible to make a > vector which is executed on each error so I can choose if it just > prints > "?" (by default) or add a character like ctrl-g which makes sound on > terminal, or attributes for inverted or flashing letters? > Does it make sense? > > Zdravko > > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications > Manager > Applications Manager provides deep performance insights into multiple > tiers of > your business applications. It resolves application problems quickly > and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: <zd...@al...> - 2016-05-01 20:48:04
|
No, it didn't work for UART2. Transmit didn't work because the
initialization was missing. You should just add #ifs and #endifs:
movlw spbrgval
; movwf SPBRG, A
banksel SPBRG2
movwf SPBRG2, BANKED
; TX enable
movlw b'00100100'
; movwf TXSTA, A
banksel TXSTA2
movwf TXSTA2, BANKED
Receive didn't work because RX2 is also an analog pin and while UART
takes care about TRIS setting, analog pin takes priority. This is
(probably) correct code:
; RX enable
#if UART == 1
#ifdef ANSELH
#ifdef ANS11
bcf ANSELH, ANS11, A ; Enable digital RB5 for RX(1)
#endif
#endif
#ifdef ANSELC
#ifdef ANSC7
banksel ANSELC
bcf ANSELC, ANSC7, BANKED ; Enable digital RC7 for RX(1)
#endif
#endif
#else
banksel ANCON2
bcf ANCON2, ANSEL18, BANKED ; Enable digital RG2 for RX2
#endif
Funny thing is that databook is totally misleading:
"In order to configure these pins as an EUSART: ... For EUSART2: ...
TRISG<1> bit must be cleared (= 0) for Asynchronous ..."
Not true, and they admit it almost immediately. ;-)
"Note: The EUSART control will automatically reconfigure the pin from
input to output as needed."
That's true, but it won't reconfigure this pin from analog to digital,
and it is nowhere mentioned in UART chapter that you shoud do it.
Mikael, give me your address so I can send you a PCB with 18F66K22 (or
65K90 if you prefer). It is pretty weird that I'm the only one in the
whole world using this with FF, hope somebody else will join and find
more use for all this.
Zdravko
|
|
From: <zd...@al...> - 2016-05-08 21:50:28
|
For the second time in 3 months I've been loosing time looking for the non existent bugs, so I would like to prevent the others falling into a same hole. In my MPLAB (8.92), when I open the FF_UART project for PIC18 it contains 11 'other' files: Two are marked as "file not found": install.txt readme.txt Everything works without them so they could be removed from the project. Then, there are 7 different .cfg files for specific PIC models of families. It is not clear if you should remove the files that are not exactly for your PIC. These 2 files are neccesary in every case: pic18f-main.cfg pic18fxxxx.cfg The problem is, these 2 files are also included in .asm: #include "p18f-main.cfg" #include "p18fxxxx.cfg" So they are processed twice, first as specified in project, second time from a folder with the .asm file (and there are a few good reasons why to keep them in a separate folders). Of course, second pass overrules the previous settings. As my .asm was in a different folder I was getting wrong baud rate calculation for 48 instead of 64 MHz. I would suggest removing all #include from .asm and placing only 3 files on project include list: pic18f-main.cfg, pic18fxxxx.cfg and readme.txt with short explanation about which .cfg files are neccessary. Should 'clock =' go out of 'main.cfg' into .cfg specific for each PIC? Any thoughts on that? Zdravko |
|
From: Mikael N. <mik...@fl...> - 2016-05-09 07:03:51
|
Basically I have abandoned MPLAB, I use only MBLABX. But I can try to clean up the MBLAB projects. The clock could be moved to device file since the clock relies on the config bits. BR Mikael On 09.05.2016 00:50, zd...@al... wrote: > For the second time in 3 months I've been loosing time looking for > the > non existent bugs, so I would like to prevent the others falling into > a > same hole. In my MPLAB (8.92), when I open the FF_UART project for > PIC18 > it contains 11 'other' files: > > > Should 'clock =' go out of 'main.cfg' into .cfg specific for each > PIC? > > Any thoughts on that? > > Zdravko > > > > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications > Manager > Applications Manager provides deep performance insights into multiple > tiers of > your business applications. It resolves application problems quickly > and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X