flashforth-devel Mailing List for FlashForth: for PIC and Atmega (Page 13)
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...> - 2017-12-29 08:00:45
|
Here's one gotcha.
The division code relies on FSR1H beeing 4 bits.
clrf DCNT, A ; count to 16; 19
UMSLASHMOD1:
change to
movlw d'16'
movwf DCNT
UMSLASHMOD1:
BR Mike
|
|
From: Mikael N. <mik...@fl...> - 2017-12-29 07:33:28
|
Interesting chip. I did a quick test on a 14k50 and moved it, works out of the box. IRQ_STACK udata irq_s0 res PARAMETER_STACK_SIZE_IRQ ; Multiple of h'10'. Interrupt parameter stack. flash_buf res 0x40 hex ok<$,ram> f070 40 dump f070 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ f080 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ f090 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ f0a0 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ok<$,ram> : tt 1 ; ok<$,ram> f070 40 dump f070 :e4 21 82 74 74 ff 01 0e ec 6e ec 6a 12 00 ff ff .!.tt....n.j.... f080 :ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ f090 :ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ f0a0 :ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ ok<$,ram> tt . 1 ok<$,ram> see tt 2306 0e01 movlw 01 2308 6eec movwf (+sp) a 230a 6aec clrf (+sp) a 230c 0012 return ok<$,ram> In addition all the hardcoded constants (0xC0 0x3F) should be parameterized with symbolic constants. These can be found in the flash write code and in I@ I! IC@ IC!. BTW, There is a ff51 branch in git which you could base your changes on. It will soon be the latest master code. It uses FSR2 as return stack pointer for R> >R R@ and for saving the HW stack to the user area in PAUSE. see >r 0f3e cfed movff (sp-) (+rp) 0f42 cfed movff (sp-) (+rp) 0f46 0012 return BR Mike On 2017-12-29 04:41, Peter Jacobs wrote: > Mike, > > I have been looking into the changes needed for running FF on a > PIC18F26K42 microcontroller. It seems that most of the changes will > be just to a few of the configuration parameters (like changing the > EEPROM and RAM prefixes to bc00h and c000h, respectively, to allow the > 14-bit data space address) but I've come to a halt when I see that the > K42 family has 128 bytes of flash write latches per row. The current > flash_buf is hard-coded to 64 bytes and lives in access memory, as I > understand the code. Could the FLASH_BUF section be moved to udata, > after the other access variable reservations and just before the > IRQ_STACK section? Are there implications for doing so? > > Regards, > > Peter J. > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel -- -- Mikael |
|
From: Peter J. <pe...@me...> - 2017-12-29 02:55:56
|
Mike, I have been looking into the changes needed for running FF on a PIC18F26K42 microcontroller. It seems that most of the changes will be just to a few of the configuration parameters (like changing the EEPROM and RAM prefixes to bc00h and c000h, respectively, to allow the 14-bit data space address) but I've come to a halt when I see that the K42 family has 128 bytes of flash write latches per row. The current flash_buf is hard-coded to 64 bytes and lives in access memory, as I understand the code. Could the FLASH_BUF section be moved to udata, after the other access variable reservations and just before the IRQ_STACK section? Are there implications for doing so? Regards, Peter J. |
|
From: Mikael N. <mik...@fl...> - 2017-12-20 21:01:18
|
This issue has been fixed and pushed to git and to the downloadable zip file. M. >> On 2017-12-18 11:44, Pablo Munoz wrote: >>> After some investigation, I have found that the problem is caused by >>> these instructions inside WARM: >>> >>> clrf TRISC, A >>> clrf LATC, A |
|
From: Mikael N. <mik...@fl...> - 2017-12-18 12:42:42
|
Or then I just did not notice, since I was focused on debugging the new USB driver and I did not use the UART. Actually the data sheets of 18F2550 and 18F14K50 mentions that the UART PINS TRIS bits should be set to 1. M. On 2017-12-18 13:17, Mikael Nordman wrote: > Hi. > Those were left there by mistake. The PORTC was used for debug leds. > The chips I use (18F2550 and 18F14K50) did not have your problem, so I > did not notice it. > > I will fix this in the next update. > > BR M. > > On 2017-12-18 11:44, Pablo Munoz wrote: >> After some investigation, I have found that the problem is caused by >> these instructions inside WARM: >> >> clrf TRISC, A >> clrf LATC, A -- -- Mikael |
|
From: Mikael N. <mik...@fl...> - 2017-12-18 11:51:16
|
Hi. Those were left there by mistake. The PORTC was used for debug leds. The chips I use (18F2550 and 18F14K50) did not have your problem, so I did not notice it. I will fix this in the next update. BR M. On 2017-12-18 11:44, Pablo Munoz wrote: > After some investigation, I have found that the problem is caused by > these instructions inside WARM: > > clrf TRISC, A > clrf LATC, A |
|
From: Pablo M. <ea...@ho...> - 2017-12-18 09:44:49
|
Hello,
I have recently compiled FF for a 18F26K20, using the last source code (ff-pic18.asm - 07.10.2017).
After power-up, the PIC sends the correct message ("FlashForth 5 PIC18F26K20 07.10.2017"). But when sending caracters from the terminal to the PIC there is no echo and no response to commands.
After some investigation, I have found that the problem is caused by these instructions inside WARM:
clrf TRISC, A
clrf LATC, A
Writing 0 to TRISC makes the pin RXD an output, so the UART can't receive. >From the datasheet:
For all modes of EUSART operation, the TRIS control
bits corresponding to the RX/DT and TX/CK pins should
be set to ‘1’. The EUSART control will automatically
reconfigure the pin from input to output, as needed.
I have commented the instructions and now everything works as expected.I suspect that this problem also affects other members of the family.
Previous versions of ff-pic18.asm didn't have these two lines of code (at least they were not included in version 19.01.2015). I would like to know what is its purpose.
Regards,
73, Pablo - EA4FUK
|
|
From: Aymeric <ult...@bl...> - 2017-09-23 21:02:56
|
Mikael Nordman said :
> It may help also on the real hardware.
It did! It's working now :) Thanks!
So to sum up:
diff --git a/avr/src/config.inc b/avr/src/config.inc
index 21f6bff..fc5a359 100644
--- a/avr/src/config.inc
+++ b/avr/src/config.inc
@@ -4,9 +4,10 @@
;.include "m2561def.inc" ;
;.include "m2560def.inc" ; Tested Fuses: E:0xff H:0xdc L:0xff
;.include "m128def.inc" ; Tested Fuses: E:0xff H:0xdc L:0xff
+.include "m168def.inc" ; Tested Fuses: E:0xf8 H:0xdf L:0xff
;.include "m168pdef.inc"
;.include "m328pdef.inc" ; Tested Fuses: E:0xff H:0xda L:0xff
-.include "m328def.inc" ; Tested Fuses: E:0xff H:0xda L:0xff
+;.include "m328def.inc" ; Tested Fuses: E:0xff H:0xda L:0xff
;.include "m32adef.inc"
;.include "m644pdef.inc"
diff --git a/avr/src/ff-atmega.asm b/avr/src/ff-atmega.asm
index 555e5c2..61dd095 100644
--- a/avr/src/ff-atmega.asm
+++ b/avr/src/ff-atmega.asm
@@ -5340,7 +5340,7 @@ WARM_1:
ldi xl, 0x1C ; clear ram from y register upwards
WARM_2:
st x+, r_zero
- cpi xh, 0x10 ; up to 0xfff, 4 Kbytes
+ cpi xh, 0x04 ; up to 0x3ff, 1 Kbytes
brne WARM_2
; Init empty flash buffer
I will play a bit with it now...
Aymeric
|
|
From: Mikael N. <mik...@fl...> - 2017-09-22 09:20:22
|
At least in AVRSIM2 the XH register in the code sequence
below fails count over 0x08 on the 168p.
So FF gets stuck in an infinite loop just at the startup.
Even if XH is a 16 bit regsister.
In atmega source file
Try replacing this
WARM_2:
st x+, r_zero
cpi xh, 0x10 ; up to 0xfff, 4 Kbytes
brne WARM_2
With THIS:
WARM_2:
st x+, r_zero
cpi xh, 0x04 ; up to 0x3ff, 1 Kbytes
brne WARM_2
It may help also on the real hardware.
BR Mikael
On 2017-09-22 00:28, Aymeric wrote:
>
> Is there anything else I could try? Or should I just get an Arduino
> that
> is already supported/tested?
>
> Thanks!
> Aymeric
|
|
From: Peter C. H. <Pet...@un...> - 2017-09-22 07:40:14
|
Some of the upper bits of the fuse bytes are not actually used, so it does not really matter what is set for those. However, avrdude reads back all bits after setting them and compares them to what they were supposed to be set as. If it does not agree an error message is created. Apparently at one stage the way avrdude reads back the not used bits was changed. So, if I remember this correctly, for older versions the lock byte has to be written as FF, but for newer versions of avrdude it has to be 3F, to prevent the error message. The actual setting is the same. Cost me a lot of time…. Peter > On 21 Sep 2017, at 23:28, Aymeric <ult...@bl...> wrote: > > Aymeric said : >> Mikael Nordman said : >>> How did you set the fuses ? That is the first thing to check. >>> The fuses must be set to BOOTSIZE=1024 words and the BOOTRESET should be >>> active. >>> >>> [..] >>> >>> I think these fuses should work for the 168. >>> >>> avrdude -p m168 -c usbtiny -e -u -U flash:w:ff-atmega.hex:i -U >>> efuse:w:0xf8:m -U hfuse:w:0xff:m -U lfuse:w:0xff:m >> >> I cannot set SPIEN to 0 on this board, so I used this: >> >> -U lfuse:w:0xFF:m -U hfuse:w:0xDF:m -U efuse:w:0xF8:m >> >> Unfortunately I still do not get anything when I try to connect with >> screen. > > I gave it another try and this time I could set the hfuse to FF, I don't > understand why it did not work last time (it was on another machine, > with another version of avrdude though...). However I still end up with > a blank screen. > > Is there anything else I could try? Or should I just get an Arduino that > is already supported/tested? > > Thanks! > Aymeric > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Aymeric <ult...@bl...> - 2017-09-21 21:29:13
|
Aymeric said : > Mikael Nordman said : > > How did you set the fuses ? That is the first thing to check. > > The fuses must be set to BOOTSIZE=1024 words and the BOOTRESET should be > > active. > > > > [..] > > > > I think these fuses should work for the 168. > > > > avrdude -p m168 -c usbtiny -e -u -U flash:w:ff-atmega.hex:i -U > > efuse:w:0xf8:m -U hfuse:w:0xff:m -U lfuse:w:0xff:m > > I cannot set SPIEN to 0 on this board, so I used this: > > -U lfuse:w:0xFF:m -U hfuse:w:0xDF:m -U efuse:w:0xF8:m > > Unfortunately I still do not get anything when I try to connect with > screen. I gave it another try and this time I could set the hfuse to FF, I don't understand why it did not work last time (it was on another machine, with another version of avrdude though...). However I still end up with a blank screen. Is there anything else I could try? Or should I just get an Arduino that is already supported/tested? Thanks! Aymeric |
|
From: craig b. <dab...@ya...> - 2017-09-20 20:50:30
|
Good thoughts! Thank you very much! Actually, editing hex images was one of our tricks back in the day (for a while I could sight-read 6502 hex). I REALLY like flash because I don't need a UV lamp to reprogram it. I've long kept a chip from every project with no read protection in case both the source code and the hex image for programming get lost. I'll go looking for STARTV, play around a bit and see what I can come up with. Thanks again! craig -------------------------------------------- On Wed, 9/20/17, Mikael Nordman <mik...@fl...> wrote: Subject: Re: [Flashforth-devel] Pic18 change system protection addresses? To: fla...@li... Date: Wednesday, September 20, 2017, 2:16 PM I think your analysis is fine, but what to do about it ? The protect system is hardcoded so you cannot circumvent it without changing the FF kernel. I have never tried dumping FF from a chip an reprogramming the image. I quess you can poke in the numbers to the hex image after the dumping it out. Look for STARTV: in the source. There you have 6 words that is used by EMPTY. ;;; EMPTY dictionary data STARTV: dw h'0000' DPC: dw dpcode ; dp_user_dictionary DPE: dw dpeeprom DPD: dw dpdata+h'f000' LW: dw lastword STAT: dw DOTSTATUS I quess you can get a map or listing file to tell you the addresses. The data you need to move there is the first 6 words in eeprom. Or a kernel word SNAP could be contructed to set the pointers used by EMPTY. Those could also be stored in eeprom. (Just because I dont like to write to kernel flash. And have another word TRULYEMPTY that works like the EMPTY of today. Or make a word ALMOSTEMPTY that gets you back to the SNAP status. Actually it not that simple... The kernel and the user words are in separate lists. So FORGET would anyway be able to forget all user dictionary words. FORGET would need to check that does not forget below the SNAPped dictionary pointer. ------------ But the above is almost the same as defining marker eeprom 0 value bla marker calibration : blu . ... ; marker basicwords : asdf ; marker appwords : akajshdk ; 59 to bla except it requires some discipline, that you don't actually use EMPTY. Changing EMPTY to some random string would fix that :-) Since the values already exist in the dictionary, reinitialization of the values will be skipped if you send a file to FF. So the fast solution is to have the special values defined in the start of the dictionary + marker, just as you suggest. No need to mess with forget. Using forget will always mess up the system. ----------- You could create another type of defining word called cal: ( address 'name' -- ) // define a uninitialized value at address. : cal: flash create -2 dp +! i, ram does> @ ; Modify this row in the FF source code DPE: dw dpeeprom by increasing the number protected EEPROM words (dpeeprom + EXTRA) There you can use as EXTRA number of bytes starting at $ec0c for unforgettable calibration data :-) Or just use adresses at end of eeprom or end of flash, and hope no one ever allots that far. hex ok<$,ram> ec50 cal: cal1 ok<$,ram> cal1 ok<$,ram>ffff 45 to cal1 ok<$,ram>ffff cal1 ok<$,ram>ffff 45 ec50 @ ok<$,ram>ffff 45 45 So now your cal: values always uses TO to init the values. BR Mikael ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Flashforth-devel mailing list Fla...@li... https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2017-09-20 18:16:42
|
I think your analysis is fine, but what to do about it ? The protect system is hardcoded so you cannot circumvent it without changing the FF kernel. I have never tried dumping FF from a chip an reprogramming the image. I quess you can poke in the numbers to the hex image after the dumping it out. Look for STARTV: in the source. There you have 6 words that is used by EMPTY. ;;; EMPTY dictionary data STARTV: dw h'0000' DPC: dw dpcode ; dp_user_dictionary DPE: dw dpeeprom DPD: dw dpdata+h'f000' LW: dw lastword STAT: dw DOTSTATUS I quess you can get a map or listing file to tell you the addresses. The data you need to move there is the first 6 words in eeprom. Or a kernel word SNAP could be contructed to set the pointers used by EMPTY. Those could also be stored in eeprom. (Just because I dont like to write to kernel flash. And have another word TRULYEMPTY that works like the EMPTY of today. Or make a word ALMOSTEMPTY that gets you back to the SNAP status. Actually it not that simple... The kernel and the user words are in separate lists. So FORGET would anyway be able to forget all user dictionary words. FORGET would need to check that does not forget below the SNAPped dictionary pointer. ------------ But the above is almost the same as defining marker eeprom 0 value bla marker calibration : blu . ... ; marker basicwords : asdf ; marker appwords : akajshdk ; 59 to bla except it requires some discipline, that you don't actually use EMPTY. Changing EMPTY to some random string would fix that :-) Since the values already exist in the dictionary, reinitialization of the values will be skipped if you send a file to FF. So the fast solution is to have the special values defined in the start of the dictionary + marker, just as you suggest. No need to mess with forget. Using forget will always mess up the system. ----------- You could create another type of defining word called cal: ( address 'name' -- ) // define a uninitialized value at address. : cal: flash create -2 dp +! i, ram does> @ ; Modify this row in the FF source code DPE: dw dpeeprom by increasing the number protected EEPROM words (dpeeprom + EXTRA) There you can use as EXTRA number of bytes starting at $ec0c for unforgettable calibration data :-) Or just use adresses at end of eeprom or end of flash, and hope no one ever allots that far. hex ok<$,ram> ec50 cal: cal1 ok<$,ram> cal1 ok<$,ram>ffff 45 to cal1 ok<$,ram>ffff cal1 ok<$,ram>ffff 45 ec50 @ ok<$,ram>ffff 45 45 So now your cal: values always uses TO to init the values. BR Mikael |
|
From: craig b. <dab...@ya...> - 2017-09-20 14:12:44
|
I've built one of our in-house tools around a PIC 18F46K22 and FlashForth 5.0 just because I think a smart user should be able to tweak their tool to do what they want it to do. This actually hasn't worked out badly except that I'm now getting the occasional complaint that whenever they have to fully re-load the programs for whatever reason; they have to replace the calibration numbers that were stored in eeprom. (They get re-initialized when declared as eeprom "value".) I completely understand and agree with the design decisions that led to ram and eeprom "here" pointers only being reset by an "empty" and not by "forget", but I need a work-around of some sort for this problem. My first and worst idea was to put all of the ram and eeprom allocations at the start (like cobol) and then just use "forget" with a marker after them. The snag is that anything after that point that allocates memory other that flash will have to be separated out and moved to the top and the marker moved. Messy, clumsy, and prone to error when trying to maintain. The next thought was to still use the "empty" but start the load off by checking the eeprom "here" address to see whether the location was initialized or blank. If blank, the eeprom values could be assigned and allocated normally. If already initialized, the named could be re-established using a variant of "value" that just didn't store anything to the locations. Once done with that the clean re-load could proceed normally. What seems the best approach to me would be a word that could be invoked after the driver extensions and calibration allocations were loaded the first time that would update the default pointers to make them part of the base protected system. A hex image could then be saved for programming a new chip and the old one could have as many reloads as it could stand without unnecessary re-calibration. So, have I analyzed the problem correctly? How many things would I need to chase down in the disassembly to change the system self-defense? The final state of the pointers and where they get their power-up initializations from aren't obvious to me from reading the assembler code, but I know they have to be there. Thanks for your time and any thoughts you might have on this matter, Craig Bair, binary behaviorist |
|
From: Mikael N. <mik...@fl...> - 2017-09-19 04:30:45
|
Hi, This what I use on linux. I do all my development on Linux :-) wine avrasm2/avrasm2.exe -I avrasm2/inc -o ff.hex -l ff.lst -m ff.map -fI avr/src/ff-atmega.asm avrdude -p m328 -c stk500 -P /dev/ttyACM1 -e -u -U flash:w:ff.hex:i -U efuse:w:0xff:m -U hfuse:w:0xda:m -U lfuse:w:0xff:m avrdude -p m2560 -c stk500 -P /dev/ttyACM0 -e -u -U flash:w:ff.hex:i -U efuse:w:0xff:m -U hfuse:w:0xdc:m -U lfuse:w:0xff:m You can get the exe and include files from here. https://sourceforge.net/projects/amforth/files/Atmel-AVR8-Assembler/ BR Mikael |
|
From: <my...@po...> - 2017-09-18 18:52:59
|
Hello, This is my first post to this mailing list. A few month ago I started using/programming Arduino and ATmegas (328/2560). I heard and experimented with FORTH on the Atari 800 a little and later I was fascinated how different (in the positive meaning) FORTH is from other languages. What follows was a LLOOOONNNGGG pause of a FORTHless time. Now I found FlashForth for the Atmegas (and PICS, but I am an avr-guy)...OH HAPPY DAY! I am exclusively working on and with Linux. I am a friend of the "small and powerful" categorie of devices, so I have a couple of Arduino ProMinis (3.3V 8MHz) here, which I want to FORTHiefy. >From the docs I remember, that the provided hex-file was made for a 5V Arduino UNO R3 running at 16MHz and one needs to recompile FlashForth for other setups. And I read, that recompiling Forth needs ATMEL Studio...which is not available for Linux as far as I know... Linux uses avr-gcc instead (not as an IDE...as a compiler ;))))) My first question is: Is there another way than wine or VirtualBox + WIndows (which I dont own and dont want) to modify and compile Flash on a pure Linux sustem? Thanks a lot for FlashForth and for any help in advance! Cheers Meino PS: My former mail to this list was sent from the wrong mail account 'tu...@po...' ... please excuse my fault. |
|
From: Aymeric <ult...@bl...> - 2017-09-01 21:47:26
|
(sorry used wrong email to send my reply) Hello Mikael, thanks for the quick reply! Mikael Nordman said : > How did you set the fuses ? That is the first thing to check. > The fuses must be set to BOOTSIZE=1024 words and the BOOTRESET should be > active. > > [..] > > I think these fuses should work for the 168. > > avrdude -p m168 -c usbtiny -e -u -U flash:w:ff-atmega.hex:i -U > efuse:w:0xf8:m -U hfuse:w:0xff:m -U lfuse:w:0xff:m I cannot set SPIEN to 0 on this board, so I used this: -U lfuse:w:0xFF:m -U hfuse:w:0xDF:m -U efuse:w:0xF8:m Unfortunately I still do not get anything when I try to connect with screen. Aymeric. |
|
From: Mikael N. <mik...@fl...> - 2017-09-01 19:46:49
|
I think these fuses should work for the 168.
BR M
avrdude -p m168 -c usbtiny -e -u -U flash:w:ff-atmega.hex:i -U
efuse:w:0xf8:m -U hfuse:w:0xff:m -U lfuse:w:0xff:m
|
|
From: Mikael N. <mik...@fl...> - 2017-09-01 18:45:58
|
Hi, I have never tested the 168, so I don't really know if it works or not. It is of the same family as the 328, so I have assumed it works. How did you set the fuses ? That is the first thing to check. The fuses must be set to BOOTSIZE=1024 words and the BOOTRESET should be active. BR M |
|
From: Aymeric <ult...@bl...> - 2017-09-01 16:06:21
|
Hello! I've successfully put FlashForth on a Arduino UNO, and I am now trying to do the same with the older Arduino Diecimila (ATMEGA168-20PU). The FlashForth distribution does not come with an .hex file for it, so I'm trying to generate one with avrasm2 2.1.52 found on the amforth sourceforge file repos. However I am failing to connect to FlashForth, and I am unsure why as I am not very familiar with AVR and Arduino in general. The steps are: 1. edit config.inc and add the line: .include "m168def.inc" 2. run avrasm2: wine avrasm2.exe -I /path/to/include -fI ff-atmega.asm I get some warnings: ff-atmega.asm(78): warning: Register r26 already defined by the .DEF directive ff-atmega.asm(79): warning: Register r27 already defined by the .DEF directive ff-atmega.asm(80): warning: Register r30 already defined by the .DEF directive ff-atmega.asm(81): warning: Register r31 already defined by the .DEF directive ff-atmega.asm(244): warning: Use of undefined or forward referenced symbol 'TX0_' in .equ/.set ff-atmega.asm(245): warning: Use of undefined or forward referenced symbol 'RX0_' in .equ/.set ff-atmega.asm(246): warning: Use of undefined or forward referenced symbol 'RX0Q' in .equ/.set 3. run avrdude: avrdude -p m168 -c usbtiny -e -u -U flash:w:ff-atmega.hex:i -U efuse:w:0xff:m -U hfuse:w:0xdc:m -U lfuse:w:0xff:m 4. connect with screen: screen /dev/cuaU0 9600 Instead of getting the FlashForth prompt like I do with the Arduino UNO, I have an empty screen and nothing seems to happen. Am I doing something wrong or is the ATMEGA168-20PU not fit for FlashForth? Thanks! Aymeric. |
|
From: Bernd D. <be...@da...> - 2017-07-18 07:20:23
|
Thank you, I'll try it out --Bernd Am 2017-07-17 17:57, schrieb mik...@fl...: > Hi, > The only think you need to set is clock=16000000 [11] and uart to 1 or 2 depending on which uart you want to use. > > M. > > ------ Original message------ > FROM: Bernd Dau > DATE: Mon, 17 Jul 2017 16:04 > TO: Flashforth Devel; > CC: > SUBJECT:[Flashforth-devel] Noob Hardware Questions > > Hi, many years ago I was quite comfortable with forth on various comuters.No [1]w, this is my first try with ff50 for PIC18F25K22.My [2] aim is to built a minimal PIC18 with flashforth, communicating via serial port.I've read the install.txt inside of the ff50.zipI've been able to build the hex file and transfer it to the PIC with PICKIT 3 and MPLAB(X).But I'm a bit unsure about the exact tuning parameters.I wonder if RX1 and TX1 is been configured for Pin 17,18 or Pin 25,26 where is the cfg in the ff50 src?My PIC doesn't have build-in USB so in p18f-main.cf [3]g "#define USB_OPERATOR_UART 0 ; 1 (=UART) or 0 ( = inbuilt USB)"should set to 1, right?If I won't > use an external Xtal, is there anything to set in *.cfg?I'm use p18f-main.cf [3]g and p18f2x4xk22.cf [4]gDid I miss some additional switches and things?Best Regards.Be [5]rnd------------------------------------------------------------------------------Check out the vibrant tech community on one of the world's mostengaging tech sites, Slashdot.org [6]! http://sdm.li [7]nk/slashdot_______________________________________________Flashforth-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/flashforth-devel [8] > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot [9] > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel [10] Links: ------ [1] http://comuters.No [2] http://PIC18F25K22.My [3] http://p18f-main.cf [4] http://p18f2x4xk22.cf [5] http://Regards.Be [6] http://Slashdot.org [7] http://sdm.li [8] http://lists.sourceforge.net/lists/listinfo/flashforth-devel [9] http://sdm.link/slashdot [10] https://lists.sourceforge.net/lists/listinfo/flashforth-devel [11] tel:16000000 |
|
From: <mik...@fl...> - 2017-07-18 03:02:17
|
The hardware uart is connected to the usb chip on the arduino uno board.M.
------ Original message------From: Bruce CorbinDate: Tue, 18 Jul 2017 05:03To: mik...@fl...;fla...@li...;Cc: Subject:Re: [Flashforth-devel] assemble FlashForth for Arduino Uno
Thanks again.
Now I'm a little confused. I have been using the USB serial port and the downloaded hex file. Is the hardware UART already active for console use or do I need to change a configuration variable and recompile?
Thank you,
Bruce
On 07/17/2017 08:59 AM, mik...@fl... wrote:
Hi The atmega 328 has only one uart, uart0. No need to change the operator uart.
The avrasm minor version shud not matter. And if you get a working compilation I suppose your include file is ok.
M.
------ Original message------ From: Bruce Corbin Date: Mon, 17 Jul 2017 15:08 To: mik...@fl...;fla...@li...; Cc: Subject:Re: [Flashforth-devel] assemble FlashForth for Arduino Uno
Mikael,
Thank you. That was very helpful. So far I have not found the exact assembler build you used. Also by comparing list files I don't think I have the exact same m328def.inc file, but I can assemble the source and get a hex file that is an exact match to the downloaded hex file. A huge step forward.
My second step is to assemble the source to use the serial port. With external logic level to RS-232 level translators I will then have a Forth machine that communicates over RS-232. It appears that I need to edit the config.inc file and change OPERATOR_UART from 0 to 1. When I do this I get fatal errors during assembly. My initial assumption is that this is caused by the m328def.inc files that is very similar to yours but based upon the list files I don't think they are an exact match. Before I end up wasting too much time I'll ask three questions:
1) Is changing OPERATOR-UART the correct procedure to reassemble for the traditional serial port?
2) Is the exact m328def.inc file that you used available for download?
3) The avrasm2 file that I found is a few builds newer than yo urs. I don't think this is a problem but it is different. I didn't find your exact assembler on the AmForth site. Yours was 2.1.30. The one I found was 2.1.43. Do you think this is a problem?
Thank you,
Bruce
On 07/16/2017 01:19 AM, mik...@fl... wrote:
Hi, You need to use wine and avrasm2.exe from atmel studio4. That is my dev toolchain, works just fine on linux.
Amforth used to have avrasm2 in its download area.
M.
------ Original message------ From: Bruce Corbin Date: Sun, 16 Jul 2017 06:45 To: fla...@li...; Cc: Subject:[Flashforth-devel] assemble FlashForth for Arduino Uno
I have been trying for hours to assemble FlashForth for the Arduino Uno. Soon I would like to compile to have it use the serial port (for an RS-232 console) but as my starting point I am trying to assemble the downloaded ff-atmega.asm file to generate the downloaded hex file. It seems like this should be both trivial and documented by one or two paragraphs on the download page that contains the source and hex.I have downloaded the AVR Studio for Windows, the A tmel 8-Bit AVR to olchain for Linux, avra for Linux and one or two other assemblers. So far the best I have been able to do is about 40-50 errors and warnings when using avra. If I recall correctly the error count was well over a thousand with Atmel AVR Studio. The downloaded Atmel toolchain also had a lot of reported errors.What assembler works? What assembler did the FlashForth developer(s) use?It looks like the code may have been assembled in a C environment since there is a commen
t in it that is commented out by a double slash. Some of my reported errors are also due to "strlen" in the source which again suggests a "C" environment to me. High in the downloaded listing file is "AVRASM ver. 2.1.30 avr/src/ff-atmega.asm Wed Mar 22 22:08:36 2017" but AVRASM isn't in the toolchain I downloaded from Atmel.Linux is by far my preferred OS but I can use Windows if necessar y.I'm just trying to get started. Thank you for your help.----- -------------------------------------------------------------------------Check out the vibrant tech community on one of the world's mostengaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________Flashforth-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/flashforth-devel
|
|
From: Bruce C. <bc...@cf...> - 2017-07-18 02:03:52
|
Thanks again. Now I'm a little confused. I have been using the USB serial port and the downloaded hex file. Is the hardware UART already active for console use or do I need to change a configuration variable and recompile? Thank you, Bruce On 07/17/2017 08:59 AM, mik...@fl... wrote: > Hi > The atmega 328 has only one uart, uart0. No need to change the > operator uart. > > The avrasm minor version shud not matter. And if you get a working > compilation I suppose your include file is ok. > > M. > > ------ Original message------ > *From: *Bruce Corbin > *Date: *Mon, 17 Jul 2017 15:08 > *To: *mik...@fl... > <mailto:mik...@fl...>;fla...@li... > <mailto:;fla...@li...>; > *Cc: * > *Subject:*Re: [Flashforth-devel] assemble FlashForth for Arduino Uno > > Mikael, > > Thank you. That was very helpful. So far I have not found the exact > assembler build you used. Also by comparing list files I don't think > I have the exact same m328def.in <http://m328def.in>c file, but I can > assemble the source and get a hex file that is an exact match to the > downloaded hex file. A huge step forward. > > My second step is to assemble the source to use the serial port. With > external logic level to RS-232 level translators I will then have a > Forth machine that communicates over RS-232. It appears that I need to > edit the config.in <http://config.in>c file and change OPERATOR_UART > from 0 to 1. When I do this I get fatal errors during assembly. My > initial assumption is that this is caused by the m328def.in > <http://m328def.in>c files that is very similar to yours but based > upon the list files I don't think they are an exact match. Before I > end up wasting too much time I'll ask three questions: > > 1) Is changing OPERATOR-UART the correct procedure to reassemble for > the traditional serial port? > > 2) Is the exact m328def.in <http://m328def.in>c file that you used > available for download? > > 3) The avrasm2 file that I found is a few builds newer than yo urs. I > don't think this is a problem but it is different. I didn't find your > exact assembler on the AmForth site. Yours was 2.1.30. The one I > found was 2.1.43. Do you think this is a problem? > > Thank you, > Bruce > > > On 07/16/2017 01:19 AM, mik...@fl... wrote: >> Hi, >> You need to use wine and avrasm2.exe from atmel studio4. That is my >> dev toolchain, works just fine on linux. >> >> Amforth used to have avrasm2 in its download area. >> >> M. >> >> ------ Original message------ >> *From: *Bruce Corbin >> *Date: *Sun, 16 Jul 2017 06:45 >> *To: *fla...@li...; >> *Cc: * >> *Subject:*[Flashforth-devel] assemble FlashForth for Arduino Uno >> >> I have been trying for hours to assemble FlashForth for the Arduino Uno. Soon I would like to compile to have it use the serial port (for an RS-232 console) but as my starting point I am trying to assemble the downloadedff-atmega.as <http://ff-atmega.as>m file to generate the downloaded hex file. It seems like this should be both trivial and documented by one or two paragraphs on the download page that contains the source and hex.I have downloaded the AVR Studio for Windows, the A >> tmel 8-Bit AVR to olchain for Linux, avra for Linux and one or two other assemblers. So far the best I have been able to do is about 40-50 errors and warnings when using avra. If I recall correctly the error count was well over a thousand with Atmel AVR Studio. The downloaded Atmel toolchain also had a lot of reported errors.What assembler works? What assembler did the FlashForth developer(s) use?It looks like the code may have been assembled in a C environment since there is a comment in it that is commented out by a double slash. Some of my reported errors are also due to "strlen" in the source which again suggests a "C" environment to me. High in the downloaded listing file is "AVRASM ver. 2.1.30 avr/src/ff-atmega.as <http://ff-atmega.as>m Wed Mar 22 22:08:36 2017" but AVRASM isn't in the toolchain I downloaded fromAtmel.Li <http://Atmel.Li>nux is by far my preferred OS but I can use Windows if necessar >> y.I'm just trying to get started. Thank you for your help.----- -------------------------------------------------------------------------Check out the vibrant tech community on one of the world's mostengaging tech sites,Slashdot.org <http://Slashdot.org>!http://sdm.link/slashdot_______________________________________________Flashforth-devel mai...@li...htt >> <mailto:%20l...@li...htt>ps://lists.sourceforge.net/lists/listinfo/flashforth-devel >> <http://lists.sourceforge.net/lists/listinfo/flashforth-devel> > |
|
From: <mik...@fl...> - 2017-07-17 15:57:53
|
Hi,The only think you need to set is clock=16000000 and uart to 1 or 2 depending on which uart you want to use. M. ------ Original message------From: Bernd DauDate: Mon, 17 Jul 2017 16:04To: Flashforth Devel;Cc: Subject:[Flashforth-devel] Noob Hardware Questions Hi, many years ago I was quite comfortable with forth on various comuters.Now, this is my first try with ff50 for PIC18F25K22.My aim is to built a minimal PIC18 with flashforth, communicating via serial port.I've read the install.txt inside of the ff50.zipI've been able to build the hex file and transfer it to the PIC with PICKIT 3 and MPLAB(X).But I'm a bit unsure about the exact tuning parameters.I wonder if RX1 and TX1 is been configured for Pin 17,18 or Pin 25,26 where is the cfg in the ff50 src?My PIC doesn't have build-in USB so in p18f-main.cfg "#define USB_OPERATOR_UART 0 ; 1 (=UART) or 0 ( = inbuilt USB)"should set to 1, right?If I won't use an external Xtal, is there anything to set in *.cfg?I'm use p18f-main.cfg and p18f2x4xk22.cfgDid I miss some additional switches and things?Best Regards.Bernd------------------------------------------------------------------------------Check out the vibrant tech community on one of the world's mostengaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________Flashforth-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Bernd D. <be...@da...> - 2017-07-17 13:03:59
|
Hi, many years ago I was quite comfortable with forth on various
comuters.
Now, this is my first try with ff50 for PIC18F25K22.
My aim is to built a minimal PIC18 with flashforth, communicating via
serial port.
I've read the install.txt inside of the ff50.zip
I've been able to build the hex file and transfer it to the PIC with
PICKIT 3 and MPLAB(X).
But I'm a bit unsure about the exact tuning parameters.
I wonder if RX1 and TX1 is been configured for Pin 17,18 or Pin 25,26
where is the cfg in the ff50 src?
My PIC doesn't have build-in USB so in p18f-main.cfg
"#define USB_OPERATOR_UART 0 ; 1 (=UART) or 0 ( = inbuilt USB)"
should set to 1, right?
If I won't use an external Xtal, is there anything to set in *.cfg?
I'm use p18f-main.cfg and p18f2x4xk22.cfg
Did I miss some additional switches and things?
Best Regards.
Bernd
|
17 messages has been excluded from this view by a project administrator.
