flashforth-devel Mailing List for FlashForth: for PIC and Atmega (Page 5)
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...> - 2022-01-08 18:25:16
|
Just upgraded to PIC-AS v2.35. And fantastically the listing file now expands the macros and shows a correct output. It was real pain to port FF with v2.32 whiich had a worthless listing file. On 2022-01-08 20:02, Mikael Nordman wrote: > Hi Tristan. > MPLABX 5.50 and 6.00 and PIC-AS 2.32. > > BR Mikael > > On 2022-01-08 12:06, Tristan Williams wrote: >> Hello Mikael, >> >> That is fantastic news. Thank you. >> >> Can you tell me which version of PIC-AS/IDE are you using? >> >> Kind regards, >> >> Tristan >> |
|
From: Mikael N. <mik...@fl...> - 2022-01-08 18:02:26
|
Hi Tristan. MPLABX 5.50 and 6.00 and PIC-AS 2.32. BR Mikael On 2022-01-08 12:06, Tristan Williams wrote: > Hello Mikael, > > That is fantastic news. Thank you. > > Can you tell me which version of PIC-AS/IDE are you using? > > Kind regards, > > Tristan > > On 08Jan22 08:40, Mikael Nordman wrote: >> Greetings. >> Microchip has dropped support of MPASM for new chips and new IDE >> versions. >> After a lot of work FF has been updated to compile with PIC-AS. >> MPASM support has been dropped in order to develop only one version of >> FF. >> >> Improvements include support for the Q41 and Q43 chips. >> Another improvement is the simultanous support for up to 3 UARTS. >> The linker files are not used anymore, but instead some PIC-AS command >> line >> options must be used. >> >> I have tested with 18f14k50 18f25k50 18f2455 18f26k42 18f26k83 >> 18f16q41. >> Please report any bugs. >> >> Best wishes for the new year. >> Mikael >> >> >> >> >> _______________________________________________ >> Flashforth-devel mailing list >> Fla...@li... >> https://lists.sourceforge.net/lists/listinfo/flashforth-devel >> > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel -- -- Mikael |
|
From: Tristan W. <ho...@tj...> - 2022-01-08 16:38:26
|
Hello Mikael, That is fantastic news. Thank you. Can you tell me which version of PIC-AS/IDE are you using? Kind regards, Tristan On 08Jan22 08:40, Mikael Nordman wrote: > Greetings. > Microchip has dropped support of MPASM for new chips and new IDE versions. > After a lot of work FF has been updated to compile with PIC-AS. > MPASM support has been dropped in order to develop only one version of FF. > > Improvements include support for the Q41 and Q43 chips. > Another improvement is the simultanous support for up to 3 UARTS. > The linker files are not used anymore, but instead some PIC-AS command line > options must be used. > > I have tested with 18f14k50 18f25k50 18f2455 18f26k42 18f26k83 18f16q41. > Please report any bugs. > > Best wishes for the new year. > Mikael > > > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
|
From: Frans-Pieter V. <ner...@xs...> - 2022-01-08 15:10:27
|
Hi Peter, Thank you for putting effort in keeping the documentation of flashforth up to date. Also introducing asciidoc for writing documentation was interesting. I found out that gitlab and github support this format. With your cheatsheet I tried to seperate the Atmega from the PIC information. Did not succeed yet. Probably that TEX is still the best solution for compact cheatsheets. I'm learning FORTH playing along with flashforth on my arduino nano's. At my school I teach computer programming at 12/13/14 year olds students. The arduino IDE is what we use normally, as the examples and code are self-explanatory and easy to copy and paste. However, when I master FORTH enough I will introduce them to ForthForh. Learning to program in FORTH alongside an introduction about the inner workings of the microcontroller can form an interesting course. On the internet dye's can be found of decapped atmega328p's that show eeprom, ram, GPIO. This physical "evidence" that memory is not just an abstract concept but really exist inside the microcontroller is a strong didactic argument. Likewise in biology, when you teach about cells students prepare samples and study them under a microscope. And in advanced classes you even experiment with dna, the program off life. Decapping a microcontroller is mostly done with chemicals which makes it not very practical in class. However internet shows there are mechanical techniques to do this. Grinding the protective layer with find sandpaper and heating and breaking of the protective shell should be possible. So using the biological analogy, with FORTH you can reprogram artificial life. This perspective, focusing on the small and simple is the message of Chuck Moore's talk, minimizing energy is the key https://www.youtube.com/watch?v=0PclgBd6_Zs Greets, Frans-Pieter Vonck > Op 06-01-2022 05:18 schreef Peter Jacobs <pe...@me...>: > > > Mikael, > many months have passed... > > No, asciidoctor produces HTML files that can be part of a static web > site. I have put the rendered files in a github repository so that they > appear at https://pajacobs-ghub.github.io/ > > These are essentially a port of the LateX documents, as they were in > 2016, 2017. Quite a few little details need to be revised because I > have not kept up with things since then, however, the current state are > a good indication of how the revised documents might turn out. > > The source asciidoc files are in the repository with the LaTeX files at > https://github.com/pajacobs-ghub/flashforth-docs > Compared with the lateX source, I think that they will be much easier to > maintain. > > Anyway, now that I have retired from the UQ payroll, I should find time > to update the docs. Unfortunately, that also means that I no longer have > access to eager thesis students who might be skilled in assembly language. > > Regards, > Peter J. > > > On 13/4/21 1:04 am, Mikael Nordman wrote: > > Peter, sorry for my slow response. > > > > FF Atmega is now transformed to be compiled with MPLABX and XC8. > > > > Does ASCIIDOC require some server side support? I am not familiar with > > it. > > > > It seems all peripherals, including flash and eeprom, are different on > > the 4809. > > Maybe you have an eager student to take on the task ? > > > > BR Mikael > > > > On 2021-03-28 13:49, Peter Jacobs wrote: > >> Mikael, > >> It would be interesting to have FF running on Atmega4809. I bought a > >> few of those thinking that I would come back to doing some FF-related > >> work this year (2021). It has been a while since I have had any time > >> to play, so part of my plans included a refresh of the tutorial > >> documents, possibly into ASCIIDOC source form. I expect that such a > >> form would allow them to be more easily included on your web site and, > >> also, that it would be easier to copy and paste code from them. > >> Cheers, > >> Peter J. > > > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2022-01-08 07:18:20
|
Greetings. Microchip has dropped support of MPASM for new chips and new IDE versions. After a lot of work FF has been updated to compile with PIC-AS. MPASM support has been dropped in order to develop only one version of FF. Improvements include support for the Q41 and Q43 chips. Another improvement is the simultanous support for up to 3 UARTS. The linker files are not used anymore, but instead some PIC-AS command line options must be used. I have tested with 18f14k50 18f25k50 18f2455 18f26k42 18f26k83 18f16q41. Please report any bugs. Best wishes for the new year. Mikael |
|
From: Peter J. <pe...@me...> - 2022-01-06 04:34:06
|
Mikael, many months have passed... No, asciidoctor produces HTML files that can be part of a static web site. I have put the rendered files in a github repository so that they appear at https://pajacobs-ghub.github.io/ These are essentially a port of the LateX documents, as they were in 2016, 2017. Quite a few little details need to be revised because I have not kept up with things since then, however, the current state are a good indication of how the revised documents might turn out. The source asciidoc files are in the repository with the LaTeX files at https://github.com/pajacobs-ghub/flashforth-docs Compared with the lateX source, I think that they will be much easier to maintain. Anyway, now that I have retired from the UQ payroll, I should find time to update the docs. Unfortunately, that also means that I no longer have access to eager thesis students who might be skilled in assembly language. Regards, Peter J. On 13/4/21 1:04 am, Mikael Nordman wrote: > Peter, sorry for my slow response. > > FF Atmega is now transformed to be compiled with MPLABX and XC8. > > Does ASCIIDOC require some server side support? I am not familiar with > it. > > It seems all peripherals, including flash and eeprom, are different on > the 4809. > Maybe you have an eager student to take on the task ? > > BR Mikael > > On 2021-03-28 13:49, Peter Jacobs wrote: >> Mikael, >> It would be interesting to have FF running on Atmega4809. I bought a >> few of those thinking that I would come back to doing some FF-related >> work this year (2021). It has been a while since I have had any time >> to play, so part of my plans included a refresh of the tutorial >> documents, possibly into ASCIIDOC source form. I expect that such a >> form would allow them to be more easily included on your web site and, >> also, that it would be easier to copy and paste code from them. >> Cheers, >> Peter J. |
|
From: Helge K. <Hel...@gm...> - 2022-01-02 10:22:53
|
Hi Stefan, > because cbi/sbi use the bitnumber and not the bitmask. Yes, now I understand why the code didn't work. I put two questions in one mail. Therefore the second question about the missing implementation for SBI/CBI in *see *is somehow lost. It was just a pity that see could not be used to verify the compiled code. I added some lines to see.fs: : .xbi ( addr -- addr) *@ dup 3 rshift 1f and ." r" decimal 2 u.r hex ." ," 7 and . cell+ ; : ?cbi ( addr -- addr f ) *@ ff00 and 9800 - ; : ?sbi ( addr -- addr f ) *@ ff00 and 9a00 - ; ?sbi 0= if 5sp ." sbi " .xbi else ?cbi 0= if 5sp ." cbi " .xbi else With these lines I get more info, at least for CBI/SBI. I wasn't aware that the implementation in see.fs is far from a complete discompiler. Best regards, Helge Am 02.01.2022 um 09:30 schrieb Stefan: > Hallo Helge, > > disassembled code is: > > 9a58 -> sbi PORTD,0 (that's 8 mod 8 because only values from 0 to 7 are > allowed) > 9a5c -> sbi PORTD,4 > ... > because cbi/sbi use the bitnumber and not the bitmask. > > use: > 3 constant txd_pin > 2 constant rxd_pin > > greetz bitflipser > > > Am 31.12.2021 um 12:35 schrieb Helge Kruse: >> Hello, >> >> I'm new to FlashForth. I want to use it for ATmega328 and ATmega2560. >> >> I try to implement an ISR for a bit bang serial port, since the >> ATmega328 has only one USART. My minimum code example is: >> >> $002b constant portd >> $002a constant ddrd >> $08 constant txd \ bit 3 >> $04 constant rxd \ bit 2 >> >> \ make an I/O addres from memory address for sbi and cbi. >> : >IO ( a - io ) $20 invert and ; >> >> : t2CompAIsr txd portd mset rxd portd mset rxd portd mclr txd portd >> mclr ; >> >> : t2CompAIsr_ >> [ >> portd >IO txd sbi, >> portd >IO rxd sbi, >> portd >IO rxd cbi, >> portd >IO txd cbi, >> ] >> ;i >> >> : irqCompAInit >> rxd ddrd mset \ to see write to rxd >> txd portd mset txd ddrd mset >> >> ['] t2CompAIsr_ compAIvec int! >> 208 ocr2a c! \ set comparator A register >> 2 tccr2a c! \ set CTC mode (WGM = 2) >> 6 tccr2b c! \ activate counter 2, clock source = clk_T2S/1 >> 2 timsk2 mset \ activate timer2 comparatorA interrupt OCIE2A >> ; >> >> If I use mclr/mset to set the bits, I see the changes on the pins with a >> logic analyzer. But unfortunately I can't see any change on the PORTD >> pins if I use the word t2CompAIsr_. >> >> What's wrong with my assembler code? I want to verify what I compiled >> with the disassembler: >> >> see t2CompAIsr_ >> 975a 9a58 >> 975c 9a5c >> 975e 985c >> 9760 9858 >> 9762 940c 3c33 jmp ............... >> ok<$,ram> >> >> All the CBI/SBI is not decompiled. Probably this is not implemented in >> "forth/avr/see.fs". I also tried "forth/avr/see2.fs". The later file >> can't be compiled, a word sy1 is missing. >> >> How can I verify what's wrong with my simple code? >> >> Best regards, >> Helge >> >> >> >> >> >> _______________________________________________ >> Flashforth-devel mailing list >> Fla...@li... >> https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Stefan <fli...@gm...> - 2022-01-02 08:30:21
|
Hallo Helge, disassembled code is: 9a58 -> sbi PORTD,0 (that's 8 mod 8 because only values from 0 to 7 are allowed) 9a5c -> sbi PORTD,4 ... because cbi/sbi use the bitnumber and not the bitmask. use: 3 constant txd_pin 2 constant rxd_pin greetz bitflipser Am 31.12.2021 um 12:35 schrieb Helge Kruse: > Hello, > > I'm new to FlashForth. I want to use it for ATmega328 and ATmega2560. > > I try to implement an ISR for a bit bang serial port, since the > ATmega328 has only one USART. My minimum code example is: > > $002b constant portd > $002a constant ddrd > $08 constant txd \ bit 3 > $04 constant rxd \ bit 2 > > \ make an I/O addres from memory address for sbi and cbi. > : >IO ( a - io ) $20 invert and ; > > : t2CompAIsr txd portd mset rxd portd mset rxd portd mclr txd portd > mclr ; > > : t2CompAIsr_ > [ > portd >IO txd sbi, > portd >IO rxd sbi, > portd >IO rxd cbi, > portd >IO txd cbi, > ] > ;i > > : irqCompAInit > rxd ddrd mset \ to see write to rxd > txd portd mset txd ddrd mset > > ['] t2CompAIsr_ compAIvec int! > 208 ocr2a c! \ set comparator A register > 2 tccr2a c! \ set CTC mode (WGM = 2) > 6 tccr2b c! \ activate counter 2, clock source = clk_T2S/1 > 2 timsk2 mset \ activate timer2 comparatorA interrupt OCIE2A > ; > > If I use mclr/mset to set the bits, I see the changes on the pins with a > logic analyzer. But unfortunately I can't see any change on the PORTD > pins if I use the word t2CompAIsr_. > > What's wrong with my assembler code? I want to verify what I compiled > with the disassembler: > > see t2CompAIsr_ > 975a 9a58 > 975c 9a5c > 975e 985c > 9760 9858 > 9762 940c 3c33 jmp ............... > ok<$,ram> > > All the CBI/SBI is not decompiled. Probably this is not implemented in > "forth/avr/see.fs". I also tried "forth/avr/see2.fs". The later file > can't be compiled, a word sy1 is missing. > > How can I verify what's wrong with my simple code? > > Best regards, > Helge > > > > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2021-12-31 18:00:47
|
<div dir='auto'>Yes. Or you can try to remove the -as line from the asm2 file.</div><div class="gmail_extra"><br><div class="gmail_quote">On 31 Dec 2021 17:28, Helge Kruse <Hel...@gm...> wrote:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<p>But loading asm2.fs calls <b>-as</b> and makes the asm words
forgotten. Does that mean that I should use asm2 instead of asm?</p>
<p>Best regards,<br />
Helge<br />
</p>
<div>Am 31.12.2021 um 15:04 schrieb Mikael
Nordman:<br />
</div>
<blockquote>
<div dir="auto">See2 requires that you compile asm2 first.
<div dir="auto"><br />
</div>
<div dir="auto">: toIO $20 - ;</div>
<div dir="auto"><br />
</div>
</div>
<div><br />
</div>
</blockquote>
</div>
</blockquote></div><br></div> |
|
From: Helge K. <Hel...@gm...> - 2021-12-31 15:28:26
|
But loading asm2.fs calls *-as* and makes the asm words forgotten. Does that mean that I should use asm2 instead of asm? Best regards, Helge Am 31.12.2021 um 15:04 schrieb Mikael Nordman: > See2 requires that you compile asm2 first. > > : toIO $20 - ; > > |
|
From: Mikael N. <mik...@fl...> - 2021-12-31 14:59:20
|
<div dir='auto'>See2 requires that you compile asm2 first.<div dir="auto"><br></div><div dir="auto">: toIO $20 - ;</div><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 31 Dec 2021 13:35, Helge Kruse <Hel...@gm...> wrote:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hello,</p> <p dir="ltr">I'm new to FlashForth. I want to use it for ATmega328 and ATmega2560.</p> <p dir="ltr">I try to implement an ISR for a bit bang serial port, since the<br> ATmega328 has only one USART. My minimum code example is:</p> <p dir="ltr">$002b constant portd<br> $002a constant ddrd<br> $08 constant txd    \ bit 3<br> $04 constant rxd    \ bit 2</p> <p dir="ltr">\ make an I/O addres from memory address for sbi and cbi.<br> : >IO  ( a - io )  $20 invert and ;</p> <p dir="ltr">: t2CompAIsr  txd portd mset  rxd portd mset  rxd portd mclr  txd portd<br> mclr ;</p> <p dir="ltr">: t2CompAIsr_<br>     [<br>       portd >IO txd sbi,<br>       portd >IO rxd sbi,<br>       portd >IO rxd cbi,<br>       portd >IO txd cbi,<br>     ]<br> ;i</p> <p dir="ltr">: irqCompAInit<br>     rxd ddrd mset \ to see write to rxd<br>     txd portd mset  txd ddrd mset</p> <p dir="ltr">     ['] t2CompAIsr_ compAIvec int!<br>     208 ocr2a c!  \ set comparator A register<br>     2 tccr2a c!   \ set CTC mode (WGM = 2)<br>     6 tccr2b c!   \ activate counter 2, clock source = clk_T2S/1<br>     2 timsk2 mset \ activate timer2 comparatorA interrupt OCIE2A<br> ;</p> <p dir="ltr">If I use mclr/mset to set the bits, I see the changes on the pins with a<br> logic analyzer. But unfortunately I can't see any change on the PORTD<br> pins if I use the word t2CompAIsr_.</p> <p dir="ltr">What's wrong with my assembler code? I  want to verify what I compiled<br> with the disassembler:</p> <p dir="ltr">see t2CompAIsr_<br> 975a 9a58<br> 975c 9a5c<br> 975e 985c<br> 9760 9858<br> 9762 940c 3c33 jmp   ...............<br>  ok<$,ram></p> <p dir="ltr">All the CBI/SBI is not decompiled. Probably this is not implemented in<br> "forth/avr/see.fs". I also tried "forth/avr/see2.fs". The later file<br> can't be compiled, a word sy1 is missing.</p> <p dir="ltr">How can I verify what's wrong with my simple code?</p> <p dir="ltr">Best regards,<br> Helge<br><br><br><br></p> <p dir="ltr">_______________________________________________<br> Flashforth-devel mailing list<br> Fla...@li...<br> https://lists.sourceforge.net/lists/listinfo/flashforth-devel<br> </p> </blockquote></div><br></div> |
|
From: Helge K. <Hel...@gm...> - 2021-12-31 11:36:07
|
Hello, I'm new to FlashForth. I want to use it for ATmega328 and ATmega2560. I try to implement an ISR for a bit bang serial port, since the ATmega328 has only one USART. My minimum code example is: $002b constant portd $002a constant ddrd $08 constant txd \ bit 3 $04 constant rxd \ bit 2 \ make an I/O addres from memory address for sbi and cbi. : >IO ( a - io ) $20 invert and ; : t2CompAIsr txd portd mset rxd portd mset rxd portd mclr txd portd mclr ; : t2CompAIsr_ [ portd >IO txd sbi, portd >IO rxd sbi, portd >IO rxd cbi, portd >IO txd cbi, ] ;i : irqCompAInit rxd ddrd mset \ to see write to rxd txd portd mset txd ddrd mset ['] t2CompAIsr_ compAIvec int! 208 ocr2a c! \ set comparator A register 2 tccr2a c! \ set CTC mode (WGM = 2) 6 tccr2b c! \ activate counter 2, clock source = clk_T2S/1 2 timsk2 mset \ activate timer2 comparatorA interrupt OCIE2A ; If I use mclr/mset to set the bits, I see the changes on the pins with a logic analyzer. But unfortunately I can't see any change on the PORTD pins if I use the word t2CompAIsr_. What's wrong with my assembler code? I want to verify what I compiled with the disassembler: see t2CompAIsr_ 975a 9a58 975c 9a5c 975e 985c 9760 9858 9762 940c 3c33 jmp ............... ok<$,ram> All the CBI/SBI is not decompiled. Probably this is not implemented in "forth/avr/see.fs". I also tried "forth/avr/see2.fs". The later file can't be compiled, a word sy1 is missing. How can I verify what's wrong with my simple code? Best regards, Helge |
|
From: Tristan W. <ho...@tj...> - 2021-11-23 16:47:00
|
Solved. Puzzle the result of a self-inflicted hardware issue. Most likely culprit, insufficient quality capacitance between Vusb3V3 and ground. Thank you to all. Best wishes, Tristan On 21Nov21 09:32, Colin Tree wrote: > Hi Tristan, > > using a ch340 based usb<>serial, no buffer and doesn't need flow control > > FTDI232 and cu with flow control > > colin@treehome:~$ cu -f -l /dev/ttyUSB0 -s 1000000 > Connected. > (cr) ok > ~. > Disconnected. > > with no flow control > > colin@treehome:~$ cu -l /dev/ttyUSB0 -s 1000000 > Connected. > (cr) ~. > (cr) ~. > (cr) ~. > (cr) ~. > (cr) ~. > (cr) ~ > Disconnected. > > so between the buffer and flow control ... > > Colin > > On 20/11/21 5:59 pm, Tristan Williams wrote: > > Hello Mikael, > > > > Thank you. I tried adding pause to the bridge word but to no > > avail. Still no data received if the serial data is sent > > infrequently. No data received after a good long wait. I have just > > moved my winter project to the PIC18F25K50 (to get more flash storage) > > from the PIC18F14K50. I didn't recall anything similar happening with > > that chip, so I tried the bridge back on my PIC18F14K50 setup and - it > > worked (without pause). It would seem to me that the two chips are > > responding differently to what I think is the same code. A puzzle. > > > > Best wishes, > > Tristan > > > > > > On 20Nov21 06:23, Mikael Nordman wrote: > > > Hi, > > > > > > TXU collects up to 8 characters before it sends the buffer to the > > > USB line. > > > > > > There is a timeout 2+TICK_TIME milliseconds to send the buffer if no > > > data arrives to TXU. TICK_TIME is defined in the config file. > > > > > > That timeout is handled by PAUSE. > > > > > > So you should have seen data on the USB line after 8 seconds. > > > If not then there is some other problem. > > > > > > Try this > > > > > > : bridge > > > u1- > > > begin > > > pause rx1? if rx1 txu then > > > again > > > ; > > > > > > BR Mikael > > > > > > > > > On 2021-11-19 21:09, Tristan Williams wrote: > > > > Hello, > > > > > > > > I have a small mcu, sending serial data over its hardware uart > > > > (38400-8N1) to the RX1 port of a PIC18F25K50 running FlashForth over > > > > USB. I am trying to see/capture that serial data using FlashForth as a > > > > USB-UART bridge > > > > > > > > : bridge > > > > u1- > > > > begin > > > > rx1? if rx1 txu then > > > > again > > > > ; > > > > > > > > as per https://sourceforge.net/p/flashforth/wiki/USB-UART%20bridge/ > > > > > > > > If the serial data is sent as a continuous stream then it arrives as I > > > > expect. If the data is subject to a delay in transmission - i.e. I put > > > > a 1 second delay between each data byte, the data does not arrive. It > > > > seems, perhaps, that the bridge has stalled in some way whilst waiting? > > > > > > > > I hooked up a second usb-serial adaptor (FTDI) to the small mcu TX and > > > > the delayed data is definitely there, arriving with a one second delay > > > > between each data byte. If the data is streamed continuously, both the > > > > bridge and the FTDI see it; if I introduce a delay, only the FTDI sees > > > > it. > > > > > > > > Any light on what I might be doing wrong would be very gratefully > > > > received. > > > > > > > > Best wishes, > > > > > > > > Tristan > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Flashforth-devel mailing list > > > > Fla...@li... > > > > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > > -- > > > -- > > > Mikael > > > > > > > > > _______________________________________________ > > > Flashforth-devel mailing list > > > Fla...@li... > > > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > > > > > > _______________________________________________ > > Flashforth-devel mailing list > > Fla...@li... > > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > > > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2021-11-21 10:52:29
|
Tristan,
I have set up the same configuration as yours,
where I send single characters to the UART and have the bridge to USB.
I must have PAUSE in the loop to reset the watchdog.
Otherwise the chip will reset and restart FF.
Maybe you do not have the watchdog active ?
In my setup on the 25k50 the transfer of single characters from
the UART to USB works just fine. This is with the current code
in git/sf.
-bridge
marker -bridge
: bridge ( -- )
u1-
begin
pause
rx1? if rx1 txu then
again
;
BR Mikael
On 2021-11-20 09:59, Tristan Williams wrote:
> Hello Mikael,
>
> Thank you. I tried adding pause to the bridge word but to no
> avail. Still no data received if the serial data is sent
> infrequently. No data received after a good long wait. I have just
> moved my winter project to the PIC18F25K50 (to get more flash storage)
> from the PIC18F14K50. I didn't recall anything similar happening with
> that chip, so I tried the bridge back on my PIC18F14K50 setup and - it
> worked (without pause). It would seem to me that the two chips are
> responding differently to what I think is the same code. A puzzle.
>
> Best wishes,
> Tristan
>
>
> On 20Nov21 06:23, Mikael Nordman wrote:
>> Hi,
>>
>> TXU collects up to 8 characters before it sends the buffer to the
>> USB line.
>>
>> There is a timeout 2+TICK_TIME milliseconds to send the buffer if no
>> data arrives to TXU. TICK_TIME is defined in the config file.
>>
>> That timeout is handled by PAUSE.
>>
>> So you should have seen data on the USB line after 8 seconds.
>> If not then there is some other problem.
>>
>> Try this
>>
>> : bridge
>> u1-
>> begin
>> pause rx1? if rx1 txu then
>> again
>> ;
>>
>> BR Mikael
>>
>>
>> On 2021-11-19 21:09, Tristan Williams wrote:
>> > Hello,
>> >
>> > I have a small mcu, sending serial data over its hardware uart
>> > (38400-8N1) to the RX1 port of a PIC18F25K50 running FlashForth over
>> > USB. I am trying to see/capture that serial data using FlashForth as a
>> > USB-UART bridge
>> >
>> > : bridge
>> > u1-
>> > begin
>> > rx1? if rx1 txu then
>> > again
>> > ;
>> >
>> > as per https://sourceforge.net/p/flashforth/wiki/USB-UART%20bridge/
>> >
>> > If the serial data is sent as a continuous stream then it arrives as I
>> > expect. If the data is subject to a delay in transmission - i.e. I put
>> > a 1 second delay between each data byte, the data does not arrive. It
>> > seems, perhaps, that the bridge has stalled in some way whilst waiting?
>> >
>> > I hooked up a second usb-serial adaptor (FTDI) to the small mcu TX and
>> > the delayed data is definitely there, arriving with a one second delay
>> > between each data byte. If the data is streamed continuously, both the
>> > bridge and the FTDI see it; if I introduce a delay, only the FTDI sees
>> > it.
>> >
>> > Any light on what I might be doing wrong would be very gratefully
>> > received.
>> >
>> > Best wishes,
>> >
>> > Tristan
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Flashforth-devel mailing list
>> > Fla...@li...
>> > https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
>> --
>> --
>> Mikael
>>
>>
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
>
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
--
--
Mikael
|
|
From: Colin T. <co...@tp...> - 2021-11-20 23:50:54
|
Hi Tristan, using a ch340 based usb<>serial, no buffer and doesn't need flow control FTDI232 and cu with flow control colin@treehome:~$ cu -f -l /dev/ttyUSB0 -s 1000000 Connected. (cr) ok ~. Disconnected. with no flow control colin@treehome:~$ cu -l /dev/ttyUSB0 -s 1000000 Connected. (cr) ~. (cr) ~. (cr) ~. (cr) ~. (cr) ~. (cr) ~ Disconnected. so between the buffer and flow control ... Colin On 20/11/21 5:59 pm, Tristan Williams wrote: > Hello Mikael, > > Thank you. I tried adding pause to the bridge word but to no > avail. Still no data received if the serial data is sent > infrequently. No data received after a good long wait. I have just > moved my winter project to the PIC18F25K50 (to get more flash storage) > from the PIC18F14K50. I didn't recall anything similar happening with > that chip, so I tried the bridge back on my PIC18F14K50 setup and - it > worked (without pause). It would seem to me that the two chips are > responding differently to what I think is the same code. A puzzle. > > Best wishes, > Tristan > > > On 20Nov21 06:23, Mikael Nordman wrote: >> Hi, >> >> TXU collects up to 8 characters before it sends the buffer to the >> USB line. >> >> There is a timeout 2+TICK_TIME milliseconds to send the buffer if no >> data arrives to TXU. TICK_TIME is defined in the config file. >> >> That timeout is handled by PAUSE. >> >> So you should have seen data on the USB line after 8 seconds. >> If not then there is some other problem. >> >> Try this >> >> : bridge >> u1- >> begin >> pause rx1? if rx1 txu then >> again >> ; >> >> BR Mikael >> >> >> On 2021-11-19 21:09, Tristan Williams wrote: >>> Hello, >>> >>> I have a small mcu, sending serial data over its hardware uart >>> (38400-8N1) to the RX1 port of a PIC18F25K50 running FlashForth over >>> USB. I am trying to see/capture that serial data using FlashForth as a >>> USB-UART bridge >>> >>> : bridge >>> u1- >>> begin >>> rx1? if rx1 txu then >>> again >>> ; >>> >>> as per https://sourceforge.net/p/flashforth/wiki/USB-UART%20bridge/ >>> >>> If the serial data is sent as a continuous stream then it arrives as I >>> expect. If the data is subject to a delay in transmission - i.e. I put >>> a 1 second delay between each data byte, the data does not arrive. It >>> seems, perhaps, that the bridge has stalled in some way whilst waiting? >>> >>> I hooked up a second usb-serial adaptor (FTDI) to the small mcu TX and >>> the delayed data is definitely there, arriving with a one second delay >>> between each data byte. If the data is streamed continuously, both the >>> bridge and the FTDI see it; if I introduce a delay, only the FTDI sees >>> it. >>> >>> Any light on what I might be doing wrong would be very gratefully >>> received. >>> >>> Best wishes, >>> >>> Tristan >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Flashforth-devel mailing list >>> Fla...@li... >>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel >> -- >> -- >> Mikael >> >> >> _______________________________________________ >> Flashforth-devel mailing list >> Fla...@li... >> https://lists.sourceforge.net/lists/listinfo/flashforth-devel >> > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
|
From: Tristan W. <ho...@tj...> - 2021-11-20 07:59:50
|
Hello Mikael, Thank you. I tried adding pause to the bridge word but to no avail. Still no data received if the serial data is sent infrequently. No data received after a good long wait. I have just moved my winter project to the PIC18F25K50 (to get more flash storage) from the PIC18F14K50. I didn't recall anything similar happening with that chip, so I tried the bridge back on my PIC18F14K50 setup and - it worked (without pause). It would seem to me that the two chips are responding differently to what I think is the same code. A puzzle. Best wishes, Tristan On 20Nov21 06:23, Mikael Nordman wrote: > Hi, > > TXU collects up to 8 characters before it sends the buffer to the > USB line. > > There is a timeout 2+TICK_TIME milliseconds to send the buffer if no > data arrives to TXU. TICK_TIME is defined in the config file. > > That timeout is handled by PAUSE. > > So you should have seen data on the USB line after 8 seconds. > If not then there is some other problem. > > Try this > > : bridge > u1- > begin > pause rx1? if rx1 txu then > again > ; > > BR Mikael > > > On 2021-11-19 21:09, Tristan Williams wrote: > > Hello, > > > > I have a small mcu, sending serial data over its hardware uart > > (38400-8N1) to the RX1 port of a PIC18F25K50 running FlashForth over > > USB. I am trying to see/capture that serial data using FlashForth as a > > USB-UART bridge > > > > : bridge > > u1- > > begin > > rx1? if rx1 txu then > > again > > ; > > > > as per https://sourceforge.net/p/flashforth/wiki/USB-UART%20bridge/ > > > > If the serial data is sent as a continuous stream then it arrives as I > > expect. If the data is subject to a delay in transmission - i.e. I put > > a 1 second delay between each data byte, the data does not arrive. It > > seems, perhaps, that the bridge has stalled in some way whilst waiting? > > > > I hooked up a second usb-serial adaptor (FTDI) to the small mcu TX and > > the delayed data is definitely there, arriving with a one second delay > > between each data byte. If the data is streamed continuously, both the > > bridge and the FTDI see it; if I introduce a delay, only the FTDI sees > > it. > > > > Any light on what I might be doing wrong would be very gratefully > > received. > > > > Best wishes, > > > > Tristan > > > > > > > > > > > > _______________________________________________ > > Flashforth-devel mailing list > > Fla...@li... > > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > -- > -- > Mikael > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
|
From: Mikael N. <mik...@fl...> - 2021-11-20 04:23:41
|
Hi,
TXU collects up to 8 characters before it sends the buffer to the
USB line.
There is a timeout 2+TICK_TIME milliseconds to send the buffer if no
data arrives to TXU. TICK_TIME is defined in the config file.
That timeout is handled by PAUSE.
So you should have seen data on the USB line after 8 seconds.
If not then there is some other problem.
Try this
: bridge
u1-
begin
pause rx1? if rx1 txu then
again
;
BR Mikael
On 2021-11-19 21:09, Tristan Williams wrote:
> Hello,
>
> I have a small mcu, sending serial data over its hardware uart
> (38400-8N1) to the RX1 port of a PIC18F25K50 running FlashForth over
> USB. I am trying to see/capture that serial data using FlashForth as a
> USB-UART bridge
>
> : bridge
> u1-
> begin
> rx1? if rx1 txu then
> again
> ;
>
> as per https://sourceforge.net/p/flashforth/wiki/USB-UART%20bridge/
>
> If the serial data is sent as a continuous stream then it arrives as I
> expect. If the data is subject to a delay in transmission - i.e. I put
> a 1 second delay between each data byte, the data does not arrive. It
> seems, perhaps, that the bridge has stalled in some way whilst waiting?
>
> I hooked up a second usb-serial adaptor (FTDI) to the small mcu TX and
> the delayed data is definitely there, arriving with a one second delay
> between each data byte. If the data is streamed continuously, both the
> bridge and the FTDI see it; if I introduce a delay, only the FTDI sees
> it.
>
> Any light on what I might be doing wrong would be very gratefully
> received.
>
> Best wishes,
>
> Tristan
>
>
>
>
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
--
--
Mikael
|
|
From: Tristan W. <ho...@tj...> - 2021-11-19 19:10:06
|
Hello,
I have a small mcu, sending serial data over its hardware uart
(38400-8N1) to the RX1 port of a PIC18F25K50 running FlashForth over
USB. I am trying to see/capture that serial data using FlashForth as a
USB-UART bridge
: bridge
u1-
begin
rx1? if rx1 txu then
again
;
as per https://sourceforge.net/p/flashforth/wiki/USB-UART%20bridge/
If the serial data is sent as a continuous stream then it arrives as I
expect. If the data is subject to a delay in transmission - i.e. I put
a 1 second delay between each data byte, the data does not arrive. It
seems, perhaps, that the bridge has stalled in some way whilst waiting?
I hooked up a second usb-serial adaptor (FTDI) to the small mcu TX and
the delayed data is definitely there, arriving with a one second delay
between each data byte. If the data is streamed continuously, both the
bridge and the FTDI see it; if I introduce a delay, only the FTDI sees
it.
Any light on what I might be doing wrong would be very gratefully
received.
Best wishes,
Tristan
|
|
From: Mikael N. <mik...@fl...> - 2021-11-06 04:11:40
|
Well done Tristan, The reason for stack size zero in the linker script is just to indicate to the linker not to reserve any stack space. So I do not think you have broken anything. Maybe you could publish your solution on github or somewhere? Myself I am considering moving FF to compile with XC8 assembler (pic-as). Some new chips (18f16q41) is only supported by XC8. Does gpasm have support for the 18f16q41 ? BR Mikael > The questions I have are - > > What is the reason for the STACK SIZE=0x0 RAM=usbep line in the > original linker file? And by commenting it out have I broken anything > I don't know about yet? -- -- Mikael |
|
From: Tristan W. <ho...@tj...> - 2021-11-05 20:57:44
|
Hello,
In preparation for my winter FlashForth project I thought I would try
using gpasm as assembler, and gplink as linker, with a
PIC18F14K50. Using them I got a working FlashForth 5 on my mcu, but I
have a question about the link process. This is what I did.
I am learning that each assembler/linker is different and gpasm found
fault where mpasm appeared not to [1],[2]. After editing the two clrf
statements that left the linker file issue [3].
[1]
usbcdc.asm:289:Error[128] Missing argument(s).
Error[181] System error while writing object file.
clrf ctrl_trf_state, ; WAIT_SETUP
[2]
ff-pic18.asm:2358:Error[128] Missing argument(s).
Error[181] System error while writing object file.
clrf UCON,
ff-pic18.asm:4047:Message[305] Using default destination of 1 (file).
[3]
error: No target memory available for section ".stack".
error: Linker script has no definition that matches the type of section ".stack".
error: Error while writing hex file.
Commenting out the STACK SIZE=0x0 RAM=usbep line removed the gplink
error. I flashed the hex file to the mcu and FlashForth was there via
USB.
//SECTION
//STACK SIZE=0x0 RAM=usbep
SECTION NAME=FORTH_VARS RAM=acs_ram
SECTION NAME=FLASH_BUF RAM=flashbuf
SECTION NAME=USER_AREA RAM=userarea
SECTION NAME=USB_EP RAM=usbep
SECTION NAME=USB_VARS RAM=usbvars
SECTION NAME=IRQ_STACK RAM=irqstack
SECTION NAME=FF_RESET ROM=coder
SECTION NAME=FF_INT_HI ROM=codeih
SECTION NAME=FF_END_CODE ROM=code1
SECTION NAME=FF_DP ROM=code2
The questions I have are -
What is the reason for the STACK SIZE=0x0 RAM=usbep line in the
original linker file? And by commenting it out have I broken anything
I don't know about yet?
Best wishes and thanks,
Tristan
|
|
From: Laszlo K. <Ko...@ce...> - 2021-11-02 11:37:03
|
Fortunately I do not have 'load' command at all. Thank you! Laci ________________________________ From: Stefan <fli...@gm...> Sent: Saturday, October 30, 2021 7:46 PM To: fla...@li... <fla...@li...> Subject: Re: [Flashforth-devel] Microsecond counter problem, please help Did you check the word 'load'? If it exists, Timer1 is used by the system-load-counter. For other purposes TCNT1 is 'read only' then. You could use 'us' (from the 'avr/forth'-subdirectory) to wait for a specified number of microseconds. If Timer1 is free for use -> see timertest.fs greetz bitflipser Am 30.10.2021 um 04:59 schrieb Mikael Nordman: > You have the wrong interrupt vector number. > > #14 constant TIMER1_OVF_vect > > BR Mikael > > On 2021-10-29 14:05, Laszlo Kollar wrote: >> I am newbie in forth and especially MCUs >> I would like to ask for help. >> I would like to write a driver for DHT-22 humidity/thermo sensor. It >> needs measure microsecond resolution changes in pin state, so I wrote a >> small code in order to count microseconds based on this article: >> https://www.reddit.com/r/arduino/comments/1q1chr/using_timer1_to_count_clock_cycles/ >> >> >> I try to implement it but failed in several various ways. >> once it looks like stuck in a infinity reset, sometimes no prompt after >> running, sometimes flood garbage when use 'words' after running the >> code. >> >> What mistake I made in this code? >> Please help me! >> >> Thanks in advance! >> >> László Kollár >> >> _______________________________________________ >> Flashforth-devel mailing list >> Fla...@li... >> https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
|
From: Laszlo K. <Ko...@ce...> - 2021-11-02 10:23:40
|
> You have the wrong interrupt vector number. Indeed, it is my fault! Thanks for the improved 'timer.fs' I am going to study it! Thaks again! Laci On Sun, 2021-10-31 at 06:36 +0200, Mikael Nordman wrote: > László, > > Just to show you an example of how to scale and format numbers > I added printing of the time in microseconds. > > In idle mode you can see that the measured time is always the same > because the execution of TIMERTEST is in sync with the millisecond > interrupt. > > In busy mode the execution time varies with 1 milliseconds depending > on > the > phase relationship of the TIMERTEST command and the millisecond > timer0. > > idle hex ok<$,ram> > timertest > counter: 18781d > time: 100225.812 us > ok<$,ram> > timertest > counter: 18781d > time: 100225.812 us > ok<$,ram> > busy hex ok<$,ram> > timertest > counter: 18a140 > time: 100884.0 us > decimal ok<#,ram> > timertest > counter: 1601046 > time: 100065.375 us > > > BR Mikael > > > On 2021-10-30 20:46, Stefan wrote: > > Did you check the word 'load'? If it exists, Timer1 is used by the > > system-load-counter. For other purposes TCNT1 is 'read only' then. > > You could use 'us' (from the 'avr/forth'-subdirectory) to wait for > > a > > specified number of microseconds. > > > > If Timer1 is free for use -> see timertest.fs > > > > greetz bitflipser > > > > > > Am 30.10.2021 um 04:59 schrieb Mikael Nordman: > > > You have the wrong interrupt vector number. > > > > > > #14 constant TIMER1_OVF_vect > > > > > > BR Mikael > > > > > > On 2021-10-29 14:05, Laszlo Kollar wrote: > > > > I am newbie in forth and especially MCUs > > > > I would like to ask for help. > > > > I would like to write a driver for DHT-22 humidity/thermo > > > > sensor. It > > > > needs measure microsecond resolution changes in pin state, so I > > > > wrote > > > > a > > > > small code in order to count microseconds based on this > > > > article: > > > > https://www.reddit.com/r/arduino/comments/1q1chr/using_timer1_to_count_clock_cycles/ > > > > > > > > > > > > I try to implement it but failed in several various ways. > > > > once it looks like stuck in a infinity reset, sometimes no > > > > prompt > > > > after > > > > running, sometimes flood garbage when use 'words' after running > > > > the > > > > code. > > > > > > > > What mistake I made in this code? > > > > Please help me! > > > > > > > > Thanks in advance! > > > > > > > > László Kollár > > > > > > > > _______________________________________________ > > > > Flashforth-devel mailing list > > > > Fla...@li... > > > > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > > > > > > > > _______________________________________________ > > Flashforth-devel mailing list > > Fla...@li... > > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2021-10-31 11:40:53
|
László, Just to show you an example of how to scale and format numbers I added printing of the time in microseconds. In idle mode you can see that the measured time is always the same because the execution of TIMERTEST is in sync with the millisecond interrupt. In busy mode the execution time varies with 1 milliseconds depending on the phase relationship of the TIMERTEST command and the millisecond timer0. idle hex ok<$,ram> timertest counter: 18781d time: 100225.812 us ok<$,ram> timertest counter: 18781d time: 100225.812 us ok<$,ram> busy hex ok<$,ram> timertest counter: 18a140 time: 100884.0 us decimal ok<#,ram> timertest counter: 1601046 time: 100065.375 us BR Mikael On 2021-10-30 20:46, Stefan wrote: > Did you check the word 'load'? If it exists, Timer1 is used by the > system-load-counter. For other purposes TCNT1 is 'read only' then. > You could use 'us' (from the 'avr/forth'-subdirectory) to wait for a > specified number of microseconds. > > If Timer1 is free for use -> see timertest.fs > > greetz bitflipser > > > Am 30.10.2021 um 04:59 schrieb Mikael Nordman: >> You have the wrong interrupt vector number. >> >> #14 constant TIMER1_OVF_vect >> >> BR Mikael >> >> On 2021-10-29 14:05, Laszlo Kollar wrote: >>> I am newbie in forth and especially MCUs >>> I would like to ask for help. >>> I would like to write a driver for DHT-22 humidity/thermo sensor. It >>> needs measure microsecond resolution changes in pin state, so I wrote >>> a >>> small code in order to count microseconds based on this article: >>> https://www.reddit.com/r/arduino/comments/1q1chr/using_timer1_to_count_clock_cycles/ >>> >>> >>> I try to implement it but failed in several various ways. >>> once it looks like stuck in a infinity reset, sometimes no prompt >>> after >>> running, sometimes flood garbage when use 'words' after running the >>> code. >>> >>> What mistake I made in this code? >>> Please help me! >>> >>> Thanks in advance! >>> >>> László Kollár >>> >>> _______________________________________________ >>> Flashforth-devel mailing list >>> Fla...@li... >>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel >> > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel -- -- Mikael |
|
From: Stefan <fli...@gm...> - 2021-10-30 18:16:57
|
Did you check the word 'load'? If it exists, Timer1 is used by the system-load-counter. For other purposes TCNT1 is 'read only' then. You could use 'us' (from the 'avr/forth'-subdirectory) to wait for a specified number of microseconds. If Timer1 is free for use -> see timertest.fs greetz bitflipser Am 30.10.2021 um 04:59 schrieb Mikael Nordman: > You have the wrong interrupt vector number. > > #14 constant TIMER1_OVF_vect > > BR Mikael > > On 2021-10-29 14:05, Laszlo Kollar wrote: >> I am newbie in forth and especially MCUs >> I would like to ask for help. >> I would like to write a driver for DHT-22 humidity/thermo sensor. It >> needs measure microsecond resolution changes in pin state, so I wrote a >> small code in order to count microseconds based on this article: >> https://www.reddit.com/r/arduino/comments/1q1chr/using_timer1_to_count_clock_cycles/ >> >> >> I try to implement it but failed in several various ways. >> once it looks like stuck in a infinity reset, sometimes no prompt after >> running, sometimes flood garbage when use 'words' after running the >> code. >> >> What mistake I made in this code? >> Please help me! >> >> Thanks in advance! >> >> László Kollár >> >> _______________________________________________ >> Flashforth-devel mailing list >> Fla...@li... >> https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
|
From: Mikael N. <mik...@fl...> - 2021-10-30 12:41:02
|
You have the wrong interrupt vector number. #14 constant TIMER1_OVF_vect BR Mikael On 2021-10-29 14:05, Laszlo Kollar wrote: > I am newbie in forth and especially MCUs > I would like to ask for help. > I would like to write a driver for DHT-22 humidity/thermo sensor. It > needs measure microsecond resolution changes in pin state, so I wrote a > small code in order to count microseconds based on this article: > https://www.reddit.com/r/arduino/comments/1q1chr/using_timer1_to_count_clock_cycles/ > > I try to implement it but failed in several various ways. > once it looks like stuck in a infinity reset, sometimes no prompt after > running, sometimes flood garbage when use 'words' after running the > code. > > What mistake I made in this code? > Please help me! > > Thanks in advance! > > László Kollár > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel -- -- Mikael |
17 messages has been excluded from this view by a project administrator.
