flashforth-devel Mailing List for FlashForth: for PIC and Atmega (Page 18)
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: Mikael N. <mik...@fl...> - 2016-01-18 16:12:03
|
This might work. Not tested.
$24 constant ddrb
$24 constant portb
$01 constant out
$02 constant clk
ddrb out bit1: spi-out-pin
portb out bit0: spi-out-0
portb out bit1: spi-out-1
portb clk bit0: spi-clk-0
portb clk bit1: spi-clk-1
: spi! ( u --- )
spi-out-pin
spi-clk-0
#16 for
dup $0001 and
if spi-out-1 else spi-out-0 then
spi-clk-1 2/ spi-clk-0
next drop ;
Mike
On 18.01.2016 00:33, Donald Golding wrote:
> Does anyone have a sample of SPI code?
>
> Thanks,
> Don
|
|
From: Donald G. <dgo...@sb...> - 2016-01-17 22:46:52
|
Does anyone have a sample of SPI code?
Thanks,Don
On Tuesday, January 6, 2015 9:21 AM, "fla...@li..." <fla...@li...> wrote:
Graham,
I have rewritten the Atmega BIT words.
The BIO words have been merged into the BIT words
so that always the optimal IO register access is used.
The BIO words were removed.
The new BIT words can be found in git and in the latest ff5.0.zip file.
Hope it works now. Tests can be found in bit-test.txt.
Mike
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Flashforth-devel mailing list
Fla...@li...
https://lists.sourceforge.net/lists/listinfo/flashforth-devel
|
|
From: Mikael N. <mik...@fl...> - 2016-01-11 18:05:03
|
Strange, I think your loop solution should work. BR Mikael On 09.01.2016 16:05, Thomas Buschhardt wrote: > I resend the mail, maybe the previous is encrypted > ====================================== > > Hallo, I want read a certain number of eeprom bytes. > > Here is a snippet to read 4 bytes > > addr-at24c32 add-read-bit i2cws i2c@ak i2c@ak i2c@ak i2c@nak > > if I want read a variable number of bytes, how I do that? > > My try was a failure ( n = number of bytes ): > > n addr-at24c32 add-read-bit i2cws 1- for i2c@ak next i2c@nak > > Thank You Thomas > > > ------------------------------------------------------------------------------ > 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=267308311&iu=/4140 > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Thomas B. <fla...@bu...> - 2016-01-09 14:05:26
|
I resend the mail, maybe the previous is encrypted ====================================== Hallo, I want read a certain number of eeprom bytes. Here is a snippet to read 4 bytes addr-at24c32 add-read-bit i2cws i2c@ak i2c@ak i2c@ak i2c@nak if I want read a variable number of bytes, how I do that? My try was a failure ( n = number of bytes ): n addr-at24c32 add-read-bit i2cws 1- for i2c@ak next i2c@nak Thank You Thomas |
|
From: Mikael N. <mik...@fl...> - 2016-01-07 17:04:23
|
Something like this comes to mind.
Just an example with some code fragments.
ram
create command 8 allot
create param1 8 allot
create param2 10 allot
: parse-gpgga
4800 baud-set
u0-
tib dup tibsize accept 'source 2! 0 >in !
['] , parse command place \ $GPGGA
['] , parse param1 place
['] , parse param2 place
\ etcetera
;
: parse-nmea
4800 baud-set u0-
begin
parse-gpgga
again
;
\ For autostart
' parse-nmea to turnkey
BR Mikael
On 07.01.2016 11:38, Sven wrote:
> Hi,
> I have a GPS module with serial NMA0183 output ( 4800 8n1 ) and a
> Arduino board with flashforth installed.
> My idea is to read the NMEA data from the Arduino serial interface
> and display it on a LCD, but the serial port is normally used by the
> terminal session of flashforth. Is it possible to detect a NMEA
> sentence like:
> $GPGGA,191410,4735.5634,N,00739.3538,E,1,04,4.4,351.5,M,48.0,M,,*45
> in the input stream and extract and store the data in table for
> example ?
> Any ideas ?
>
> Sven
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
|
|
From: Sven <sve...@ya...> - 2016-01-07 09:55:44
|
Hi, I have a GPS module with serial NMA0183 output ( 4800 8n1 ) and a Arduino board with flashforth installed. My idea is to read the NMEA data from the Arduino serial interface and display it on a LCD, but the serial port is normally used by the terminal session of flashforth. Is it possible to detect a NMEA sentence like: $GPGGA,191410,4735.5634,N,00739.3538,E,1,04,4.4,351.5,M,48.0,M,,*45 in the input stream and extract and store the data in table for example ? Any ideas ? Sven |
|
From: Donald G. <dgo...@sb...> - 2015-11-16 16:47:54
|
I don't think a 32 bit version of FlashForth would be necessary. You can build a very complex application in Forth just using the 16 bit implementation.
If you need a request for extended memory words, I will vote yes they are needed. Users can then put arrays, small databases of sensor data logging, etc. in this space...
I will need these words in the future, myself.
Great job on the design of FlashForth, keep up the good work!Don
On Sunday, November 15, 2015 11:00 AM, Mikael Nordman <mik...@fl...> wrote:
You are right that extended memory words could be made
for data storage or even for code in flash.
But I have chosen not to implement that, since there has been no
demand.
All my FF programs have been fairly compact fitting well within the
16-bit limits.
One reason to support the larger chips is to get access to the
peripherals, even if
all memory cannot be adressed.
Another alternative would be to implement a 32-bit FF. Then all memory
would be adressable.
BR Mikael
On 15.11.2015 19:41, Donald Golding wrote:
> You should have an extended memory word to address all of memory,
> right?
>
> Since this is a 16 bit Forth implementation, it is understandable
> that
> it can only address 64K words. However, we should be able to address
> all of the memory for data in the processor.
>
> I haven't started using FlashForth yet, so my comments are not based
> on knowledge of FlashForth.
>
> Don
>
------------------------------------------------------------------------------
_______________________________________________
Flashforth-devel mailing list
Fla...@li...
https://lists.sourceforge.net/lists/listinfo/flashforth-devel
|
|
From: Mikael N. <mik...@fl...> - 2015-11-15 19:00:09
|
You are right that extended memory words could be made for data storage or even for code in flash. But I have chosen not to implement that, since there has been no demand. All my FF programs have been fairly compact fitting well within the 16-bit limits. One reason to support the larger chips is to get access to the peripherals, even if all memory cannot be adressed. Another alternative would be to implement a 32-bit FF. Then all memory would be adressable. BR Mikael On 15.11.2015 19:41, Donald Golding wrote: > You should have an extended memory word to address all of memory, > right? > > Since this is a 16 bit Forth implementation, it is understandable > that > it can only address 64K words. However, we should be able to address > all of the memory for data in the processor. > > I haven't started using FlashForth yet, so my comments are not based > on knowledge of FlashForth. > > Don > |
|
From: Donald G. <dgo...@sb...> - 2015-11-15 17:54:49
|
You should have an extended memory word to address all of memory, right?
Since this is a 16 bit Forth implementation, it is understandable that it can only address 64K words. However, we should be able to address all of the memory for data in the processor.
I haven't started using FlashForth yet, so my comments are not based on knowledge of FlashForth.
Don
On Saturday, November 14, 2015 8:08 AM, Mikael Nordman <mik...@fl...> wrote:
By design FlashForth can only address 64 Kbytes of memory.
FF maps flash, ram and eeprom into one 16-bit address space.
@ and ! can then be used with all types of memory.
The free flash should be about 45 Kbytes on chips that have 8 K ram and
4 K eeprom.
The FF kernel size is 8,5 Kbytes.
The mega1284 has 16 K of ram so only 36 K is left as free flash memory.
BR Mikael
------------------------------------------------------------------------------
_______________________________________________
Flashforth-devel mailing list
Fla...@li...
https://lists.sourceforge.net/lists/listinfo/flashforth-devel
|
|
From: Mikael N. <mik...@fl...> - 2015-11-14 16:08:14
|
By design FlashForth can only address 64 Kbytes of memory. FF maps flash, ram and eeprom into one 16-bit address space. @ and ! can then be used with all types of memory. The free flash should be about 45 Kbytes on chips that have 8 K ram and 4 K eeprom. The FF kernel size is 8,5 Kbytes. The mega1284 has 16 K of ram so only 36 K is left as free flash memory. BR Mikael |
|
From: Ronny S. <man...@te...> - 2015-11-14 11:39:09
|
Hi I'm new to flashforth , but not new to forth. I have this question: I have downloaded the 'free.txt' program included in the forth directory. I notice on an atmega2560 that there is only about 45kbytes free , and on the mega1284p only 35kbytes (approx.) This is strange to me because the atmega2560 has 256kbytes flash and the atmega1284 has 128kbytes flash. The ram and eeprom free spaces look correct. What am I overlooking ??? Kind regards , Ronny Suy |
|
From: Pete Z. <pza...@pz...> - 2015-10-29 16:22:26
|
Hi Mikael, Thanks for all the help and the changes to FF5.0 for Operator UARTx selection. For general information: I now have the latest FF running on the pic24f32ka302 on both Microchip development boards, DM300027 and DM240311. UART2 works fine and the pic24f32ka302 works with either the on-board XTAL or the on-chip FRC. I used MPLAB v8.92 and a PICKit3. I am using the RS232 serial port on the DM240311 because the USB to RS232 MCP2200 on the board appears to be in the data invert mode and is not able to be changed with the MCP2200 configuration software I have. Pete |
|
From: Mikael N. <mik...@fl...> - 2015-10-24 18:54:42
|
<div style="font-size:10pt;"><p style="margin-top:0;margin-bottom:0;">Hi Pete</p><p style="margin-top:0;margin-bottom:0;"> </p><p style="margin-top:0;margin-bottom:0;">I just pushed support for configuring the operator uart. Not tested on real hw yet.</p><p style="margin-top:0;margin-bottom:0;"> </p><p style="margin-top:0;margin-bottom:0;">git pull</p><p style="margin-top:0;margin-bottom:0;"> </p><p style="margin-top:0;margin-bottom:0;">Best wishes</p><p style="margin-top:0;margin-bottom:0;">Mikael</p><p style="margin-top:0;margin-bottom:0;"> </p> <pre> </pre></div> |
|
From: Pete Z. <pza...@pz...> - 2015-10-24 16:02:09
|
Hi Mikael and Peter, Have either of you tried using UART2 on the pic24f32ka302 or picf16ka102 ? Can the terminal communications be shifted from u1tx/u1rx pins to u2tx/u2rx pins easily ? Especially looking to use these chips on the Microchip 16-bit nano-Watt XLP board (DN243011) for development. Pete |
|
From: Peter J. <pe...@me...> - 2015-10-15 12:47:19
|
Mikael,
I've been using ff-shell.tcl a quite bit lately and have made a
small adjustment to improve the display when the microcontroller is
sending back a lot of text without any new-line characters. The older
version would not update to display the end of the text widget until a
new-line was received. Now the update occurs every so many characters
or on receipt of a new-line character. Revised program is attached.
Cheers,
Peter J.
|
|
From: Peter J. <pe...@me...> - 2015-10-13 10:27:11
|
Thank you. Your suggestion worked nicely.
chan 1 0.0 Pa chan 2 88.2 Pa ok<#,ram>
ok<#,ram>
' main is turnkey ok<#,ram>
ok<#,ram>
ok<#,ram>
ok<#,ram>
S FlashForth PIC24 03.09.2015
ESC
chan 1 0.0 Pa chan 2 88.2 Pa
chan 1 0.0 Pa chan 2 88.2 Pa
chan 1 0.0 Pa chan 2 88.2 Pa
chan 1 0.0 Pa chan 2 88.2 Pa
chan 1 0.0 Pa chan 2 88.2 Pa
chan 1 0.0 Pa chan 2 88.2 Pa
chan 1 0.0 Pa chan 2 88.2 Pa
Cheers,
Peter J.
On 13/10/15 15:06, Mikael Nordman wrote:
> There seems to be some problem with WRITE_METHOD 2, it writes to EEPROM
> but after a long delay.
>
> Try using WRITE_METHOD 1 setting in the config file.
> Works for me on a PIC24FV32KA302.
>
> BR Mikael
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
|
|
From: Mikael N. <mik...@fl...> - 2015-10-13 05:39:48
|
There seems to be some problem with WRITE_METHOD 2, it writes to EEPROM but after a long delay. Try using WRITE_METHOD 1 setting in the config file. Works for me on a PIC24FV32KA302. BR Mikael |
|
From: Peter J. <pe...@me...> - 2015-10-12 21:19:36
|
Mikael,
I have a pressure monitoring program for a small wind tunnel that is
running nicely on a PIC24FV32KA301. Now, I want to make it start at
power up but the turnkey vector does not seem to be working.
chan 1 0.0 Pa chan 2 480.2 Pa
chan 1 0.0 Pa chan 2 480.2 Pa
chan 1 0.0 Pa chan 2 480.2 Pa ok<#,ram>
main
chan 1 0.0 Pa chan 2 480.2 Pa
chan 1 0.0 Pa chan 2 480.2 Pa
chan 1 0.0 Pa chan 2 480.2 Pa
chan 1 0.0 Pa chan 2 480.2 Pa ok<#,ram>
' main is turnkey ok<#,ram>
S FlashForth PIC24 03.09.2015
ok<#,ram>
ok<#,ram>
Suggestions?
Regards,
Peter Jacobs
|
|
From: Peter J. <pe...@me...> - 2015-09-04 01:19:37
|
It seems to be working fine on the PIC24FV16KM202 that I have on the desk here. Thank you. Peter J. On 04/09/15 05:44, Mikael Nordman wrote: > I checked in some further improvements for the FK series. > > The Interrupt vectors are moved from ram to flash, freeing up 256 bytes > of the 1 to 2 K of ram on these chips. > > And there is a new word INT/ ( vector-no -- ) that restores the > original vector > in the alternate table if you happen write some crap into the table. > > Hope I did not break anything. > BR Mike > > On 03.09.2015 15:32, Peter Jacobs wrote: >> Mike, >> I am extra pleased this evening... >> >> By adding SOSCSRC_DIG to the __FOSCSEL setting, I now get control of >> RA4 >> and RB4 as digital outputs. Of course this is completely >> unsurprising >> but it is something that I haven't been able do for the past year >> from >> within FF. I had been able to do so from within a C program on the >> very >> same chips. >> >> There has to be something dodgy with the XC16-supplied macro (or the >> assembler handling of it) for setting the config words on the >> K-series >> chips. >> > > ------------------------------------------------------------------------------ > Monitor Your Dynamic Infrastructure at Any Scale With Datadog! > Get real-time metrics from all of your servers, apps and tools > in one place. > SourceForge users - Click here to start your Free Trial of Datadog now! > http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2015-09-03 19:44:39
|
I checked in some further improvements for the FK series. The Interrupt vectors are moved from ram to flash, freeing up 256 bytes of the 1 to 2 K of ram on these chips. And there is a new word INT/ ( vector-no -- ) that restores the original vector in the alternate table if you happen write some crap into the table. Hope I did not break anything. BR Mike On 03.09.2015 15:32, Peter Jacobs wrote: > Mike, > I am extra pleased this evening... > > By adding SOSCSRC_DIG to the __FOSCSEL setting, I now get control of > RA4 > and RB4 as digital outputs. Of course this is completely > unsurprising > but it is something that I haven't been able do for the past year > from > within FF. I had been able to do so from within a C program on the > very > same chips. > > There has to be something dodgy with the XC16-supplied macro (or the > assembler handling of it) for setting the config words on the > K-series > chips. > |
|
From: Peter J. <pe...@me...> - 2015-09-03 12:32:55
|
Mike, I am extra pleased this evening... By adding SOSCSRC_DIG to the __FOSCSEL setting, I now get control of RA4 and RB4 as digital outputs. Of course this is completely unsurprising but it is something that I haven't been able do for the past year from within FF. I had been able to do so from within a C program on the very same chips. There has to be something dodgy with the XC16-supplied macro (or the assembler handling of it) for setting the config words on the K-series chips. Cheers, Peter J. On 03/09/15 08:57, Peter Jacobs wrote: > Very nice. You've made my day. > I've now had it running on PIC24FV32KA302 and PIC24FV16KM202, with the > bonus that the PLL is running. > > ok<#,ram> > ok<#,ram> > warm S FlashForth PIC24 01.09.2015 > > $0742 constant osccon ok<#,ram> > bin ok<%,ram> > osccon @ u. 1000100110000 ok<%,ram> > decimal ok<#,ram> > Fcy u. 16000 ok<#,ram> > > I see your comment in the pic24fk_config.inc file that the normal config > macros did not work. > That may have been my problem with the PLL for a long time now. > For the first time on these chips, I can see the PLL lock bit set while > FF is running. > > Cheers, > Peter J. > > > On 02/09/15 22:13, Mikael Nordman wrote: >> Actually the files are not missing, and should not be needed. >> >> It is only the MPLABX project that is referring to those obsolete >> files. >> >> I was very happy to find a setup the only needs one config file for all >> the K chips. >> >> There was evidence of some incompatible NVMCON settings for some chips. >> It turned out to be a fault in the old version of the datasheet. >> >> I need to commit correct project files. >> >> BR Mikael >> >> On 02.09.2015 14:43, Peter Jacobs wrote: >>> Almost, yes. The two new config files are missing from your commit, >>> I >>> think. >>> >>> Error: Project "FF" refers to file "p24fka_config.inc" which does not >>> exist in the disk. The project failed to load. >>> Error: Project "FF" refers to file "p24fkm_config.inc" which does not >>> exist in the disk. The project failed to load. >>> >>> Regards, >>> Peter J. >>> >>> >> ------------------------------------------------------------------------------ >> Monitor Your Dynamic Infrastructure at Any Scale With Datadog! >> Get real-time metrics from all of your servers, apps and tools >> in one place. >> SourceForge users - Click here to start your Free Trial of Datadog now! >> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 >> _______________________________________________ >> Flashforth-devel mailing list >> Fla...@li... >> https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > ------------------------------------------------------------------------------ > Monitor Your Dynamic Infrastructure at Any Scale With Datadog! > Get real-time metrics from all of your servers, apps and tools > in one place. > SourceForge users - Click here to start your Free Trial of Datadog now! > http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Peter J. <pe...@me...> - 2015-09-02 22:57:17
|
Very nice. You've made my day. I've now had it running on PIC24FV32KA302 and PIC24FV16KM202, with the bonus that the PLL is running. ok<#,ram> ok<#,ram> warm S FlashForth PIC24 01.09.2015 $0742 constant osccon ok<#,ram> bin ok<%,ram> osccon @ u. 1000100110000 ok<%,ram> decimal ok<#,ram> Fcy u. 16000 ok<#,ram> I see your comment in the pic24fk_config.inc file that the normal config macros did not work. That may have been my problem with the PLL for a long time now. For the first time on these chips, I can see the PLL lock bit set while FF is running. Cheers, Peter J. On 02/09/15 22:13, Mikael Nordman wrote: > Actually the files are not missing, and should not be needed. > > It is only the MPLABX project that is referring to those obsolete > files. > > I was very happy to find a setup the only needs one config file for all > the K chips. > > There was evidence of some incompatible NVMCON settings for some chips. > It turned out to be a fault in the old version of the datasheet. > > I need to commit correct project files. > > BR Mikael > > On 02.09.2015 14:43, Peter Jacobs wrote: >> Almost, yes. The two new config files are missing from your commit, >> I >> think. >> >> Error: Project "FF" refers to file "p24fka_config.inc" which does not >> exist in the disk. The project failed to load. >> Error: Project "FF" refers to file "p24fkm_config.inc" which does not >> exist in the disk. The project failed to load. >> >> Regards, >> Peter J. >> >> > > ------------------------------------------------------------------------------ > Monitor Your Dynamic Infrastructure at Any Scale With Datadog! > Get real-time metrics from all of your servers, apps and tools > in one place. > SourceForge users - Click here to start your Free Trial of Datadog now! > http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2015-09-02 12:13:57
|
Actually the files are not missing, and should not be needed. It is only the MPLABX project that is referring to those obsolete files. I was very happy to find a setup the only needs one config file for all the K chips. There was evidence of some incompatible NVMCON settings for some chips. It turned out to be a fault in the old version of the datasheet. I need to commit correct project files. BR Mikael On 02.09.2015 14:43, Peter Jacobs wrote: > Almost, yes. The two new config files are missing from your commit, > I > think. > > Error: Project "FF" refers to file "p24fka_config.inc" which does not > exist in the disk. The project failed to load. > Error: Project "FF" refers to file "p24fkm_config.inc" which does not > exist in the disk. The project failed to load. > > Regards, > Peter J. > > |
|
From: Peter J. <pe...@me...> - 2015-09-02 11:44:04
|
Almost, yes. The two new config files are missing from your commit, I think. Error: Project "FF" refers to file "p24fka_config.inc" which does not exist in the disk. The project failed to load. Error: Project "FF" refers to file "p24fkm_config.inc" which does not exist in the disk. The project failed to load. Regards, Peter J. On 02/09/15 04:42, Mikael Nordman wrote: > Now FF should compile and work also with the PIC24F(V)KA KM and KL > chips. ! > > BR Mikael > > On 01.09.2015 20:47, Mikael Nordman wrote: >> Todays FF finally works with the PIC24FV32KA302. >> The PMD4 disabled the eeprom which was not good :-) >> It was not easy to find that bug, so for now all peripherals are left >> powered at startup. >> >> For PIC24FV16KM202 the ff30.inc include file and a new device cinfig >> file is needed. >> >> BR Mike > > ------------------------------------------------------------------------------ > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2015-09-01 18:42:45
|
Now FF should compile and work also with the PIC24F(V)KA KM and KL chips. ! BR Mikael On 01.09.2015 20:47, Mikael Nordman wrote: > Todays FF finally works with the PIC24FV32KA302. > The PMD4 disabled the eeprom which was not good :-) > It was not easy to find that bug, so for now all peripherals are left > powered at startup. > > For PIC24FV16KM202 the ff30.inc include file and a new device cinfig > file is needed. > > BR Mike |
17 messages has been excluded from this view by a project administrator.
