flashforth-devel Mailing List for FlashForth: for PIC and Atmega (Page 38)
Brought to you by:
oh2aun
Menu
▾
▴
flashforth-devel — FlashForth users and developers
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
(22) |
Mar
(3) |
Apr
(4) |
May
(6) |
Jun
(8) |
Jul
|
Aug
(6) |
Sep
|
Oct
(20) |
Nov
(9) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(4) |
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(14) |
Nov
(1) |
Dec
|
| 2013 |
Jan
(4) |
Feb
(5) |
Mar
(4) |
Apr
(2) |
May
|
Jun
(29) |
Jul
(7) |
Aug
|
Sep
(20) |
Oct
(9) |
Nov
(2) |
Dec
(7) |
| 2014 |
Jan
|
Feb
(23) |
Mar
(113) |
Apr
(25) |
May
(31) |
Jun
(9) |
Jul
(47) |
Aug
(15) |
Sep
(1) |
Oct
(4) |
Nov
(8) |
Dec
(3) |
| 2015 |
Jan
(21) |
Feb
(1) |
Mar
(18) |
Apr
(16) |
May
(100) |
Jun
(33) |
Jul
|
Aug
(10) |
Sep
(8) |
Oct
(7) |
Nov
(5) |
Dec
|
| 2016 |
Jan
(12) |
Feb
(9) |
Mar
|
Apr
(7) |
May
(5) |
Jun
(9) |
Jul
(1) |
Aug
(2) |
Sep
(17) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
(6) |
Feb
(12) |
Mar
(9) |
Apr
(3) |
May
(7) |
Jun
|
Jul
(12) |
Aug
|
Sep
(13) |
Oct
|
Nov
|
Dec
(10) |
| 2018 |
Jan
(1) |
Feb
|
Mar
(7) |
Apr
(4) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(21) |
Oct
(3) |
Nov
|
Dec
|
| 2019 |
Jan
(5) |
Feb
(4) |
Mar
|
Apr
|
May
(3) |
Jun
(11) |
Jul
(4) |
Aug
(6) |
Sep
(3) |
Oct
|
Nov
(9) |
Dec
(7) |
| 2020 |
Jan
(2) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(4) |
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(8) |
Apr
(40) |
May
(12) |
Jun
|
Jul
|
Aug
(3) |
Sep
(3) |
Oct
(4) |
Nov
(10) |
Dec
(4) |
| 2022 |
Jan
(29) |
Feb
(7) |
Mar
(10) |
Apr
|
May
(3) |
Jun
(3) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(6) |
| 2023 |
Jan
(8) |
Feb
|
Mar
(5) |
Apr
(9) |
May
(6) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(9) |
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Davoud S. <dav...@gm...> - 2013-12-10 16:57:06
|
Hi Mikael, As Atmega32A is easy to find here I wonder if it is possible to assemble FF for this target by just editing config.inc, we already have Atmega644P there which is pretty much the same with 32KB less flash space, or it needs extra work to adapt FF for Atmega32A? Warmest Regards, Davoud |
|
From: Mikael N. <mik...@pp...> - 2013-11-01 20:53:50
|
Sure, But I suggest you read the atmega instruction set manual first anyway. http://www.atmel.com/images/doc0856.pdf Mike On 11/01/2013 08:05 PM, Davoud Seyedin wrote: > Hi Mikael, > > Is it possible for you to provide a short document for atmega assember > or just some comments on the asmtest? > > Regards, > Davoud > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
|
From: Davoud S. <dav...@gm...> - 2013-11-01 18:07:41
|
Hi Mikael, Is it possible for you to provide a short document for atmega assember or just some comments on the asmtest? Regards, Davoud |
|
From: Peter J. <pe...@me...> - 2013-10-26 12:42:44
|
Mike, I've updated the ff-tutorial-guide.pdf at http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/ Fixed a couple of typos, changed to use GtkTerm for the terminal program and added an example of reporting voltage measurements from an MCP3422 ADC hanging off the I2C port. I needed a scale operator for mixed, signed values so I've put one in m-star-slash.txt. It might be useful for other users of qmath.txt (if you don't already have one -- I looked but didn't see). Regards, Peter Jacobs \ m-star-slash.txt \ Peter J. 2013-10-26 -m-star-slash marker -m-star-slash \ Duplicate triple : 3dup ( n1 n2 n3 -- n1 n2 n3 n1 n2 n3 ) 2 pick 2 pick 2 pick ; \ Signed scale d1*n1/n2 with intermediate triple result : m*/ ( d1 n1 n2 -- d2 ) 3dup xor xor >r \ save result sign abs >r abs >r dabs r> r> \ now have S:ud1 u1 u2 um*/ r> ?dnegate ; |
|
From: Mikael N. <mik...@pp...> - 2013-10-25 03:20:20
|
I think it should work on that chip. For these never chips I use MPLABX and the XC16 compiler. The pic30-as does not seem to support these newer chips. Mike |
|
From: <rsc...@op...> - 2013-10-24 22:57:13
|
Hi, I'm new to FF. I've been trying to assemble and load FF4.8 onto a pic24FV16km202 Microstick without luck. MPLAB 8.8 fails to assemble saying : Clean: Deleting intermediary and output files. Clean: Deleted file "D:MPLAB_IDE_8_88FF.mcs". Clean: Done. Executing: "C:Program FilesMicrochipMPLAB ASM30 Suitebinpic30-as.exe" "ff.s" -o"ff.o" -p=24FV16KM202 --keep-locals -g -ahmls="ff.lst" Unknown processor 24FV16KM202. Halting build on first failure as requested. ---------------------------------------------------------------------- Release build of project `D:MPLAB_IDE_8_88FF.mcp' failed. Language tool versions: pic30-as.exe v3.31, pic30-ld.exe v3.31, pic30-ar.exe v3.31 Fri Oct 25 09:59:46 2013 ---------------------------------------------------------------------- BUILD FAILED Will FF 4.8 work on the PIC24FV16km202 ? Thanks. ------------------------- Email sent using Optus Webmail |
|
From: Mikael N. <mik...@pp...> - 2013-10-20 08:58:45
|
No need to send me the project files. The startup sequence in WARM is such that if turnkey contains something else than 0 or FFFF, it assumed to be a valid word address. If it is some crap you normally get cyclic restarts. If turnkey contains FFFF, then EMPTY is executed in startup. This is the case when you have erased the eeprom. So your eeprom turnkey contained neither zero or FFFF when you had the problem. You test this by $ffff is turnkey <cr> warm <cr> After this you should have an empty device. Now, when you set the eeprom to 00, FlashForth itself did not reprogram the eeprom. So in this case it must be that the hex file contained the correct eeprom info which your programmer put into the eeprom. BR Mike On 10/20/2013 10:31 AM, Neil Shuker-Harris wrote: > > Hi Mikael, > > Thank you for your reply. > > Executing empty fixed the problem completely. > > Your suggestion about the eeprom not getting programmed correctly had > me look at the way I had programmed the device. I found that > mikroelektronicas mikroprog suite defaults to putting FF in all 256 > eeprom memory locations if you do not load it with anything else. I > have never had a problem with this in the past with other pic projects > so never thought to change it. I erased the eeprom using the facility > in mikropro , set the locations to 00 and reprogrammed the device and > worked first time with no need to execute empty. > > As this is now working do you still want the mplab project, > particularly as I am only using it to create the hex file. > > Neil > > *From:*Mikael Nordman [mailto:mik...@pp...] > *Sent:* 19 October 2013 21:47 > *To:* fla...@li... > *Subject:* Re: [Flashforth-devel] re V 3.8 runing in 4550 > > It seems to me that for some reason the EEPROM does not get > programmed correctly. > > Try to after ESC as the first command give EMPTY. > It should correct the EEPROM. > > Are you using FF3.8 or some development version from git ? > > Are you using a bootloader ? > > If you can zip your exact mplab project to me, I can have a look. > > BR Mike > > On 10/19/2013 10:54 PM, Neil Shuker-Harris wrote: > > Hi All, > > With some direct help from Craig Bair I have succeed today in > compiling and loading FF into a 18f4550. My set up is an easypic 7 > dev board 8mhz crystal oscillator. I am using the uart version of > FF with a mikroElektronika supplied usb to serial driver called > VCP for a FTDI FT232RL to a putty terminal which communicates in > both directions as expected. > > When I switch the board on I get a the following line on screen > > ESCFlashForth V3.8 > > which repeats around once per second. > > I can interrupt this by pressing esc to get the interpreter as > suggested in the manual, but then about the only things I can do > then is type words which performs as expected by printing the > dictionary and ' .' which gives an 0 ok. 1 2 + . gives nothing > and as with the other trials the above ESC etc starts scrolling > again. I do not have turnkey set as this is a new install and I > have as yet done nothing with it other than turn it on and the above. > > Any ideas as to what this might be and how to fix it would be > welcomed. > > Neil > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > > the latest Intel processors and coprocessors. See abstracts and register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk > > > > > _______________________________________________ > > Flashforth-devel mailing list > > Fla...@li... <mailto:Fla...@li...> > > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
|
From: Mikael N. <mik...@pp...> - 2013-10-19 20:47:23
|
It seems to me that for some reason the EEPROM does not get programmed correctly. Try to after ESC as the first command give EMPTY. It should correct the EEPROM. Are you using FF3.8 or some development version from git ? Are you using a bootloader ? If you can zip your exact mplab project to me, I can have a look. BR Mike On 10/19/2013 10:54 PM, Neil Shuker-Harris wrote: > > Hi All, > > With some direct help from Craig Bair I have succeed today in > compiling and loading FF into a 18f4550. My set up is an easypic 7 dev > board 8mhz crystal oscillator. I am using the uart version of FF with > a mikroElektronika supplied usb to serial driver called VCP for a > FTDI FT232RL to a putty terminal which communicates in both directions > as expected. > > When I switch the board on I get a the following line on screen > > ESCFlashForth V3.8 > > which repeats around once per second. > > I can interrupt this by pressing esc to get the interpreter as > suggested in the manual, but then about the only things I can do then > is type words which performs as expected by printing the dictionary > and ' .' which gives an 0 ok. 1 2 + . gives nothing and as with the > other trials the above ESC etc starts scrolling again. I do not have > turnkey set as this is a new install and I have as yet done nothing > with it other than turn it on and the above. > > Any ideas as to what this might be and how to fix it would be welcomed. > > Neil > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Neil Shuker-H. <nei...@sk...> - 2013-10-19 19:54:20
|
Hi All, With some direct help from Craig Bair I have succeed today in compiling and loading FF into a 18f4550. My set up is an easypic 7 dev board 8mhz crystal oscillator. I am using the uart version of FF with a mikroElektronika supplied usb to serial driver called VCP for a FTDI FT232RL to a putty terminal which communicates in both directions as expected. When I switch the board on I get a the following line on screen ESCFlashForth V3.8 which repeats around once per second. I can interrupt this by pressing esc to get the interpreter as suggested in the manual, but then about the only things I can do then is type words which performs as expected by printing the dictionary and ' .' which gives an 0 ok. 1 2 + . gives nothing and as with the other trials the above ESC etc starts scrolling again. I do not have turnkey set as this is a new install and I have as yet done nothing with it other than turn it on and the above. Any ideas as to what this might be and how to fix it would be welcomed. Neil |
|
From: Mikael N. <mik...@pp...> - 2013-10-19 09:10:02
|
I put together an Atmega Assembler for flashforth. It is available in git on the flashforth site http://sourceforge.net/p/flashforth/code/ci/master/tree/ Cheers Mike |
|
From: Pete Z. <pza...@pz...> - 2013-10-17 18:45:12
|
Hi all, I have added some utility files with helpful words (for us) for FF3.81 and FF4.81 on the Wiki. Let me know if they are of any use to you and please add to the Wiki. Pete Pete Zawasky PZEF Co. 361 Mills RD Oriental, NC 28571 www.pzef.net pza...@pz... 1-252-249-3393 (voice and fax) 1-252-670-6940 (cell) |
|
From: Mikael N. <mik...@pp...> - 2013-10-08 20:31:58
|
There is now an example project in git that implements a simple word in C and is called from a Forth word. The word is C4+ , which does adds 4 to TOS. git clone git://git.code.sf.net/p/flashforth/code flashforth-code The project is for MPLABX and FF 4.82 (PIC24-30-33). The XC16 compiler needs also to be installed. Any suggestions or improvements on how to call C-code from Forth are appreciated. Thanks Mike |
|
From: Mikael N. <mik...@pp...> - 2013-09-28 17:57:14
|
I think anything simpler than a PIC18 is too primitive for a target resident Forth, There was a guy called Byron Jeff looking into this. He gave up and concluded the same. Google finds him. Mike |
|
From: craig b. <dab...@ya...> - 2013-09-27 15:46:30
|
Has anyone given any thought to the downsizing problem? I've done a couple of projects on the 16F1825 &1829 chips now and the XLP extensions look like it might finally be possible (although probably not pretty). There are now 2 FSR-s and have larger addressing, the ram has a flattened access mode, and there's FINALLY access to the stack. The bank-switching for sfr access could be annoying, but looks like if rolled together could be easier to write for than my usual assembler banging. I'm poking at it as an amusing curiosity (although it could be a nice quick-turnaround tool) and wonder if anyone else sees potential. Thanks for time, craig bair ...not a speck of serial... |
|
From: Mikael N. <mik...@pp...> - 2013-09-23 19:14:16
|
I pushed to the git repo MPLABX projects for FF3.81 and FF4.81. You need to install MPLABX and the XC16 compiler. Hope that helps. BR Mike On 09/23/2013 01:38 AM, glen worstell wrote: > Hi, > > I tried to assemble this using the latest MPLAB-X on linux, and got > this error: > > In file included from ../../Downloads/asl-current/code16c5x.c:31:0: > ../../Downloads/asl-current/stdinc.h:29:20: fatal error: unistd.h: No > such file or directory > > Do you have any ideas? > > TIA, > g. > KG0T > |
|
From: Donald G. <dgo...@sb...> - 2013-09-20 19:09:54
|
I downloaded FF4.8 from Sourceforge. Opened the workspace in MPlab 8.70. Changed Config/Device to my dsPIC33FJ256MC710 Clicked: Build all. Received a "Build Succeeded" Wow, that was easy! I will download the file to the device and test it out. Thanks, Don ________________________________ From: Donald Golding <dgo...@sb...> To: Mikael Nordman <mik...@pp...>; "fla...@li..." <fla...@li...> Sent: Friday, September 20, 2013 11:54 AM Subject: Re: [Flashforth-devel] FF 3.8 onto newer PIC18FxxK22 chips I am new to FlashForth. I want to use it on a dsPIC33FJ256MC710 device. Has anyone done this before? Care to share what you had to do to implement this? Thanks, Don ________________________________ From: Mikael Nordman <mik...@pp...> To: fla...@li... Sent: Monday, September 16, 2013 2:25 PM Subject: Re: [Flashforth-devel] FF 3.8 onto newer PIC18FxxK22 chips Thanks Attila, I'll make that update. Did you also change the clock source for the timers ? Apparently the use if internal clock for TMR3 is not the default in 18f2xK22. BR Mike On 09/16/2013 10:52 PM, Herman Attila wrote: > Hi Craig and Mike > > The 18FxxK22 controllers are good choice, because they have several nice features. (2UARTS, 64MHz, lot of timers ...) > If you want to use them, you have to modify the ff18_usb.asm file. The main problem with the using uart, the RX enable incompatibility. These controllers use ansela, anselb, anselc, anseld instead of ansel, anselh. The new RX enable routine: > ; RX enable > #ifdef ANSELH > #ifdef ANS11 > bcf ANSELH, ANS11, A ; Enable digital RB5 for RX > #endif > #endif > > #ifdef ANSELC > #ifdef ANSC7 > BANKSEL ANSELC > bcf ANSELC, ANSC7, BANKED ; Enable digital RC7 for RX > #endif > #endif > > movlw b'10010000' > movwf RCSTA, A > bsf PIE1, RCIE, A > > You must use banked addressing, because anselc is out of range access bank! > > These controllers can run 64MHz with internal oscillator with PLL, but using this feature need a modification in FF. That's why the PLL enable in config bits is uneffective for the internal oscillator. > > #ifdef OSCCON > movlw 0x70 ; Use full internal OSC frequency > movwf OSCCON, A > #endif > #ifdef PLL_EN ; Activate PLL > movlw 0x40 > movwf OSCTUNE, A > #endif > > To activate it, place the next line in 18f-main.cfg : > > #define PLL_EN \ Activate PLL from SW > > I suggest to build this modifications in the FF. > > BR > Attila Herman > > > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk _______________________________________________ Flashforth-devel mailing list Fla...@li... https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Donald G. <dgo...@sb...> - 2013-09-20 18:54:46
|
I am new to FlashForth. I want to use it on a dsPIC33FJ256MC710 device. Has anyone done this before? Care to share what you had to do to implement this? Thanks, Don ________________________________ From: Mikael Nordman <mik...@pp...> To: fla...@li... Sent: Monday, September 16, 2013 2:25 PM Subject: Re: [Flashforth-devel] FF 3.8 onto newer PIC18FxxK22 chips Thanks Attila, I'll make that update. Did you also change the clock source for the timers ? Apparently the use if internal clock for TMR3 is not the default in 18f2xK22. BR Mike On 09/16/2013 10:52 PM, Herman Attila wrote: > Hi Craig and Mike > > The 18FxxK22 controllers are good choice, because they have several nice features. (2UARTS, 64MHz, lot of timers ...) > If you want to use them, you have to modify the ff18_usb.asm file. The main problem with the using uart, the RX enable incompatibility. These controllers use ansela, anselb, anselc, anseld instead of ansel, anselh. The new RX enable routine: > ; RX enable > #ifdef ANSELH > #ifdef ANS11 > bcf ANSELH, ANS11, A ; Enable digital RB5 for RX > #endif > #endif > > #ifdef ANSELC > #ifdef ANSC7 > BANKSEL ANSELC > bcf ANSELC, ANSC7, BANKED ; Enable digital RC7 for RX > #endif > #endif > > movlw b'10010000' > movwf RCSTA, A > bsf PIE1, RCIE, A > > You must use banked addressing, because anselc is out of range access bank! > > These controllers can run 64MHz with internal oscillator with PLL, but using this feature need a modification in FF. That's why the PLL enable in config bits is uneffective for the internal oscillator. > > #ifdef OSCCON > movlw 0x70 ; Use full internal OSC frequency > movwf OSCCON, A > #endif > #ifdef PLL_EN ; Activate PLL > movlw 0x40 > movwf OSCTUNE, A > #endif > > To activate it, place the next line in 18f-main.cfg : > > #define PLL_EN \ Activate PLL from SW > > I suggest to build this modifications in the FF. > > BR > Attila Herman > > > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk _______________________________________________ Flashforth-devel mailing list Fla...@li... https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: craig b. <dab...@ya...> - 2013-09-17 14:16:07
|
There are a few modifications to FlashForth required to use the INTOSC and INTOSC-PLL Fosc configurations, as I've discovered trying to get it running in a PIC18F26K22. First: The INTOSC needs to be configured as Primary Clock, PLL enabled and selected config bits required: > config FOSC = INTIO67 ;Internal oscillator block > config PLLCFG = ON ;Oscillator multiplied by 4 > config PRICLKEN = ON ;Primary clock enabled This is probably best done in the processor's .CFG file for consistancy with the package. ; :!!!!!!!!!!!!!!!! Second: OSCCON and OSCTUNE bits need to be set in the startup (main: in the ff18_usb.asm code) I made these changes: ; main: movlw 0xf iorwf ADCON1, F, A clrf TBLPTRU, A #ifdef USB_CDC movlw 0x14 movwf UCFG, A #endif #ifdef OSCCON #ifdef __18F26K22 movlw 0x70 movwf OSCCON,A movlw 0x40 ;ena PLL movwf OSCTUNE #else movlw 0x70 ; Use full internal OSC frequency movwf OSCCON, A #endif #endif ; :!!!!!!!!!!!!!!!! Third problem was matching up the baudrate with higher clockrates Added this sequence to p18f-main.cfg and cleaned up conflicts: ; #define CONFIG_RESET 0x0000 ; No bootloader constant clock = .64000000 ; Hz constant baud = .38400 ; Handle 8-bit BRG overflow condition... ;#define Use_BRG16 0 ; to use higher Fosc, BRG16 needs to be activated... #define Use_BRG16 1 #if (Use_BRG16) constant spbrgval = ((clock/baud)/d'4') - 1 #else constant spbrgval = ((clock/baud)/d'16') - 1 #endif ; :!!!!!!!!!!!!!!!! ...This needs to be commented out if still present: ;;; Calculate the baud rate control value ; constant spbrgval = ((clock/baud)/d'16') - 1 ; :!!!!!!!!!!!!!!!! ... Then inserted this into the WARM: sequence in ff18_usb.asm #if(Use_BRG16) ; Setup UART1 with high-speed 16-bit BaudRate Gen ; 18F26K22 Workaround: ANSELx FUMTU movlw 0 ;load up pattern... movff WREG,ANSELC ;...and BANG it in directly ; set Baudrate movlw b'00001000' ;BRG16 movwf BAUDCON1,A movlw (spbrgval%0x100) movwf SPBRG1,A movlw (spbrgval/0x100) movwf SPBRGH1,A ; TX enable movlw b'00100100' ;TXEN + BRGH + !SYNC movwf TXSTA1, A ; RX enable !!!!! movlw b'10010000' ;SPEN + CREN movwf RCSTA1, A bsf PIE1, RCIE, A #else movlw spbrgval movwf SPBRG, A ; movlw 0 ; movwf SPBRGH, A ; TX enable movlw b'00100100' ;TXEN + BRGH movwf TXSTA, A ; RX enable !!!!! ; 18F26K22 Workaround: This form Failed to change ANSELC Register... ; bcf ANSELH, ANS11, A ; Enable digital RB5 for RX ; movwf ANSELC,A ;DOESN'T WORK, EITHER! movlw 0 ;load up pattern... movff WREG,ANSELC ;...and BANG it in directly ; bsf TRISC,7,A ;appearently futile but not needed movlw b'10010000' ;SPEN + CREN movwf RCSTA, A bsf PIE1, RCIE, A #endif ; :!!!!!!!!!!!!!!!! Finally, the change that tripped me up the longest was the ms-timer config for IDLE MODE. My TMR3 default T3CON was clocking from Pin Or Oscillator which wasn't available running INTOSC. The sysrem clock source (Fosc) works with the least change, instruction clock is /4. My change (immediately following above code): #ifdef MS_TMR3 #ifdef OSCCON movlw h'41' ; System Clock (Fosc) #else movlw h'81' ; prescale = 1 #endif movwf T3CON, A setf TMR3H, A bsf PIE2,TMR3IE, A #endif ; :!!!!!!!!!!!!!!!! Other chips and other config choices may require other mods (your milage may vary (grin)), but hopefully this can save someone else some of the frustrations I experienced. Many thanks to Mike and Attila for the help, hearty exhortations, and sound advice. Great Project! Long may it rave. craig bair -- binary behaviorist ...not a speck of serial... |
|
From: Herman A. <exp...@vn...> - 2013-09-16 21:56:13
|
Hi Mike
I have forgotten to write, I used olnly the tmr4 for ms, similarly then the tmr2 is used:
#ifdef MS_TMR4 ;******************************
banksel PIR5
btfss PIR5, TMR4IF, BANKED
bra irq_ms_end
bcf PIR5, TMR4IF, BANKED
infsnz ms_count, F, A
incf ms_count+1, F, A
#endif
BR
Attila
|
|
From: Mikael N. <mik...@pp...> - 2013-09-16 21:25:09
|
Thanks Attila, I'll make that update. Did you also change the clock source for the timers ? Apparently the use if internal clock for TMR3 is not the default in 18f2xK22. BR Mike On 09/16/2013 10:52 PM, Herman Attila wrote: > Hi Craig and Mike > > The 18FxxK22 controllers are good choice, because they have several nice features. (2UARTS, 64MHz, lot of timers ...) > If you want to use them, you have to modify the ff18_usb.asm file. The main problem with the using uart, the RX enable incompatibility. These controllers use ansela, anselb, anselc, anseld instead of ansel, anselh. The new RX enable routine: > ; RX enable > #ifdef ANSELH > #ifdef ANS11 > bcf ANSELH, ANS11, A ; Enable digital RB5 for RX > #endif > #endif > > #ifdef ANSELC > #ifdef ANSC7 > BANKSEL ANSELC > bcf ANSELC, ANSC7, BANKED ; Enable digital RC7 for RX > #endif > #endif > > movlw b'10010000' > movwf RCSTA, A > bsf PIE1, RCIE, A > > You must use banked addressing, because anselc is out of range access bank! > > These controllers can run 64MHz with internal oscillator with PLL, but using this feature need a modification in FF. That's why the PLL enable in config bits is uneffective for the internal oscillator. > > #ifdef OSCCON > movlw 0x70 ; Use full internal OSC frequency > movwf OSCCON, A > #endif > #ifdef PLL_EN ; Activate PLL > movlw 0x40 > movwf OSCTUNE, A > #endif > > To activate it, place the next line in 18f-main.cfg : > > #define PLL_EN \ Activate PLL from SW > > I suggest to build this modifications in the FF. > > BR > Attila Herman > > > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
|
From: Mikael N. <mik...@pp...> - 2013-09-16 21:22:16
|
Craig, please reply to the list. Others may have some input also. If the ms-timer interrupts are not firing and you have idle mode in use there will be watchdog resets occuring. That could explain some of your problems. How should the timers be configured to use the internal clock as source on these chips ? BR Mike On 09/16/2013 11:34 PM, craig bair wrote: > Mike, > > OSCCON wants to be 0xF0 and OSCTUNE wants PLLEN set (0x40)... OSCCON2 is fine on default. > I went a few rounds with the PLL before finding out that it only works with Primary Clock Selected. > > That setup was what drove me to tinker with the .ASM file. Well, that and the need to go into 16-bit BRG mode to get the UART into the right range. > > CONFIG BITS: > config FOSC = INTIO67 ;Internal oscillator block > ; config FOSC = ECMPIO6 ;EC oscillator (medium power, 500 kHz-16 MHz) > ; Note: PLL only operates with PRIMARY CLOCK > config PLLCFG = ON ;Oscillator multiplied by 4 > config PRICLKEN = ON ;Primary clock enabled > config FCMEN = OFF ;Fail-Safe Clock Monitor disabled > config IESO = OFF ;Oscillator Switchover mode disabled > config PWRTEN= OFF ;ON ;Power up timer enabled > config BOREN = OFF ;Brown-out Reset disabled in hardware and software > config BORV = 285 ;VBOR set to 2.85 V nominal > config WDTEN = ON ;WDT is always enabled. SWDTEN bit has no effect > config WDTPS = 256 ;Watchdog Timer Postscale > ; CCP2 MUX bit: > ; config CCP2MX = PORTB3 ;CCP2 input/output is multiplexed with RB3 > config CCP2MX = PORTC1 ;CCP2 input/output is multiplexed with RC1 > config PBADEN = OFF ;PORTB<5:0> pins are configured as digital I/O on Reset > ; P3A/CCP3 Mux bit: > ; config CCP3MX = PORTC6 ;P3A/CCP3 input/output is mulitplexed with RC6 > ; config CCP3MX = PORTB5 ;P3A/CCP3 input/output is multiplexed with RB5 > config HFOFST = OFF ;HFINTOSC output and ready status are delayed by the oscillator stable status > ; Timer3 Clock input mux bit: > ; config T3CMX = PORTB5 ;T3CKI is on RB5 > ; config T3CMX = PORTC0 ;T3CKI is on RC0 > ; ECCP2 B output mux bit: > ; config P2BMX = PORTC0 ;P2B is on RC0 > ; config P2BMX = PORTB5 ;P2B is on RB5 > config MCLRE = EXTMCLR ;MCLR pin enabled, RE3 input pin disabled > config STVREN = ON ;Stack full/underflow will cause Reset > config LVP = OFF ;Single-Supply ICSP disabled > config XINST = OFF ;Instruction set extension and Indexed Addressing mode disabled > config DEBUG = OFF ;Background Debug disabled > > > > The SIM is dicey for the PIC18FxxK22 chips and may not get fixed with the new MPLab-X takeover. I'm still running XP single-core machines, so I really can't afford the processor overhead of JAVA-based software. At least not until the economy picks up again. > > what I DID stumble across building up pieces and running test routines on the chip was that the ms-timer interrupts weren't firing. I've gone back into the docs for TMR3 and there are different bit-settings for timer osc inputs and the original takes it off the external pin. I'm switching it to System Clock (Fosc) and I'll see what that does. > > Thanks for the comments/suggestions, I'm pretty isolated and don't get to chat with programmers often. > > craig > > ...not a speck of serial... > |
|
From: Herman A. <exp...@vn...> - 2013-09-16 20:08:58
|
Hi Craig and Mike
The 18FxxK22 controllers are good choice, because they have several nice features. (2UARTS, 64MHz, lot of timers ...)
If you want to use them, you have to modify the ff18_usb.asm file. The main problem with the using uart, the RX enable incompatibility. These controllers use ansela, anselb, anselc, anseld instead of ansel, anselh. The new RX enable routine:
; RX enable
#ifdef ANSELH
#ifdef ANS11
bcf ANSELH, ANS11, A ; Enable digital RB5 for RX
#endif
#endif
#ifdef ANSELC
#ifdef ANSC7
BANKSEL ANSELC
bcf ANSELC, ANSC7, BANKED ; Enable digital RC7 for RX
#endif
#endif
movlw b'10010000'
movwf RCSTA, A
bsf PIE1, RCIE, A
You must use banked addressing, because anselc is out of range access bank!
These controllers can run 64MHz with internal oscillator with PLL, but using this feature need a modification in FF. That's why the PLL enable in config bits is uneffective for the internal oscillator.
#ifdef OSCCON
movlw 0x70 ; Use full internal OSC frequency
movwf OSCCON, A
#endif
#ifdef PLL_EN ; Activate PLL
movlw 0x40
movwf OSCTUNE, A
#endif
To activate it, place the next line in 18f-main.cfg :
#define PLL_EN \ Activate PLL from SW
I suggest to build this modifications in the FF.
BR
Attila Herman
|
|
From: Mikael N. <mik...@pp...> - 2013-09-16 19:34:47
|
Craig, Hard to say what the problem is. I don't have that chip series myself. I would do the following. Configure a simple oscillator conf without clock switching. Configure the OSCCON so that it matches the assumed clock frequency. Disable the watchdog in the configbits. Debug it in the simulator to check that it nicely runs in RX1 waiting for input. After that try to get the UART working on the target. What exactly are your configuration bits, and the OSCCON value ? BR Mike On 09/16/2013 08:51 PM, craig bair wrote: > Hi. I'm new at this email/online support thing, but played with Forth in the later 80-s and have been programming assembler into PIC16 chips for a couple of decades. PIC18-s, only occasionally (the PIC17 was brand new back then) but appreciate the architecture. > > I've gotten FF up and running nicely on 18F4550-s and an 18F4458 recently, but would like to use it in an 18F26K22 with the double UART. I've built a p18f26k22.cfg file with the config-bit settings and flash-write parms, extended the p18fxxxx.cfg file to cover the chip, tweaked the p18f-main.cfg and added a few small mods to the OSCCON and baudrate code in the ff_usb.asm to try and use the on-board intosc-pll combo to goose it up to 64Mhz operation. > > So far, I haven't gotten anything coherent out of the primary uart at any baudrate. My BitScope in logic mode shows me a quick series of blips (several per ms) for a few ms, a ms-long active bump, and then idle except for a blip each time the watchdog overflows. I didn't touch the watchdogging... Every change I've made to the config-bits or adding debug routines to the startup sequence has made it worse if not hung it completely. > > Has anyone else tried this stunt and/or have any suggestions about what I'm missing (besides "Don't fix a working program") ? > > Thanks and I hope this isn't a major intrusion. > > craig bair, binary behaviorist > > ...not a speck of serial... |
|
From: craig b. <dab...@ya...> - 2013-09-16 17:51:56
|
Hi. I'm new at this email/online support thing, but played with Forth in the later 80-s and have been programming assembler into PIC16 chips for a couple of decades. PIC18-s, only occasionally (the PIC17 was brand new back then) but appreciate the architecture. I've gotten FF up and running nicely on 18F4550-s and an 18F4458 recently, but would like to use it in an 18F26K22 with the double UART. I've built a p18f26k22.cfg file with the config-bit settings and flash-write parms, extended the p18fxxxx.cfg file to cover the chip, tweaked the p18f-main.cfg and added a few small mods to the OSCCON and baudrate code in the ff_usb.asm to try and use the on-board intosc-pll combo to goose it up to 64Mhz operation. So far, I haven't gotten anything coherent out of the primary uart at any baudrate. My BitScope in logic mode shows me a quick series of blips (several per ms) for a few ms, a ms-long active bump, and then idle except for a blip each time the watchdog overflows. I didn't touch the watchdogging... Every change I've made to the config-bits or adding debug routines to the startup sequence has made it worse if not hung it completely. Has anyone else tried this stunt and/or have any suggestions about what I'm missing (besides "Don't fix a working program") ? Thanks and I hope this isn't a major intrusion. craig bair, binary behaviorist ...not a speck of serial... |
|
From: Mike M. <mi...@mo...> - 2013-09-10 14:00:00
|
Pete We are using 4 uarts, 2 spi, 2 a/d inputs, and the rtc We are not using the PIC usb. Mike On 9/8/13 3:45 PM, Pete Zawasky wrote: > Hi Mike, > > Thanks for the info. The config bits and the programmable pin > assignments are "challenging". > I thought I was the only one confused..... > > Are you using the uart or usb function on the PIC24FJ256G110 ? > > Pete > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > |
17 messages has been excluded from this view by a project administrator.
