flashforth-devel Mailing List for FlashForth: for PIC and Atmega (Page 36)
Brought to you by:
oh2aun
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: Anders E. <ska...@te...> - 2014-03-03 21:05:36
|
Is there any chance that someone on this list is interested in writing FF for the PIC32? Best regards, /anders |
From: Doug J. <do...@do...> - 2014-03-03 20:34:01
|
YAY! On 4/03/2014 6:15 AM, Mikael Nordman wrote: > BASE is back. > FLASH HI was wrong on PIC24 and ATmega. Fixed. > HELP now words with CR NL or any combination thereof in the helpwords file. > TMR 4,5,6 added for PIC18. > > BR Mike > > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and the > freedom to use Git, Perforce or both. Make the move to Perforce. > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > |
From: Doug J. <do...@do...> - 2014-03-03 20:33:58
|
On 3/03/2014 11:30 PM, craig bair wrote: > Point is, if you prevent everyone from doing something stupid, you prevent someone else from doing something extremely clever... Don't let seatbelts become straight-jackets. > That's what I love about Forth - It is a real language - warts and all. - It doesn't hold your hand. It was never designed to gently stroke your arm while saying "That's ok - you can do it...." - It does *exactly* what you ask, when you ask, and how you ask. It doesn't say - "Hang on, I have to talk to the floppy disk for the next 5 seconds..." - It Never says "Are You Sure (Y/N)?" - If you would like to drop the dictionary containing your words, you are welcoime to, even while running the program that relied on them. Thats dynamic! Anything else looks way too much like BASIC for me :-) Doug |
From: Mikael N. <mik...@pp...> - 2014-03-03 20:27:57
|
Which chip ? |
From: Herman A. <exp...@vn...> - 2014-03-03 19:56:23
|
Hi Mikael I have tried to compile the latest version to try the timers, but the comilation was unsuccesful: Error - section 'IRQ_STACK' has a memory 'irqstack' which can not fit the section. Section 'IRQ_STACK' length=0x000001ba. It was independent on timer selection. BR Attila |
From: Mikael N. <mik...@pp...> - 2014-03-03 19:17:39
|
On 03/03/2014 01:58 AM, Herman Attila wrote: > Hi Mikael, > > After all I have a suggestion. The 18F2xK22-4xK22 controllers have several timers. > Sometimes would be fine to select the TMR4,5,6 for MS_TMR to keep the TMR1,2,3 free for other usage I added the timers, can you check if they work ? I have no possibility. BR Mike |
From: Mikael N. <mik...@pp...> - 2014-03-03 19:16:02
|
BASE is back. FLASH HI was wrong on PIC24 and ATmega. Fixed. HELP now words with CR NL or any combination thereof in the helpwords file. TMR 4,5,6 added for PIC18. BR Mike |
From: Mikael N. <mik...@pp...> - 2014-03-03 16:22:52
|
Alright, I can unhide BASE as a compilation option. Although in my opinion using anything else than BIN, HEX, DECIMAL as base is an amusing curiosity. And when I demoed it I always got some wise-xxx putting it to zero or one. BR Mike On 03/03/2014 10:31 AM, Peter Jacobs wrote: > Not hiding BASE is my preference also. Some of the robustness might be > regained by filtering out bad values and defaulting to one of the known > good values (hex seems to be a favoured option). > Peter J. > > > On 03/03/14 18:14, Kit Latham wrote: >> Hello >> >> My 2 pence worth, I would also prefer BASE to be available - most of my stuff is permanent HEX. >> >> Cheers >> >> Kit >> >> >> -----Original Message----- >> From: Herman Attila [mailto:exp...@vn...] >> Sent: 03 March 2014 07:30 >> To: fla...@li... >> Subject: Re: [Flashforth-devel] FF5.0 Base hidden >> >> I am not happy with hidden base, too. Sometimes I save the current base and restore it after using another one in a word, if I want to change it temorarily only. How can I do it, if base is hidden? I think the robustness is not enough reason to make it hidden. >> Otherwise in my opinion it is not rationale to see the decimal as a normal base. It is absolutely application depended. >> >> Attila >> |
From: Mikael N. <mik...@pp...> - 2014-03-03 16:17:06
|
I have not used the Atmega I2C yet so I have not implemented any support for that. A contribution is of course welcome. Either in Forth or assembly. BR Mike On 03/03/2014 10:39 AM, Peter Jacobs wrote: > My guess is that Mike had done the PIC18 i2c words as a demonstration > for the PIC18 assembler. Building corresponding AVR words with his > recently-written AVR assembler would be a good exercise for someone > like you or me. It's on my list of things to try but I haven't got to it. > Peter J. > > > On 03/03/14 17:54, rfr...@gm... wrote: >> Hallo >> I would like to know why the i2c words aren't implemented in the AVR >> Version. >> What should i do to implement them? Is there anything which can be >> reloaded? >> Mit freundlichem Gruss >> >> R.Freitag >> |
From: craig b. <dab...@ya...> - 2014-03-03 12:33:13
|
IMHO: as an old guard FORTH acquaintance, besides being defined in the language spec, BASE is amusing to have available to play with. I routinely use words to print that chamge to a specific base and return the system to previous condition. I think assembler in hex and data in decimal. Binary is occasionally usefull with ports, and even octal is handy on occasion... Then something plays a Tom Leaher song that's got base 7 or you want to lead sonething in with a count of seventeen... Point is, if you prevent everyone from doing something stupid, you prevent someone else from doing something extremely clever... Don't let seatbelts become straight-jackets. craig bair ...averaging may or may not help clarify data. If Bill Gates walks into a bar, the average patron becomes a millionaire... |
From: Peter J. <pe...@me...> - 2014-03-03 08:39:40
|
My guess is that Mike had done the PIC18 i2c words as a demonstration for the PIC18 assembler. Building corresponding AVR words with his recently-written AVR assembler would be a good exercise for someone like you or me. It's on my list of things to try but I haven't got to it. Peter J. On 03/03/14 17:54, rfr...@gm... wrote: > Hallo > I would like to know why the i2c words aren't implemented in the AVR > Version. > What should i do to implement them? Is there anything which can be > reloaded? > Mit freundlichem Gruss > > R.Freitag > > [x ] Köln > [ ] Stuttgart > [ ] Vilsbiburg > [ ] Finkenwerder > [ ] Berlin > [ ] Überlingen > [ ] Ingolstadt > [ ] Frankfurt > [] Radolfzell |
From: Peter J. <pe...@me...> - 2014-03-03 08:31:51
|
Not hiding BASE is my preference also. Some of the robustness might be regained by filtering out bad values and defaulting to one of the known good values (hex seems to be a favoured option). Peter J. On 03/03/14 18:14, Kit Latham wrote: > Hello > > My 2 pence worth, I would also prefer BASE to be available - most of my stuff is permanent HEX. > > Cheers > > Kit > > > -----Original Message----- > From: Herman Attila [mailto:exp...@vn...] > Sent: 03 March 2014 07:30 > To: fla...@li... > Subject: Re: [Flashforth-devel] FF5.0 Base hidden > > I am not happy with hidden base, too. Sometimes I save the current base and restore it after using another one in a word, if I want to change it temorarily only. How can I do it, if base is hidden? I think the robustness is not enough reason to make it hidden. > Otherwise in my opinion it is not rationale to see the decimal as a normal base. It is absolutely application depended. > > Attila > > |
From: Kit L. <Ki...@fo...> - 2014-03-03 08:27:46
|
Hello My 2 pence worth, I would also prefer BASE to be available - most of my stuff is permanent HEX. Cheers Kit -----Original Message----- From: Herman Attila [mailto:exp...@vn...] Sent: 03 March 2014 07:30 To: fla...@li... Subject: Re: [Flashforth-devel] FF5.0 Base hidden I am not happy with hidden base, too. Sometimes I save the current base and restore it after using another one in a word, if I want to change it temorarily only. How can I do it, if base is hidden? I think the robustness is not enough reason to make it hidden. Otherwise in my opinion it is not rationale to see the decimal as a normal base. It is absolutely application depended. Attila ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Flashforth-devel mailing list Fla...@li... https://lists.sourceforge.net/lists/listinfo/flashforth-devel Scanned by MailDefender - managed email security from TSG - http://maildefender.tsg.com |
From: <rfr...@gm...> - 2014-03-03 07:54:44
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hallo</div> <div> </div> <div>I would like to know why the i2c words aren't implemented in the AVR Version.</div> <div> </div> <div>What should i do to implement them? Is there anything which can be reloaded?<br/> </div> <div class="signature">Mit freundlichem Gruss<br/> <br/> R.Freitag<br/> <br/> [x ] Köln<br/> [ ] Stuttgart<br/> [ ] Vilsbiburg<br/> [ ] Finkenwerder<br/> [ ] Berlin<br/> [ ] Überlingen<br/> [ ] Ingolstadt<br/> [ ] Frankfurt<br/> [] Radolfzell</div></div></body></html> |
From: Herman A. <exp...@vn...> - 2014-03-03 07:30:35
|
I am not happy with hidden base, too. Sometimes I save the current base and restore it after using another one in a word, if I want to change it temorarily only. How can I do it, if base is hidden? I think the robustness is not enough reason to make it hidden. Otherwise in my opinion it is not rationale to see the decimal as a normal base. It is absolutely application depended. Attila |
From: Mikael N. <mik...@pp...> - 2014-03-03 05:20:41
|
Good idea. And easy to implement. BR Mike |
From: Mikael N. <mik...@pp...> - 2014-03-03 05:19:51
|
BASE is hidden for robustness. For example 1 BASE ! does some strange stuff. HEX, BIN, DECIMAL is what I have ever needed in practice. Elizabeth Conklin mentioned the rationale that decimal is the normal base that words that change base should return to. I admit FF does not follow that rule :-) , either. BR Mike On 03/03/2014 04:58 AM, pza...@pz... wrote: > Hi Mikael, > > and my question is .... Why is BASE now hidden? BASE is a FORTH Core > word. > > Pete > > > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and the > freedom to use Git, Perforce or both. Make the move to Perforce. > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
From: <pza...@pz...> - 2014-03-03 03:10:14
|
Hi Mikael, and my question is .... Why is BASE now hidden? BASE is a FORTH Core word. Pete |
From: Herman A. <exp...@vn...> - 2014-03-02 23:58:46
|
Hi Mikael, After all I have a suggestion. The 18F2xK22-4xK22 controllers have several timers. Sometimes would be fine to select the TMR4,5,6 for MS_TMR to keep the TMR1,2,3 free for other usage. BR Attila |
From: Mikael N. <mik...@pp...> - 2014-03-02 08:12:32
|
Hi Attila, Thanks for the info. I noticed the same thing a few years ago bút did not do anything about it. Now for FF 5.0: I have added DECIMAL in TINIT. FF now also catches divide by zero errors and restarts. BASE is hidden so it cannot be ticked anymore. HEX BIN DECIMAL can be used. Do you have any other suggestions for FF 5.0 before I freeze it ? BR Mikael |
From: Herman A. <exp...@vn...> - 2014-03-02 00:48:33
|
Hi Mikael There is a disturbing thing using pictured output in task. The base (radix) of task is not initialised automatically neither at creating nor initiating of task. If I forget to set the base in task a legal value, it will remain zero. Generating the pictured numeric output, the illegal value of base couse not only a hangup, but usually destroys the FF system. It would be practical to set the base a default value automatically at the creating or initiating of task. Perhaps it can inherit the actual base value of operator task. BR Attila |
From: Mikael N. <mik...@pp...> - 2014-02-28 05:57:47
|
If you want compiled code speeds, naturally you have to compile the code :-) There are some delays because the interpreter takes time to process the input line one word at a time. Another source of delay is if you have idle mode configured. In every PAUSE FF sleeps until the next interrupt. You can get rid off that by compiling FF with the idle mode disabled. The FF3.8 BUSY IDLE words are tricky to use, but are simplified in FF5.0 which you can find in GIT. I have not tried higher baudrates. Even if these could be configured, in practice the PIC18 cannot process data at those speeds. BR Mike On 02/28/2014 05:09 AM, craig bair wrote: > Sorry for the delay, things got crazed and I couldn't get back online > for a while there. > > As it turns out, putting the flag clearing after the buffer write > really did solve my problem, but there was this matter of scale with > the BitScope and its triggering. I'm guessing that there's some odd > interaction going on between some of the routines, the interpreter, > and the time-slicing of the multi-tasker. Entering the words as a > line interactively there was a 10 ms delay between the ssen and the > first sspbuf! with another 4 ms till the next sspbuf!. The little > pocket BS-10 wasn't retriggering on the second write leading to the > misinterpretation of events. It also wasn't happy about slowing down > enough to show the whole sequence, but eventually co-operated. > > Rolling the desired sequence together into a single word works much > more smoothly. Do interactive sessions often do this? I for one > normally wouldn't notice if it did under most circumstances. > > On an almost unrelated note, have you ever pushed a Pic18 UART to > 230.4K baud or 460.8K baud? I may have need to run that or higher > bit-rates between chips for a project and the numbers look like it > might be possible when clocking the pics at 48-64Mhz. One problem I > see is that I don't have a serial port that runs that fast to watch > them with. I hope that one of the FTDI usb-to-uart interface boards > can give me a virtual serial that can handle it, but I'm experimenting > blind at this point. Tera Term does have settings up to 921.6K, after > all....(grin) > > Keep up the good work! > craig > ...averaging may or may not help clarify data. > If Bill Gates walks into a bar, > the average patron becomes a millionaire... > > ------------------------------------------------------------------------ > ** > When quickly checking the datasheet I saw no requirement for the slave > to respond for sspif to be set. In the datasheet sspif is cleared after > writing to sspbuf. In the current code sspif is cleared before writing > to sspbuf. You could try this. : sspbuf! ( c -- ) \ sspbuf! takes 90 us > @ 100 KHz > sspbuf c! > [ pir1 sspif a, bcf, ] > [ begin, ] > [ pir1 sspif a, btfss, ] > [ again, ] > ; > Mikael > > |
From: Mikael N. <mik...@pp...> - 2014-02-27 05:37:15
|
When quickly checking the datasheet I saw no requirement for the slave to respond for sspif to be set. In the datasheet sspif is cleared after writing to sspbuf. In the current code sspif is cleared before writing to sspbuf. You could try this. : sspbuf! ( c -- ) \ sspbuf! takes 90 us @ 100 KHz sspbuf c! [ pir1 sspif a, bcf, ] [ begin, ] [ pir1 sspif a, btfss, ] [ again, ] ; Mikael |
From: craig b. <dab...@ya...> - 2014-02-27 04:23:18
|
I'm coming back to FORTH after being away for a while including programming PIC16-s in assembler for a couple of decades. I've never really gotten the I2c mode of the MSSP module to work, I've always just fallen back on bit-banging a couple of I/O pins and been done with it. I now have a PIC18F4458 with FlashForth 3.8 up and ticking along on a 48Mhz oscillator with customized A/D routines to do 12-bit reads, and the included I2cBase routines loaded (tweaked for PortB SCL & SDA) because I also need to talk to ADS1100 I2c A/D converter chips. I don't actually have any I2c devices to talk to yet, but I have 10K pullups on the 2 pins and a BitScope attached to watch behavior. The I2cINIT, SSEN, and SPEN routines work as expected. I can even stick an i2c@nak in the middle and it runs straight through. What doesn't seem to work for me is the sspbuf! routine. I can't see any sign that pir1.sspif is ever changing after I clear it. The SCL pulses and data states for that one byte go out and then it just hangs. I have to ^O it to get out... which leaves little to diagnose with. the only thing that calls it and "works" is I2cWS which sits there madly banging the pins continuously untill I ^O that, too. Obviously I'm missing something, is it an I2c Slave on the bus? I won't get that for a day or more and if that's the problem, how can I test for that condition and keep running? I can still load up the FF Assembler and write yet another I2c bitbanger, but I was really hoping to get the hardware to work this time. If anyone can help point me in the right direction, I would be much obliged... Thanks for reading this, you're either very patient or completely bored (grin). craig bair ...averaging may or may not help clarify data. If Bill Gates walks into a bar, the average patron becomes a millionaire... |
From: Mark G. <bit...@gm...> - 2014-02-13 18:53:06
|
That did the trick! Thank you. -mdg On Thu, Feb 13, 2014 at 1:41 PM, Mikael Nordman <mik...@pp...> wrote: > What about now. > There was still the real bug left. I had commented out interrupt enable > in WARM. > That prevented the system clock from running and the TX0 send timeout > did not work. > > BR > > On 02/13/2014 07:59 PM, Mark Goldman wrote: >> >> Still no joy on the 2550 on my dev board. >> >> I did a clean clone and adjusted the oscillator to match my 20Mhz >> crystal. Same behavior as last night. >> >> -mdg >> >> On Feb 13, 2014 12:34 AM, "Mikael Nordman" <mik...@pp... >> <mailto:mik...@pp...>> wrote: >> >> I just pushed a solution to the tmr1 and tm3 problem. >> > > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel -- Our problems are mostly behind us, now all we have to do is fight the solutions. |