I'm mistake.
I have misunderstood word'forget' also re-write eeprom.
I get tricked like this all the time. Words seems like the SHOULD do a bunch of "extra" stuff, but their power is that they do the simplest thing to get the job done.
In summary:
FORGET only moves HERE back to the address of the definition being forgotten.
SAVEFORTH writes the current contents of ram into eeprom.
we are looking at demo options.
The current logger has realtime clock implemented, the only issue is setting the clock accurately and automatically.
We are looking at radio time synchronization. Of course, it might be easier and cheaper to set the ttime manually, and use a realtime chip such as DS1302. Our options so far are some combination of:
DS1302
WWV
GPS
Each of these might be handy in certain situations. Sal's criterion is that we need to determine what people would actually want to DO. The software to automatically adjust the clock in referece to a known source already exists (in the DS1302 and IP drivers). Adding an interface to a WWV or GPS would remove the manual time setting step, which might be useful in for example solar powered remote applicattions. I'm thinking a solar powered app could occasionally lose power if it were cloudy for too long. So the investigation is to determine a radio reciever that can be had for a reasonable (under $20?) cost.
The remainder of the discussion was PF6.0 development.
Sorry, needing Clock-stretch is wrong.
Original i2c-word(_eestart, _eewrite, _eestop) use output-port at going to hi for scl.
It seems to disturb writing register-value about ADT7410.
Maybe I think _eeread also need to re-write.
Sunday's Call:
We've been debugging the PF6 build automation. One of the issues was caused by poor power being supplied by the PC USB to the quickstart, the same issue ocures with a wonky wall-wart on the protoboard.
Sal was able to overcome the issue by placing a capacitor between Vin and ground on the quickstart. But he does NOT recommend this, the capacitor could cause damage the PC at power up or power down; the solution is to get a good power supply, and or ensure the laptop can deliver clean reliable power to the quick start. In any case, this is why Sal always starts a project by building a power supply correctly sized for the task at hand. In my case, I don;t know about building power supplies. Maybe a powered USB hub will be the general solution.
Hi.
I tried to read/write RH6010's register by new i2c-WORDS.
I could read/write register0(Config1) and register1(Config2).
Refering #340 in this thread.
Not yet read correctly Touch-Sense data(register2).
Data for register2 is always 0.
Pulses for scl/sda is normal. ( I checked them by oscilloscope)
When resetting on connecting RH6010 to scl/sda for propeller, Forth can not reboot.
It seems Propeller can not read eeprom.
When removing scl-line of RH6010, Forth can reboot.
Accessing(boot-code inside propeller) to i2c-devices from propeller is not perfect?
Or RH6010 is out of i2c-spec?
When current is 0, mode display only Current and USB-Voltage
Current is max 2000mA.
Time display passing time and total-current.
Time is max99Hour59Min59Sec.
This use voltage(200mV) from signal-supply for test.
Today's Call:
The turmoil at the Braino Lab (emptying out the house for major remodeling during record snow and cold, because it waiting until Spring would be just silly) has finally wound down. Hopefully we can return to our regular pattern.
Sal looked at Issue 215, "serial parameter n3 is baud divided by 4". Sal finds that Art's way of stating it is much clearer, and will update the docs next release.
Which bring up the larger issue of documentation strategy. PropForth.htm will move from being included in the download archive to the wiki. Every successful online project has online documentation, and if we need an offline copy, we can grab ourselves.
We are looking into organizing the wiki documentations into sections, and having users add and maintain the content. An example of the documentation organization may look like:
* getting started
* installation
* References
* simple programs
* using the multitasker
* modify the serial drivers
* creating drivers
* writing in assembler
* setting up the automation
* running the build automation
* running the test automation
* custom kernels
* custom test automation
So the documation would start with the online version of what currently PropForth.htm; the sections would have links to the above main topics. Someone knowledgeable/interested in a given topic (possibly Loopy for serial drivers, caskaz for writing in assembler, for example) could contribute to or even own a given page.
From this, we could evolve a common method and possible style for capturing users' learning.
Sal is considering creating a separate wiki / google code site for propforth 6. A big re-org would break things that are in place for PF5.5; we don't yet know if the reorg wil be effective. So we will probably try to keep these effort separate until we are sure the new metthod works.
Also PF6 is different from PF5.5:
PF5.5 has a specific development sequence to achive specific goals. Sal wanted to try or add or change specific things at each release, and these have been completed.
Wtih PropForth 6, there appears to be no further kernel development needed, all development looks like it will be extensions and applications. PF6 kerrnel has actually been stable for over a year, there have been no isues requiring modification. The multitasker works great, optimizing routines in assembler works better than expected. The kerenl does everything Sal needs it to do, and the environment presents a tool box of sufficient functions to create custom kernels and applications. The only thing left to do appears to be the user documetation; this is probably a biger project than the entire development that has been completed. Sal did most of thework on kernel development, he knew exactly what he wanted. He does not know very much about what we, the user community, want in the way of documentation. Therefore, it is up to us to drive the docs (with our questions), and write them (capute what we learn and how it makes sense to us) and own the pages we write. Wish us luck and participate in any way the suits you!
When did it start, who is Sal, how did you come to be the "PropForth Ambassador", etc.
I'm exploring Forth, currently going through "Starting Forth" using SwiftForth on the PC. I hope to start playing around with the various Forth's using a QuickStart board in the near future.
PropForth has always had this air of mystery around it, and I'd like to know a little more about it.
When did it start, who is Sal, how did you come to be the "PropForth Ambassador", etc.
I'm exploring Forth, currently going through "Starting Forth" using SwiftForth on the PC. I hope to start playing around with the various Forth's using a QuickStart board in the near future.
PropForth has always had this air of mystery around it, and I'd like to know a little more about it.
Thanks,
Chris Wardell
I can chip in too, here's a link to where Sal released his "SpinForth" back in 2007, before it became PropForth. What memories, and when Sal still communicated directly with us mortals, rather than through his Prof'et
(was that a dig at Doug? no, I dig Doug)
I used to use Forth, Inc PolyForth, it was the coolest thing I ever saw, but the $1700 per liscence was too expensive, and seems to go against Moore's original intent of a community developed tool. I was looking for forth on the prop, and found Cliffe Biffle's Propeller Forth. It was cool but no source, no way to fix bug or make changes, and I'm not advanced enough to do it on my own (I'm a process/requirements/test trace guy, not a coder anymore). Looking for alternatives, found SPINFORTH, which tried to use the prop's built in interpreter. But this was too slow and used up too many resources. I found the same author had a another attempt, propforth, written in SPIN but implementing the interpreter in assembler. I contacted the author with questions and bugs. I expected to be ignored, as with Cliffe, but to my surprise, the guy answered. This turned out to be Sal. To my greater surprise, Sal understood the value of requirements, testing, traceability, and "another set of eyes". I told Sal I wanted to teach kids about embedded systems using forth.
Sal that "that sounds interesting. Tell me what you want me to do and I'll see what I can do." Just like that.
We agreed right off that the tool was always Sal's too first, and any suggestions from me would be just suggestions. But he's found a number of my suggestions useful, and often tries them even when he KNOWS the results won't pan out, because he knows somethimes he's wrong. One result was the test automation, which was set up so I could reproduce his results, even though Sal could run the tests on his own in less than a week. Now the automation gets ALL testing done in an hour, whereas it used to take weeks doing it manually (due to re-test events). Another example is common interfaces. I would get confused how each interface works, so Sal made a everything use a common interface. Now everything just "plugs in" by pointers, which allow an easy interface to Go-channels, as these are both similar to CSP channels. He says he wouldn't have bothered had he been left alone, but now that they are implemented they are invaluable much more powerful and useful than he anticipated.
Sal does not argue, and does not usually care to talk to folks that do not have a minimum understanding sufficient to ask a reasonable question on the subject at hand. That's about half the conversations concerning forth. He's not arogant or anything, he just doesn't have time to go back to first prinicples for every discussion on the forums. He does in fact start at first principles on every investigation that I have seen him work, this is probably why he his work is mostly flawless. It just talkes a lot of time.
So he lets me filter the questions and interface to the public at large; and he concentrates on the work. If I bring in questions, he considers them and answers them, and adjusts as needed. He even considers "stoopid" stuff; he's says its not stupid to the person that asked it and a significant number of times yields important results he would not have otherwise considered.
I just write stuff down, and get to play with the results.
For our common goals, Sal had a development road map, which he recently completed after 5 or so years. Recently he had gig that needed more than 8 tasks, so he did the multitasker in PF6, and implemented it so it should run as-is on P1 and P2 when available. The P1 runs 30 real tasks easily (around 120 was the most that would pas a single byte from one to the next). The P2 should be able to do more based on memory resources.
Comments
You did saveforth, so onreset2 is in the dictionary.
Every time you reboot, it comes back.
If you do forget, then saveforth, it will be gone forever.
Word'forget' cannot be 'forget' [: onreset2 onreset test ;] from dictionary.
This is PropForth's specification?
Why 'it cannot do 'forget' word'onreset2'?
I'm mistake.
I have misunderstood word'forget' also re-write eeprom.
I get tricked like this all the time. Words seems like the SHOULD do a bunch of "extra" stuff, but their power is that they do the simplest thing to get the job done.
In summary:
FORGET only moves HERE back to the address of the definition being forgotten.
SAVEFORTH writes the current contents of ram into eeprom.
I made USB_Current_monitor document.
There is bug in USB_Current_monitor_0.3.1.f yet.
I will upload to fix.
That's pretty cool!
My suggestion is minor- consider putting a separate parts list
just before the I/F circuit section.
Nice work!
I'll start a new thread for Propforth 6.
Propforth 5.5 will remain the current release for another 6 months while PF6 is being prepared, which looks to be another six months.
http://forums.parallax.com/showthread.php/152568-PropForth-6-development
I have been writing i2c_device's code.
DS3231,DS1337,HM5883,DRV8830,DS1631,L3GD20,ColorSensor
Now I write ADT7410(Temp sensor).
Register0x0(Temperature) can read but other cannot.
It seems to not change register-address.
Why register don't change?
I check codes many times, but I cannot find out where is wrong.
Please teach me if tou have hint.
we are looking at demo options.
The current logger has realtime clock implemented, the only issue is setting the clock accurately and automatically.
We are looking at radio time synchronization. Of course, it might be easier and cheaper to set the ttime manually, and use a realtime chip such as DS1302. Our options so far are some combination of:
DS1302
WWV
GPS
Each of these might be handy in certain situations. Sal's criterion is that we need to determine what people would actually want to DO. The software to automatically adjust the clock in referece to a known source already exists (in the DS1302 and IP drivers). Adding an interface to a WWV or GPS would remove the manual time setting step, which might be useful in for example solar powered remote applicattions. I'm thinking a solar powered app could occasionally lose power if it were cloudy for too long. So the investigation is to determine a radio reciever that can be had for a reasonable (under $20?) cost.
The remainder of the discussion was PF6.0 development.
I wrote i2c_detect displaying slave-address.
lockdict create _eewrite forthentry $C_a_lxasm w, h15F h141 1- tuck - h9 lshift or here W@ alignl h10 lshift or l, z1SV058 l, zW0000 l, zG0000 l, zG l, z2WiQD4 l, z3[yQD6 l, z1SV000 l, z2WyPj8 l, z1YVPQ0 l, z1vix\2 l, z1bix\3 l, z1Sybw5 l, z1Sybw5 l, z1[ix\3 l, zfyPO1 l, z1Sybw5 l, z1Sybw5 l, z3[yPo9 l, z1[ixo2 l, z1bix\3 l, z1Sybw5 l, z1Sybw5 l, z1YFbNl l, z1viPR6 l, z1[ix\3 l, z1Sybw5 l, z1Sybw5 l, z1[ix\2 l, z1bixo2 l, z1SV01X l, freedict \ Print out connected i2c-devices slave-address \ ( -- ) : i2c_detect hex \ Print lower ." 0 1 2 3 4 5 6 7 8 9 A B C D E F" cr 0 8 0 do \ Print 1-line dup .byte h3A emit space d16 0 do \ Start I2C _eestart \ Write slave address[wr], then receive Acknowledge-bit(ACK:Lo NACK:Hi) dup i + 1 lshift _eewrite 0= if dup i + .byte else ." --" then space \ Stop I2C _eestop loop cr \ next line d16 + loop drop decimal ;Result below;
Prop0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: 00 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Prop0 Cog6 okEeprom on QuickStartboard is h50.ADT7410 is h48.
ADT7410 also respond to h00(GeneralCallAddress).
Original _eewrite cannot use on i2c_detect because it has bug.
It get acknowledgement before SCL rise up.
Prop0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20: 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30: 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40: 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50: 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60: 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70: 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F Prop0 Cog6 okI upload modified _eewrite's assembler list later.
OLED-LCD(SSD1306) has no problem by using this _eewrite.
If there is problem on other i2c-device, I will modify this.
lockdict create _eewrite forthentry $C_a_lxasm w, h131 h113 1- tuck - h9 lshift or here W@ alignl h10 lshift or l, z2WyPj8 l, z1YVPQ0 l, z1vix[h l, z1Sy\fe l, z1bix[i l, z1Sy\fe l, z1Sy\fe l, z1[ix[i l, zfyPO1 l, z1Sy\fe l, z3[yPnK l, z1[ixnh l, z1Sy\fe l, z1bix[i l, z1Sy\fe l, z1YF\ql l, z1viPR6 l, z1Sy\fe l, z1[ix[i l, z1Sy\fe l, z1Sy\fe l, z1[ix[h l, z1bixnh l, z1SV01X l, z2WiQCj l, z3[yQCf l, z1SV000 l, zW0000 l, zG0000 l, zB l, freedict \ Print out connected i2c-devices slave-address \ ( -- ) : i2c_detect hex \ Print lower ." 0 1 2 3 4 5 6 7 8 9 A B C D E F" cr 0 8 0 do \ Print 1-line dup .byte h3A emit space d16 0 do \ Start I2C _eestart \ Write slave address[wr], then receive Acknowledge-bit(ACK:Lo NACK:Hi) dup i + 1 lshift _eewrite 0= if dup i + .byte else ." --" then space \ Stop I2C _eestop loop cr \ next line d16 + loop drop decimal ; { \ Modified _eewrite ( c1 -- t/f ) write c1 to the eeprom, true if there was an error \ Received acknowledge from i2c-device during scl is high build_BootOpt :rasm mov $C_treg3 , # h8 \ Set data-bit to sda __x0B test $C_stTOS , # h80 wz muxnz outa , __x02sda jmpret __x0Fdelayret , # __x0Edelay/2 \ Set scl to Hi or outa , __x03scl jmpret __x0Fdelayret , # __x0Edelay/2 jmpret __x0Fdelayret , # __x0Edelay/2 \ Set scl to lo andn outa , __x03scl \ Shift data-bit shl $C_stTOS , # 1 jmpret __x0Fdelayret , # __x0Edelay/2 \ Finish 8bit? djnz $C_treg3 , # __x0B \ Set sda to input(floating) andn dira , __x02sda jmpret __x0Fdelayret , # __x0Edelay/2 \ Set scl to Hi or outa , __x03scl jmpret __x0Fdelayret , # __x0Edelay/2 \ Input sda from slave Read ACK test __x02sda , ina wz muxnz $C_stTOS , $C_fLongMask jmpret __x0Fdelayret , # __x0Edelay/2 \ Set scl to lo andn outa , __x03scl jmpret __x0Fdelayret , # __x0Edelay/2 jmpret __x0Fdelayret , # __x0Edelay/2 \ Set sda to lo and output andn outa , __x02sda or dira , __x02sda jexit \ this delay makes for a 384kHZ clock on an 80 Mhz prop Xtal:5MHz __x0Edelay/2 mov $C_treg6 , __x04delay/2 __x0D djnz $C_treg6 , # __x0D __x0Fdelayret ret __x02sda h20000000 __x03scl h10000000 __x04delay/2 hB ;asm _eewrite }BTW,today is her birthday.
She is 10 years old.
Happy Birthday, pup! She grew up to be a beauty! I'm glad I'm not the only one that gets birthday cakes for my dogs!
Reading for ADT7410 is ok.
ADT7410 need clock-stretch at repeated-start.
I re-write _eewrite,_eestart,Sr,_eestop ATE7410's register is below;
Sorry, needing Clock-stretch is wrong.
Original i2c-word(_eestart, _eewrite, _eestop) use output-port at going to hi for scl.
It seems to disturb writing register-value about ADT7410.
Maybe I think _eeread also need to re-write.
Only 9 devices.
DS1337,DS3231 and DRV8830 are NOT re-written.
We've been debugging the PF6 build automation. One of the issues was caused by poor power being supplied by the PC USB to the quickstart, the same issue ocures with a wonky wall-wart on the protoboard.
Sal was able to overcome the issue by placing a capacitor between Vin and ground on the quickstart. But he does NOT recommend this, the capacitor could cause damage the PC at power up or power down; the solution is to get a good power supply, and or ensure the laptop can deliver clean reliable power to the quick start. In any case, this is why Sal always starts a project by building a power supply correctly sized for the task at hand. In my case, I don;t know about building power supplies. Maybe a powered USB hub will be the general solution.
The remainder of the discussion was PF6
I tried to read/write RH6010's register by new i2c-WORDS.
I could read/write register0(Config1) and register1(Config2).
Refering #340 in this thread.
Not yet read correctly Touch-Sense data(register2).
Data for register2 is always 0.
Pulses for scl/sda is normal. ( I checked them by oscilloscope)
When resetting on connecting RH6010 to scl/sda for propeller, Forth can not reboot.
It seems Propeller can not read eeprom.
When removing scl-line of RH6010, Forth can reboot.
Accessing(boot-code inside propeller) to i2c-devices from propeller is not perfect?
Or RH6010 is out of i2c-spec?
http://youtu.be/x6_4kwdeypo
Mode:
Current, USB-Voltage, Total-Current, Time
When current is 0, mode display only Current and USB-Voltage
Current is max 2000mA.
Time display passing time and total-current.
Time is max99Hour59Min59Sec.
This use voltage(200mV) from signal-supply for test.
http://youtu.be/zROAR94AF4A
This code operate well, but not final.
Using parts;
Propeller QFP chip
OLED-LCD SSD1306(i2c device)
24LC256
MCP3204(ADC)
NJM2732(OpeAMP)
NJM2863(3.3V Regurator output:max100mA)
Xtal 5MHz
chip kondensors and chip resistors
The turmoil at the Braino Lab (emptying out the house for major remodeling during record snow and cold, because it waiting until Spring would be just silly) has finally wound down. Hopefully we can return to our regular pattern.
Sal looked at Issue 215, "serial parameter n3 is baud divided by 4". Sal finds that Art's way of stating it is much clearer, and will update the docs next release.
Which bring up the larger issue of documentation strategy. PropForth.htm will move from being included in the download archive to the wiki. Every successful online project has online documentation, and if we need an offline copy, we can grab ourselves.
We are looking into organizing the wiki documentations into sections, and having users add and maintain the content. An example of the documentation organization may look like:
* getting started
* installation
* References
* simple programs
* using the multitasker
* modify the serial drivers
* creating drivers
* writing in assembler
* setting up the automation
* running the build automation
* running the test automation
* custom kernels
* custom test automation
So the documation would start with the online version of what currently PropForth.htm; the sections would have links to the above main topics. Someone knowledgeable/interested in a given topic (possibly Loopy for serial drivers, caskaz for writing in assembler, for example) could contribute to or even own a given page.
From this, we could evolve a common method and possible style for capturing users' learning.
Sal is considering creating a separate wiki / google code site for propforth 6. A big re-org would break things that are in place for PF5.5; we don't yet know if the reorg wil be effective. So we will probably try to keep these effort separate until we are sure the new metthod works.
Also PF6 is different from PF5.5:
PF5.5 has a specific development sequence to achive specific goals. Sal wanted to try or add or change specific things at each release, and these have been completed.
Wtih PropForth 6, there appears to be no further kernel development needed, all development looks like it will be extensions and applications. PF6 kerrnel has actually been stable for over a year, there have been no isues requiring modification. The multitasker works great, optimizing routines in assembler works better than expected. The kerenl does everything Sal needs it to do, and the environment presents a tool box of sufficient functions to create custom kernels and applications. The only thing left to do appears to be the user documetation; this is probably a biger project than the entire development that has been completed. Sal did most of thework on kernel development, he knew exactly what he wanted. He does not know very much about what we, the user community, want in the way of documentation. Therefore, it is up to us to drive the docs (with our questions), and write them (capute what we learn and how it makes sense to us) and own the pages we write. Wish us luck and participate in any way the suits you!
Can you post a quick little history of PropForth?
When did it start, who is Sal, how did you come to be the "PropForth Ambassador", etc.
I'm exploring Forth, currently going through "Starting Forth" using SwiftForth on the PC. I hope to start playing around with the various Forth's using a QuickStart board in the near future.
PropForth has always had this air of mystery around it, and I'd like to know a little more about it.
Thanks,
Chris Wardell
I can chip in too, here's a link to where Sal released his "SpinForth" back in 2007, before it became PropForth. What memories, and when Sal still communicated directly with us mortals, rather than through his Prof'et
(was that a dig at Doug? no, I dig Doug)
Chris Wardell
I used to use Forth, Inc PolyForth, it was the coolest thing I ever saw, but the $1700 per liscence was too expensive, and seems to go against Moore's original intent of a community developed tool. I was looking for forth on the prop, and found Cliffe Biffle's Propeller Forth. It was cool but no source, no way to fix bug or make changes, and I'm not advanced enough to do it on my own (I'm a process/requirements/test trace guy, not a coder anymore). Looking for alternatives, found SPINFORTH, which tried to use the prop's built in interpreter. But this was too slow and used up too many resources. I found the same author had a another attempt, propforth, written in SPIN but implementing the interpreter in assembler. I contacted the author with questions and bugs. I expected to be ignored, as with Cliffe, but to my surprise, the guy answered. This turned out to be Sal. To my greater surprise, Sal understood the value of requirements, testing, traceability, and "another set of eyes". I told Sal I wanted to teach kids about embedded systems using forth.
Sal that "that sounds interesting. Tell me what you want me to do and I'll see what I can do." Just like that.
We agreed right off that the tool was always Sal's too first, and any suggestions from me would be just suggestions. But he's found a number of my suggestions useful, and often tries them even when he KNOWS the results won't pan out, because he knows somethimes he's wrong. One result was the test automation, which was set up so I could reproduce his results, even though Sal could run the tests on his own in less than a week. Now the automation gets ALL testing done in an hour, whereas it used to take weeks doing it manually (due to re-test events). Another example is common interfaces. I would get confused how each interface works, so Sal made a everything use a common interface. Now everything just "plugs in" by pointers, which allow an easy interface to Go-channels, as these are both similar to CSP channels. He says he wouldn't have bothered had he been left alone, but now that they are implemented they are invaluable much more powerful and useful than he anticipated.
Sal does not argue, and does not usually care to talk to folks that do not have a minimum understanding sufficient to ask a reasonable question on the subject at hand. That's about half the conversations concerning forth. He's not arogant or anything, he just doesn't have time to go back to first prinicples for every discussion on the forums. He does in fact start at first principles on every investigation that I have seen him work, this is probably why he his work is mostly flawless. It just talkes a lot of time.
So he lets me filter the questions and interface to the public at large; and he concentrates on the work. If I bring in questions, he considers them and answers them, and adjusts as needed. He even considers "stoopid" stuff; he's says its not stupid to the person that asked it and a significant number of times yields important results he would not have otherwise considered.
I just write stuff down, and get to play with the results.
For our common goals, Sal had a development road map, which he recently completed after 5 or so years. Recently he had gig that needed more than 8 tasks, so he did the multitasker in PF6, and implemented it so it should run as-is on P1 and P2 when available. The P1 runs 30 real tasks easily (around 120 was the most that would pas a single byte from one to the next). The P2 should be able to do more based on memory resources.
I'd write more but it would be very boring.
No I won't have that Charlie's Angels-esque image in my head when you mention your conference call with Sal...
I'm really looking forward to digging into PropForth and the other Forths that have been created for the prop.
Chris Wardell
I sure hope your image had the Prof as Bosley,
because, well, it's too close to lunch to consider any other possibilities!
... and of course, you meant the REAL Charlie's Angels, right??
There were others?
C.W.
Talked about DLink DI505 project. See other thread.
http://forums.parallax.com/showthread.php/154181-DLINK-DIR505-router-for-WiFi-connection-to-Prop