flashforth-devel Mailing List for FlashForth: for PIC and Atmega (Page 41)
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: Bob E. <bob...@ti...> - 2013-02-05 11:15:36
|
Hi Mike, No, I don't have a good source for encoders I'm afraid, but see below... High resolution shaft encoders are to be had http://www.bourns.com/ProductLine.aspx?name=magnetic_encoders but they're more expensive than I care to pay (£30 upwards) I've seen various diy techniques for radio tuning. Probably easiest and cheapest is the use of a stepper motor in generator mode, see http://www.webx.dk/oz2cpu/20m/encoder.htm. Bulky, but as long as the motor generates a large enough pulse at slow speed it works. A smaller low cost solution is now available using hall effect chips - see http://store.makerbot.com/magnetic-rotary-encoder.html. The chips alone are very cheap http://uk.farnell.com/jsp/search/browse.jsp?N=2031+203959&Ntk=gensearch&Ntt=magnetic+encoder&Ntx=mode+matchallpartial. I'm thinking of buying some AS5040 http://uk.farnell.com/ams/as5040-assu/encoder-magnetic-rotary-10bit-16ssop/dp/1630800 and button magnets and just wiring my own using 'dead bug' construction. OH2NLT uses that approach http://www.kolumbus.fi/juha.niinikoski/Hall_encoder/Hall_encoder.htm. Your quad math library looks very useful for synthesiser control - I needed 38 bit math for the SI570 chip, so will now start on a driver for that. I have a 2x16 LCD driver written - the PIC board came with this 2 wire circuit http://www.rentron.com/myke1.htm. I'll publish that in another email, it might be useful to someone. Best regards, Bob |
From: Mikael N. <mik...@pp...> - 2013-02-04 20:25:53
|
Great Bob, I was going to answer you that you do not need to modify the FF core. But you figured it out. Any idea where to find hi resolution shaft encoders with an analog feel to them ? I think 128 or 256 pulses per revolution should be enough. I am putting together a DDS synthesized HF receiver and a tuning knob would be nice. 73s de oh2aun /Mike On Mon, 2013-02-04 at 19:22 +0000, Bob Edwards wrote: > Hi Folks, > > Having asked about an interrupt driven shaft encoder I had a go > at programming with success on a PIC18F4450. This is my solution: - > > \ interrupt driven shaft encoder connected to portb bits 6 and 7 > \ free to use at your own risk - Bob Edwards G4BBY > > rbie intcon mclr > false di is irq ei > > -knob > marker -knob > > > $fff2 con intcon > $ff81 con portb > $ff93 con trisb > > > $1 con rbif > $8 con rbie > > > ram variable knobcount > ram variable oldportb > ram variable oldticks > > > : knob_int ( -- ) > [i > rbif intcon mtst > if > rbif intcon mclr > oldportb @ portb c@ $c0 and dup oldportb ! 2dup <> > if > 2/ xor $40 and > if > 1 > else > -1 > then > knobcount +! > else > 2drop > then > then > i] > ;i > > : knobgo ( -- ) > \ install knob interrupt > $c0 trisb mset > ['] knob_int is irq > rbie intcon mset > ; > > : readknob ( -- n1 n2) > \ n2 knob counts recieved in the last n1 milliseconds > di > ticks oldticks 2dup @ > - dup ?negate > >r ! r> > knobcount @ > 0 knobcount ! > ei > ; > > : knobstop ( -- ) > \ remove knob interrupt > rbie intcon mclr > false di is irq ei > ; > > Cheers, Bob > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_jan > _______________________________________________ Flashforth-devel mailing list Fla...@li... https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
From: Bob E. <bob...@ti...> - 2013-02-04 19:22:25
|
Hi Folks, Having asked about an interrupt driven shaft encoder I had a go at programming with success on a PIC18F4450. This is my solution: - \ interrupt driven shaft encoder connected to portb bits 6 and 7 \ free to use at your own risk - Bob Edwards G4BBY rbie intcon mclr false di is irq ei -knob marker -knob $fff2 con intcon $ff81 con portb $ff93 con trisb $1 con rbif $8 con rbie ram variable knobcount ram variable oldportb ram variable oldticks : knob_int ( -- ) [i rbif intcon mtst if rbif intcon mclr oldportb @ portb c@ $c0 and dup oldportb ! 2dup <> if 2/ xor $40 and if 1 else -1 then knobcount +! else 2drop then then i] ;i : knobgo ( -- ) \ install knob interrupt $c0 trisb mset ['] knob_int is irq rbie intcon mset ; : readknob ( -- n1 n2) \ n2 knob counts recieved in the last n1 milliseconds di ticks oldticks 2dup @ - dup ?negate >r ! r> knobcount @ 0 knobcount ! ei ; : knobstop ( -- ) \ remove knob interrupt rbie intcon mclr false di is irq ei ; Cheers, Bob |
From: Bob E. <bob...@ti...> - 2013-02-01 12:25:29
|
Has anyone implemented a shaft encoder by 'interrupt on change of input' with Flashforth? It needs a mod to ff18_usb.asm, am I right? I've been writing 2x16 char LCD driver words on a 18F4450 and wanted to add a 'tuning knob' before having a go at a SI570 programmable RF signal generator via the i2c interface. Flashforth very easy to use - I've been a hobbyist 'forther' for many years. I could poll the shaft encoder inputs, possibly from a timed interrupt, but that's not as efficient as the above. Cheers, Bob G4BBY |
From: Joe E. <jo...@wh...> - 2013-01-12 20:36:18
|
On Sat, 12 Jan 2013 15:16:48 +0200 Mikael Nordman <mik...@pp...> wrote: > On 12.1.2013 3:29, Joe Ennis wrote: > > I have an Arduino 2560 R3 that I've been using for some time and > > would like very much to test Flash Forth on it. > > > > Hi Joe, > I think going over the 128 Kbyte limit will require a bigger overhaul. > The Atmega registers can nicely address only 64 Kwords of flash. > To go above there are some page bits that need to be considered. > > Maybe the easiest thing would be to put FF completely in the > upper 64 Kword flash page. I assume the boot area is in the upper > page. > > Cheers /Mike Of course, guess I wasn't sober enough to catch that on the first pass. And yes, boot loader is in the high page. Time permitting, I'll dig into it and see what I can get done. I built a balancing two wheeled bot using the 2560 written using the Arduino IDE. It would be a lot of work writing all the library equivalents but, if we get enough snow this winter, it would surely help with the cabin fever. br, -- joe |
From: Mikael N. <mik...@pp...> - 2013-01-12 13:37:27
|
On 12.1.2013 3:29, Joe Ennis wrote: > I have an Arduino 2560 R3 that I've been using for some time and would > like very much to test Flash Forth on it. > Hi Joe, I think going over the 128 Kbyte limit will require a bigger overhaul. The Atmega registers can nicely address only 64 Kwords of flash. To go above there are some page bits that need to be considered. Maybe the easiest thing would be to put FF completely in the upper 64 Kword flash page. I assume the boot area is in the upper page. Cheers /Mike |
From: Joe E. <jo...@wh...> - 2013-01-12 01:51:35
|
This afternoon I fired up FFatmega on an Arduino Duemilanove 328p. Works really great, thanks Mike! I went into config.inc and added the Mega 2560.def then added a PFLASH conditional init to FlashForth.asm. Still does not asmemble. Lots of "rel branch out of range" and one or two more "unresolved symbols". Time permiting, I'll do what I can to get this going but it would be nice to have a config for the 2560. I have an Arduino 2560 R3 that I've been using for some time and would like very much to test Flash Forth on it. ciao, -- joe |
From: Peter J. <pe...@me...> - 2013-01-08 07:25:32
|
I've updated the tutorial and reference sheet over the new year. The new versions are at the same dropbox locations, as given below. Changes: 1. Added an I2C slave example to the tutorial. 2. Small edit to remove 0> from the reference sheet. Cheers, Peter J. On 08/10/12 14:37, Peter Jacobs wrote: >> Hi All, >> Over the past few months, I have been putting together a couple of >> documents to help engineering students get started with Flash Forth. >> The first is a tutorial guide that works through a few simple exercises. >> >> http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/ff-tutorial-guide.pdf >> >> The second is a companion reference document (Hitchhikers' Guide to >> FF) that tries to pack a more complete overview into a few pages. >> >> http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/flash-forth-sheet.pdf >> >> These documents are a work in progress and, although I have been >> tinkering with microcontrollers for a few years, I am a beginner with >> FF. I know that there are some (hopefully small) things that need fixing >> but I think that the documents are ready for use/review. Comments >> and corrections are most welcome. >> >> Regards, >> Peter Jacobs >> Mechanical Engineering, University of Queensland. >> >> |
From: Mikael N. <mik...@pp...> - 2012-11-03 19:52:17
|
Hi ! TRY FlashForth via TELNET now ! You can try now three different FF boards via Telnet ! A PIC18F2455 @ 48MHz connected via the native USB interface. telnet -l pic18f2455usb flashforth.dlinkddns.com A PIC18F2620 @ 12 MHz using the 38400 baud UART. telnet -l pic18f2620 flashforth.dlinkddns.com A PIC24HJ128 @ 55 MHz using the 38400 baud UART. telnet -l pic24hj128 flashforth.dlinkddns.com The secret is 'ff'. End the session with control-c. Commandline editing and history works via the READLINE library. This is not native telnet on the PIC. Just a login to the serial port on a linux box. BR Mike |
From: Peter J. <pe...@me...> - 2012-10-31 00:20:31
|
On 25/10/12 03:57, Pete Zawasky wrote: > Hi Peter, > > A simple edit on the "FlashForth Sheet". > > Under the "P Register" section, the first p@ should be @p . > > Pete > > Pete Zawasky > PZEF Co. > 361 Mills RD > Oriental, NC 28571 > www.pzef.net > pza...@pz... > 1-252-249-3393 (voice and fax) > 1-252-670-6940 (cell) > > ------------------------------------------------------------------------------ Fixed. Thank you. I put the revised PDF at http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/ as before, however, I've also put up a tar-file of my working directory. The LaTeX source is in a single file with the name "flash-forth-sheet.tex". Mike might like to keep this file with the FlashForth source code. Cheers, Peter J. |
From: Pete Z. <pza...@pz...> - 2012-10-24 17:57:16
|
Hi Peter, A simple edit on the "FlashForth Sheet". Under the "P Register" section, the first p@ should be @p . Pete Pete Zawasky PZEF Co. 361 Mills RD Oriental, NC 28571 www.pzef.net pza...@pz... 1-252-249-3393 (voice and fax) 1-252-670-6940 (cell) |
From: Mikael N. <mik...@pp...> - 2012-10-15 19:34:22
|
Thanks, I will put them up on the FF web. / Mike On 14.10.2012 13:55, Peter Jacobs wrote: > Tutorial and sheet have been updated following comments from > Mike and Pete. Same dropbox links as in the original post. > > I gave up trying to keep the Hitchhiker's guide within 4 pages. > The extra examples and the I2C words were worth adding already > and I expect that the document will expand (slowly) as time goes by. > > Cheers, > Peter J. > > On 08/10/12 14:37, Peter Jacobs wrote: >> Hi All, >> Over the past few months, I have been putting together a couple of >> documents to help engineering students get started with Flash Forth. >> The first is a tutorial guide that works through a few simple exercises. >> >> http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/ff-tutorial-guide.pdf >> >> The second is a companion reference document (Hitchhikers' Guide to >> FF) that tries to pack a more complete overview into a few pages. >> >> http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/flash-forth-sheet.pdf >> >> These documents are a work in progress and, although I have been >> tinkering with microcontrollers for a few years, I am a beginner with >> FF. I know that there are some (hopefully small) things that need fixing >> but I think that the documents are ready for use/review. Comments >> and corrections are most welcome. >> >> Regards, >> Peter Jacobs >> Mechanical Engineering, University of Queensland. >> >> >> ------------------------------------------------------------------------------ >> Don't let slow site performance ruin your business. Deploy New Relic APM >> Deploy New Relic app performance management and know exactly >> what is happening inside your Ruby, Python, PHP, Java, and .NET app >> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >> http://p.sf.net/sfu/newrelic-dev2dev >> _______________________________________________ >> Flashforth-devel mailing list >> Fla...@li... >> https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
From: Peter J. <pe...@me...> - 2012-10-14 10:55:35
|
Tutorial and sheet have been updated following comments from Mike and Pete. Same dropbox links as in the original post. I gave up trying to keep the Hitchhiker's guide within 4 pages. The extra examples and the I2C words were worth adding already and I expect that the document will expand (slowly) as time goes by. Cheers, Peter J. On 08/10/12 14:37, Peter Jacobs wrote: > Hi All, > Over the past few months, I have been putting together a couple of > documents to help engineering students get started with Flash Forth. > The first is a tutorial guide that works through a few simple exercises. > > http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/ff-tutorial-guide.pdf > > The second is a companion reference document (Hitchhikers' Guide to > FF) that tries to pack a more complete overview into a few pages. > > http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/flash-forth-sheet.pdf > > These documents are a work in progress and, although I have been > tinkering with microcontrollers for a few years, I am a beginner with > FF. I know that there are some (hopefully small) things that need fixing > but I think that the documents are ready for use/review. Comments > and corrections are most welcome. > > Regards, > Peter Jacobs > Mechanical Engineering, University of Queensland. > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
From: Mikael N. <mik...@pp...> - 2012-10-12 04:03:33
|
Hi Pete, The reason to use the HW wathdog is to recover from loops that hang when you are polling som hardware. The WDT timeout should be set in the FF configuration file to a longer time than what is the normal execution time of a HW poll. I usually configure the watchdog timeout to 0.5 seconds. PAUSE should get executed at least that often. The WDT is cleared in PAUSE. If you have a SW loop which is not polling HW, and it takes a long time to execute, you can clear the watchdog with PAUSE or CWD in the loop. For example a I2C device may for some reason never respond. The watchdog will then restart the CPU. If do not have any HW that possibly hangs, you can disable the watchdog in the CPU configuration bits. BR Mike On 12.10.2012 5:19, Pete Zawasky wrote: > Hi Mikael, > > Can you elucidate a bit on your philosophy for clearing the WDT in FF3.8? > Perhaps add some info to the User's Guide concerning the WDT. > > Pete > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
From: Pete Z. <pza...@pz...> - 2012-10-12 02:19:16
|
Hi Mikael, Can you elucidate a bit on your philosophy for clearing the WDT in FF3.8? Perhaps add some info to the User's Guide concerning the WDT. Pete |
From: Adam <ge...@in...> - 2012-10-10 20:10:51
|
Hi All, Suppose it brings nothing very important, but: - using FTDI USB to RS232 is fully transparent till now for me, some minor problems are with rs485 converters (tx/rx switching) - on 30f3011 FF works well if defined words are sent by UART as command (ascii) (& sw char used), with the same UART line (both debug/program and app) - on other doubled USART PIC (i.e.30f 6010a) is well to make the both debug and control the same time, esp with int defined, MODBUS i.e. - some trying the network version of simple FF app (using moxa eth/uart and delphi/server) as a test replace of bootloader ,with later 'J' version (eth inside) of PIC as a target, in mind to find similar to tibbo module, could be some kind of test to check it through the ocean... ;-) - if some others tried that... Other idea of the forth itself (I'm not in force/time to check it now) could be to replace the words with exact long asm code of each words used rather then 'standard' forth commands/jump - it should bring the same speed /length as asm/c definition but is memory usage trash. On PC there exist the Forth using this philosophy, also some forth implementation exists for '51 (all forth words definition are on PC, and result word is made only as long structure compiled once) regards Adam ps. some first time problems with FF was for me to find the peripherial off (PMD reg def in source) pps if there is implementation of 18f4550/2550 (USB) with FF usage, - nice to know that "Mikael Nordman" <mik...@pp...> pisze: > Myself, I have never used an USB-UART bridge with FlashForth. > I suppose one would use SW flow control with that. > Maybe some extra TX delays could be needed for that, if the latency of > the bridge is high. > > Mike > > On 10.10.2012 15:52, Peter Jacobs wrote: > > Mike, Pete, > > Thanks for the useful and very encouraging comments. > > I'll probably get to work on this again over the weekend when > > I'll dust off an old Windows machine and try out the various > > terminal programs that the students are likely to use. > > So far, I've been concentrating on just using the UART > > interface on the MCU and in all cases have used one of > > several USB-to-UART bridges that I have available. Much > > of the custom instrumentation that interests me is timing > > sensitive and I want to minimize the number of things that > > the MCU has to deal with. > > You are most welcome to put the documents on the FF > > web. In the next few days (hopefully), I'll clean up the > > issues that you've identified. > > Cheers, > > Peter J. > > > > > > On 09/10/12 06:02, Mikael Nordman wrote: > >> Hi Pete > >> Firstly, I want to say what a nice tutorial it is. > >> -- > >> About the tutorial and flow control. > >> > >> In the cutecom picture you combine the USB with SW flow control. > >> With the USB interface one must use HW flow control. > >> The intercharacter delay is not needed. > >> > >> With the UART and SW flow control, no delays should be needed > >> when you set the UART into low latency mode(linux) > >> or remove the UART FIFOs from use(windows). > >> > >> Having the delay there makes the serial operation just work, but it also > >> makes loading of files quite slow. > >> > >> -- > >> About the hitchikers guide. > >> > >> Do not call VALUE VNAME a variable, but just call it value VNAME. > >> Explain that TO sets a new value into the VNAME. > >> > >> Formatted strings are constructed before the PAD in the end of TIB. > >> Not in PAD which has 0 as default size. > >> > >> If you are using the default values of the p18f-main.cfg > >> the following is valid for the UART version. > >> SRAM is further subdivided as: > >> $f000 - $f03f 64-byte flash write buffer > >> $f040 - $f05f 32-byte used internall by FF > >> $f060 - $f06f 16-byte interrupt parameter stack > >> $f070 - $f093 36-byte RX an TX buffers > >> $f094 - $f09d 10-byte mirror of turnkey, dp, latest > >> $f09e - $f09f 2-byte interrupt vector > >> $f0a0 - $foa1 2-byte user pointer > >> $f0a2 - $f1b1 user area for operator task > >> $f1b2 - $ff5f free for application use (up to RAM HI) > >> $ff60 - $ffff special function registers > >> > >> -- > >> May I store copies of these documents on the FF web ? > >> > >> / Mike > >> > >> > > > > > > ------------------------------------------------------------------------------ > > Don't let slow site performance ruin your business. Deploy New Relic APM > > Deploy New Relic app performance management and know exactly > > what is happening inside your Ruby, Python, PHP, Java, and .NET app > > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > > http://p.sf.net/sfu/newrelic-dev2dev > > _______________________________________________ > > Flashforth-devel mailing list > > Fla...@li... > > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
From: Mikael N. <mik...@pp...> - 2012-10-10 17:05:14
|
Myself, I have never used an USB-UART bridge with FlashForth. I suppose one would use SW flow control with that. Maybe some extra TX delays could be needed for that, if the latency of the bridge is high. Mike On 10.10.2012 15:52, Peter Jacobs wrote: > Mike, Pete, > Thanks for the useful and very encouraging comments. > I'll probably get to work on this again over the weekend when > I'll dust off an old Windows machine and try out the various > terminal programs that the students are likely to use. > So far, I've been concentrating on just using the UART > interface on the MCU and in all cases have used one of > several USB-to-UART bridges that I have available. Much > of the custom instrumentation that interests me is timing > sensitive and I want to minimize the number of things that > the MCU has to deal with. > You are most welcome to put the documents on the FF > web. In the next few days (hopefully), I'll clean up the > issues that you've identified. > Cheers, > Peter J. > > > On 09/10/12 06:02, Mikael Nordman wrote: >> Hi Peter, >> Firstly, I want to say what a nice tutorial it is. >> -- >> About the tutorial and flow control. >> >> In the cutecom picture you combine the USB with SW flow control. >> With the USB interface one must use HW flow control. >> The intercharacter delay is not needed. >> >> With the UART and SW flow control, no delays should be needed >> when you set the UART into low latency mode(linux) >> or remove the UART FIFOs from use(windows). >> >> Having the delay there makes the serial operation just work, but it also >> makes loading of files quite slow. >> >> -- >> About the hitchikers guide. >> >> Do not call VALUE VNAME a variable, but just call it value VNAME. >> Explain that TO sets a new value into the VNAME. >> >> Formatted strings are constructed before the PAD in the end of TIB. >> Not in PAD which has 0 as default size. >> >> If you are using the default values of the p18f-main.cfg >> the following is valid for the UART version. >> SRAM is further subdivided as: >> $f000 - $f03f 64-byte flash write buffer >> $f040 - $f05f 32-byte used internall by FF >> $f060 - $f06f 16-byte interrupt parameter stack >> $f070 - $f093 36-byte RX an TX buffers >> $f094 - $f09d 10-byte mirror of turnkey, dp, latest >> $f09e - $f09f 2-byte interrupt vector >> $f0a0 - $foa1 2-byte user pointer >> $f0a2 - $f1b1 user area for operator task >> $f1b2 - $ff5f free for application use (up to RAM HI) >> $ff60 - $ffff special function registers >> >> -- >> May I store copies of these documents on the FF web ? >> >> / Mike >> >> > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
From: Peter J. <pe...@me...> - 2012-10-10 12:52:28
|
Mike, Pete, Thanks for the useful and very encouraging comments. I'll probably get to work on this again over the weekend when I'll dust off an old Windows machine and try out the various terminal programs that the students are likely to use. So far, I've been concentrating on just using the UART interface on the MCU and in all cases have used one of several USB-to-UART bridges that I have available. Much of the custom instrumentation that interests me is timing sensitive and I want to minimize the number of things that the MCU has to deal with. You are most welcome to put the documents on the FF web. In the next few days (hopefully), I'll clean up the issues that you've identified. Cheers, Peter J. On 09/10/12 06:02, Mikael Nordman wrote: > Hi Peter, > Firstly, I want to say what a nice tutorial it is. > -- > About the tutorial and flow control. > > In the cutecom picture you combine the USB with SW flow control. > With the USB interface one must use HW flow control. > The intercharacter delay is not needed. > > With the UART and SW flow control, no delays should be needed > when you set the UART into low latency mode(linux) > or remove the UART FIFOs from use(windows). > > Having the delay there makes the serial operation just work, but it also > makes loading of files quite slow. > > -- > About the hitchikers guide. > > Do not call VALUE VNAME a variable, but just call it value VNAME. > Explain that TO sets a new value into the VNAME. > > Formatted strings are constructed before the PAD in the end of TIB. > Not in PAD which has 0 as default size. > > If you are using the default values of the p18f-main.cfg > the following is valid for the UART version. > SRAM is further subdivided as: > $f000 - $f03f 64-byte flash write buffer > $f040 - $f05f 32-byte used internall by FF > $f060 - $f06f 16-byte interrupt parameter stack > $f070 - $f093 36-byte RX an TX buffers > $f094 - $f09d 10-byte mirror of turnkey, dp, latest > $f09e - $f09f 2-byte interrupt vector > $f0a0 - $foa1 2-byte user pointer > $f0a2 - $f1b1 user area for operator task > $f1b2 - $ff5f free for application use (up to RAM HI) > $ff60 - $ffff special function registers > > -- > May I store copies of these documents on the FF web ? > > / Mike > > |
From: Pete Z. <pza...@pz...> - 2012-10-09 18:44:38
|
I agree with Mikael, Excellent work on the "FF Tutorial and Guide" and the "FlashForth Sheet". The FF Sheet is long overdue on the Source Forge FF page if you will allow Mikael to post it for download. Having followed along, mostly in the background, since Mikael started FF and the FF presence on FF, I would say there have often been questions concerning the communications connection to FF (uart or usb). Perhaps a bit more explanation and examples are in order in both the Tutorial and on the Guide Sheet. I have the best results on various PIC18 and PIC30 chips with Tera Term. Again, thanks for the effort and I hope your students will enjoy FF. Pete Pete Zawasky PZEF Co. 361 Mills RD Oriental, NC 28571 www.pzef.net pza...@pz... 1-252-249-3393 (voice and fax) 1-252-670-6940 (cell) *<https://sourceforge.net/mailarchive/message.php?msg_id=29936169>* |
From: Pete Z. <pza...@pz...> - 2012-10-08 20:06:56
|
Hi Peter, Definitely needed. I will also try to review the documents. Thanks, Pete |
From: Mikael N. <mik...@pp...> - 2012-10-08 20:02:43
|
Hi Peter, Firstly, I want to say what a nice tutorial it is. -- About the tutorial and flow control. In the cutecom picture you combine the USB with SW flow control. With the USB interface one must use HW flow control. The intercharacter delay is not needed. With the UART and SW flow control, no delays should be needed when you set the UART into low latency mode(linux) or remove the UART FIFOs from use(windows). Having the delay there makes the serial operation just work, but it also makes loading of files quite slow. -- About the hitchikers guide. Do not call VALUE VNAME a variable, but just call it value VNAME. Explain that TO sets a new value into the VNAME. Formatted strings are constructed before the PAD in the end of TIB. Not in PAD which has 0 as default size. If you are using the default values of the p18f-main.cfg the following is valid for the UART version. SRAM is further subdivided as: $f000 - $f03f 64-byte flash write buffer $f040 - $f05f 32-byte used internall by FF $f060 - $f06f 16-byte interrupt parameter stack $f070 - $f093 36-byte RX an TX buffers $f094 - $f09d 10-byte mirror of turnkey, dp, latest $f09e - $f09f 2-byte interrupt vector $f0a0 - $foa1 2-byte user pointer $f0a2 - $f1b1 user area for operator task $f1b2 - $ff5f free for application use (up to RAM HI) $ff60 - $ffff special function registers -- May I store copies of these documents on the FF web ? / Mike |
From: Mikael N. <mik...@pp...> - 2012-10-08 05:54:07
|
Thanks a lot Peter ! Really nice work, and long overdue for FF. I'll check them out, and comment. Cheers /Mike On 8.10.2012 7:37, Peter Jacobs wrote: > Hi All, > Over the past few months, I have been putting together a couple of > documents to help engineering students get started with Flash Forth. > The first is a tutorial guide that works through a few simple exercises. > > http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/ff-tutorial-guide.pdf > > The second is a companion reference document (Hitchhikers' Guide to > FF) that tries to pack a more complete overview into a few pages. > > http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/flash-forth-sheet.pdf > > These documents are a work in progress and, although I have been > tinkering with microcontrollers for a few years, I am a beginner with > FF. I know that there are some (hopefully small) things that need fixing > but I think that the documents are ready for use/review. Comments > and corrections are most welcome. > > Regards, > Peter Jacobs > Mechanical Engineering, University of Queensland. > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
From: Peter J. <pe...@me...> - 2012-10-08 04:37:35
|
Hi All, Over the past few months, I have been putting together a couple of documents to help engineering students get started with Flash Forth. The first is a tutorial guide that works through a few simple exercises. http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/ff-tutorial-guide.pdf The second is a companion reference document (Hitchhikers' Guide to FF) that tries to pack a more complete overview into a few pages. http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/flash-forth-sheet.pdf These documents are a work in progress and, although I have been tinkering with microcontrollers for a few years, I am a beginner with FF. I know that there are some (hopefully small) things that need fixing but I think that the documents are ready for use/review. Comments and corrections are most welcome. Regards, Peter Jacobs Mechanical Engineering, University of Queensland. |
From: Peter J. <pe...@me...> - 2012-09-30 12:50:44
|
To answer Lowell Bruson: Yes, I've been happily using a copy of FF38 that was built with MPLAB X. Presently, I have tried only the USART version on a PIC18F2520. PeterJ |
From: Lowell B. <low...@gm...> - 2012-09-26 06:06:37
|
Has anyone attempted to build under Microchip's new MPLAB X? I am considering moving all my projects from mplab 8 to X so I can drop windows completely. Lowell |