I have only encountered one SD card that would not work, it was from a local consumer electronics shop (similar to BIC Camera or Yodobashi Camera) and was for 90% off the price of 4g card at the time. It is store - labeled SDHC, but nothing has gotten and response from it. It cannot be read by any PC or camera.
Could you try making a new SD slot from a microSD adapter so you can use a microSD card for one test? It is not very expensive except for time. I keep thinking that it must be a hardware issue, like a cold solder joint or something. Not that I doubt your skills, but the hardware build is usually the cause when I have this kind of problem myself.
I keep thinking that it must be a hardware issue, like a cold solder joint or something. Not that I doubt your skills, but the hardware build is usually the cause when I have this kind of problem myself.
Hi prof_braino.
I don't think there is hardware issue.
I made sd_loader on this SD-I/F-Board.
sd_loader works fine now.
And sd_init of sd_driver also work fine. I watch another function.
For example, sd_driver's blockread is different to my sd_loader's way.
Sal's code is difficult. I can't understand it yet.
I continue to read it.
The sd_unit code appears to work. It frees up the COG memory. This is goodness!!
I've been playing with the IPServer and using Telnet to get in an play on the Spinneret. I really like this setup. I was seeing some error (172 errors from SD) after reboot/reset but I'm not sure if this is power issues or something else. No cause for alarm or an official trouble report yet.
This is my iPad running a Telnet session into the Spinner running PropForth......how cool!!
The testing and the FUN continues. Tonight, my 9 year old daughter started learning about pinout, pinhi, pinlo and delms so she can write blinking words! It's Forth for the family!!
Thanks for the sd_uninit solution. I'll keep banging away at it with my released variables.
I re-make 2-wire_LCD for PF4.5.
And I changed curcuit.
I added level-shift(3.3V -> 5V) because LCD's D0-D7 and RS is pulled up to 5V inside LCD-controller(HD44780).
Default is 16-Character4-Line LCD.
If another LCD, use lcd-setup.
Incase of 16-Character2-Line LCD
Inside lcd_demo1/lcd_demo2, add "10 2 lcd_setup".
My post number "300"!! Wonderful!!
It had passed 1-year since I had found out PropForth. That' was PropForth2.7.
The sd_unit code appears to work. It frees up the COG memory. This is goodness!!
...Telnet...blinking words!
Thanks for testing. This word should make it into the v5.0 non-kerenl extensions package, let me know of any other needs you run across.
Please find the ANSI support for Telnet in the downloads page, I don't think ANSI.f has made it into the download archive yet. This might be a source of fun to play with.
Glad your daughter likes it. Any inputs on improving your/her experience would be greatly appreciated (My 9 year old daughter is my primary audience, but she has not expressed approval yet).
I have never used forth before. Can you give a brief description of its advantages and some cases where things where easier to achieve with forth over spin?
Or is forth just a special kind of language and forth-people like to have their favorite language on every device the work with?
Prof_Braino & Caskaz: Thanks for your explanation of how to generate assembler code.
I have abstracted from the sd-driver a general purpose spi word set (PF_SPI attachment). While timing depends somewhat on the nature of the spi device, I have the following limited results for the uM-FPU chip in microseconds.
Can you give a brief description of its advantages and some cases where things where easier to achieve with forth over spin?
Or is forth just a special kind of language and forth-people like to have their favorite language on every device the work with?
Hi Stefan
Forth is really fun to use on microcontrollers. This is its main advantage in general. The specific points are 1) interactive 2) very small 3) almost as fast as assembler
The interactive development cycle in forth allows developers to achive many more design-code-test cycles per period of time than non-interactive PC-hosted development environments. This promotes many more small test cycles, as opposed to writing the whole application and try to debug everything at once.
Forth is specifically designed to work on tiny micro controllers, and is pretty much the same on any microcontroller, except for the actual hardware differences.
Spin is specifically designed to wok on the prop, and is done very well. Those guys are very clever. Use Spin on the prop is first recommendation.
If you like C, Spin looks similar, so this it i s easier than learning a stack based language.
If one knows Spin and does not know Forth, there is no advantage to Forth. If one knows Forth and does not know Spin, knowledge and code from other projects directly applies to the prop.
To me, Forth is very well suited to real time, embedded systems, on micro controllers and up. To me, C is very well suited to writing operating systems for PC work stations. Since the Prop is a micro controller, I choose forth as my tool. I could use Spin, but I don't need to. You could use Spin, and I could still interface to your application; interfaces are language and machine independent. The tool does not matter, its how it is used that counts.
Some people are picky about "the right tool for the right job". I would not use a screw driver to stir paint, and I would not use a microwave to make toast (OK, I did once but that's a different story ). I would use Forth on a micro controller, or a PC that weeps when it runs windows. I would use C if I were to write linux extensions on the PC; but I don't need to, somebody smarter is already doing that.
-edit- I can't speak for any Forth person but my self, but as far as I am concerned, -edit -
Forth people like to like to have their favorite language on every device the work with, if they work with micro controllers or environments with limited resources, and constraints on time. Not only is it fun, often it is the only way to make the application work at all in the allotted time with the available resources.
I have abstracted from the sd-driver a general purpose spi word set (PF_SPI attachment).
WOW! This is very cool. Thanks a bunch.
Please note, Sal is re-doing the assembler material for the summer release. It will be easier to use the assembler, but rebuilding the kernel will have another step. This doesn't affect anything at the moment since we don't have all the details, just be aware.
Do you have a C3? That part is very nice and has 5 SPI devices, I believe. I'm saving C3 for end of summer when the VGA material is brought forward from 3.6 to 5.0.
I re-make 2-wire_LCD for PF4.5.
My post number "300"!! Wonderful!! It had passed 1-year since I had found out PropForth. That' was PropForth2.7.
Way to go! Thanks for tolerating the changes. Hopefully, V5.0 kernel will be the final version.
I found a HD44780 16x2 display, an OPTREX DMC16230. Should I build the 2-wire interface board exactly as you did, or would you make changes?
So far I think the parts list is:
TC4040
TD62083
(3) RN1210
47uH
(2) 10K
10K variable
100uF
.01uF
47uF Tantalum
22uF Tantalum
1N5817
HT7750A
RN1210 is easy to get for me. How do you?
If not RN1210, You can use NPN-Tr and base-resister.
I use VR on contrast-adjustement.
If you want to control contrast from propforth, use PWM(other cog).
NCO same as brightness is not used on contrast-adjustment.
So when you use only VR on contrast, you don't need to build contrast's curcuit(RN1210 10k 100uF).
I recommend you test operation by connecting TC4040(counter IC) and TD62083 on breadboard at first.
Please build I/F board after you test LCD's demo.
If you find out code-bug and curcuit-bug, teach me.
RN1210 is easy to get for me. How do you? If not RN1210, You can use NPN-Tr and base-resister.
I use VR on contrast-adjustement. If you want to control contrast from propforth, use PWM(other cog).
NCO same as brightness is not used on contrast-adjustment.
So when you use only VR on contrast, you don't need to build contrast's curcuit(RN1210 10k 100uF).
I recommend you test operation by connecting TC4040(counter IC) and TD62083 on breadboard at first.
Please build I/F board after you test LCD's demo. If you find out code-bug and curcuit-bug, teach me.
By the way,PF5.0 is final?
PF 5.0 is NOT final
Sal will not begin his internal regression test for at least another month. He DOES find things, and adds new tests as each new function is complete, a rearranges the documentation.
We have a review conference call where he tells me of changes, and I write up documentation as needed and time permitting.
Then I run through it a couple times to find any points of confusion. If I get stuck, I send it to you guys when I need help. These tare the alpha and beta I send you.
After Sal's developer test, and at least one review discussion on conference call, and several passes of my regression test, we decide that nothing has changed between the current Beta and the previous Beta. When two consecutive Betas are identical, we update the time stamp and name it Release Candidate. This is what I post on the google code site.
As of today, Sal pretty much knows exactly what he wants to and how to do it, he just hasn't written it down in the form of source code yet. He is usually accurate to within three days of his estimated completion time. The delays come from my testing issues.
LCD:
Did not check the availability of parts yet, but I may try the NPN-Tr & base resistor alternative; what value is base resistor?
Will try controlling contrast from Prop AFTER I duplicate your circuit, as I am not good at hardware.
May skip the contrast circuit and use variable resistor depending on parts in my drawer.
Will build on breadboard first
SD:
Ran Transcend 2Gig microSD to be most similar to your equipment.
Collecting logs, will post on completion.
Fresh card (Transcend 2Gig microSD) that was Windows identified as NOT formatted gave a -1 debug error and would not initialize with sd_scripts
After Formatting with FAT32, the card read correctly. This could be the bug?
Anyway, the debug made it run a LONG time and I forgot my place.
I used a transecnd 2Gig microSD to match your equipment
The uSD was NOT recognized as formatted by windows.
Propforth gave Error 166.
Captured logs of loading propforthkernel.spin; uncommenting the debug constants in sd_driver.f and sdfs.f, loading them; running saveforth, and reboot.
At some point, I moved the teraterm window, and spoiled the fl (fast load) text stream.
The definition of _sd_CrEaTe was NOT in the dictionary. I noticed this a couple times in regression testing.
I reloaded propforthkernel.spin; WITHOUT uncommenting the debug constants in sd_driver.f and sdfs.f, loaded them; ran saveforth, and rebooted.
ran sd_scripts.f
worked as required.
1) first issue may be due to completely uninitialized card does not respond as expected?
2) second issue may due to interference with teraterm in clipboard copy operation?
RN1210's internal base-resistor is 4.7k-ohm.
I thought sd_driver was strange from 172 UNKNOWN ERROR. But this idea is wrong? Any idea?
Thanks for the 4.7kOhm, I will try that.
The long time-out is is similar to the error I saw from my misformatted card as in log post #47.
Possibly try reformatting the card and running the SD test again, that's what I did and it worked the second time.
@prof_braino: I've been intrigued by FORTH forever. Unfortunately the intrigue never translated into much action, except to learn that FIG FORTH for the 6502 still costs money! Meanwhile, versions written to run on a PC violate my sense of rightness and also lead to many unpleasant crashes of an overly complex and expensive system.
Seems like the Prop would be a great place to start. I only know enough SPIN to make PASM work, anyway. But I wonder if FORTH on the Prop is a suitable substitute for PASM for implementing things like SPI and I2C?
(BTW, it was an IBM researcher who was working on three-dimension data storage in crystals that fired up my interest in FORTH. He swore by the language. Nothing else in his experience allowed him to develop applications in so little time... In this instance we were articulating a platter that held his magic crystals while they were being interrogated by lasers.)
I was seeing similar "172 UNKNOWN ERROR" from various places when I was testing and playing with having sd_driver.f adn sdfs.f on EEPROM and loading and unloading them to free memory when not in use.
The following teraTerm output is from me doing an fsload of my sd_driver.f and sdfs.f from EEPROM - at the end of that script, mountsys and mountusr are defind and the mountsys word is executed. As you can see, all off that happens on Cog0:
.
.
. earlier output from script trimmed to keep it short! :smile:
.
[ifdef _sd_debug
Prop0 Cog1 ok
Prop0 Cog1 ok
Prop0 Cog1 ok
decimal
Prop0 Cog1 ok
Prop0 Cog1 ok
Prop0 Cog1 ok
Prop0 Cog0 ok
decimal
Prop0 Cog0 ok
[ifndef mountsys : mountsys 0000000001 sd_mount ; ]
Prop0 Cog0 ok
[ifndef mountusr : mountusr 65538 sd_mount ; ]
Prop0 Cog0 ok
mountsys
Prop0 Cog0 ok
fread .sdcardinfo
SDCard size: 1,927,160 Kbytes
File System: sys
Start Block: 1End Block: 65,538
File System Size (blocks): 65,537
File System Size (bytes): 32,760 Kbytes
File System: usr
Start Block: 65,538End Block: 3,854,336
File System Size (blocks): 3,788,798
File System Size (bytes): 1,894,390 Kbytes
Prop0 Cog0 ok
ls
337 .partion-sys/130 .sdcardinfo
136 .autousr.f
133 .autoload.f
Prop0 Cog0 ok
Prop0 Cog6 ok
At this point, the sd-driver.f and sdfs.f words are loaded and mountsys and mountusr have been created, also, mountsys has run on Cog0. As you can see below, if you do 'ls' from the Cog6 prompt, you get the 172 error. You need to do 'mountsys' on Cog6 so it can access the SD card.
Prop0 Cog6 ok
lsCON:Prop0 Cog6 RESET - last status: 172 UNKNOWN ERROR
Prop0 Cog6 RESET - last status: 172 UNKNOWN ERROR
Prop0 Cog6 ok
mountsysProp0 Cog6 ok
ls337 .partion-sys/
130 .sdcardinfo
136 .autousr.f
133 .autoload.f
Prop0 Cog6 ok
I kept running into problems like this when I was testing the HTTP and IPSERVICES features. Often, one COG would load the SD system and have done a mountsys but another COG was trying to load the IP words and not be able to see the SD. Having the mount apply to a COG takes some planning and getting used to.
Meanwhile, versions written to run on a PC violate my sense of rightness and also lead to many unpleasant crashes of an overly complex and expensive system.
I would send you a 386, except the shipping costs are more than I can handle. (Digging it out of the basement is more than I can handle at the monent). My forth pc is a Pentium 2; Forth runs crazy fast but it takes 3 minutes to boot to windows 98 before I can open the DOS window.. I am too lazy to make a native forth disk. Dig out that old PC that Aunt MArtha refused to take, and use that. It will be fine. Easier still it to find a discarded Laptop incapable of surfing the net, it will also be fine.
I recommend Frank Sargent's Pygmy Forth for use on the PC. It is brilliant and simple.
Seems like the Prop would be a great place to start. I only know enough SPIN to make PASM work, anyway. But I wonder if FORTH on the Prop is a suitable substitute for PASM for implementing things like SPI and I2C?
Probably not, if you ask many folks on these forums, but thats what we the forth team are doing. If your goal is to have more fun without bleaching you hair, forth is a good option. Sal Sanci made SPI for the EEPROM and Nick Lordi made a general SPI wordset, so clearly it can be done by loosely coupled widely dispersed team. Nobody has needed I2C yet so I nominate YOU to start. The PASM stuff (or more specifically prop assembler in the forth environment) is just the series of byte codes loaded into cog memory. The assembler, disassembler, and debugger etc are going to be optimized next release, if you start playing now you will be ready to jump in and kick butt by August release of v5.
(BTW, it was an IBM researcher who was working on three-dimension data storage in crystals that fired up my interest in FORTH. He swore by the language. Nothing else in his experience allowed him to develop applications in so little time... In this instance we were articulating a platter that held his magic crystals while they were being interrogated by lasers.)
This has been my experience too, except for the IBM, crystals, lasers and three dimensional storage part. But be aware that for every "success" story there are many not-success stories, so forth is not for everyone and is not a magic silver bullet as many disappointed managers wished. Folks that actually know something about what going on have the most success, "yours truely" being the exception that proves the rule.
Post here or PM me and we will get you up and running.
"172 UNKNOWN ERROR" ... mountsys and mountusr
Often, one COG would load the SD system and have done a mountsys but another COG was trying to load the IP words and not be able to see the SD. Having the mount apply to a COG takes some planning and getting used to.
Sorry, this is not so clear.
There is only one access to the SD, only one file is open at a time.
Each cog must mount the partition (mountsys for system or mountusr for user).
The last file opened is the current file for all subsequent accesses until the next command that sets the file.
If one or more cogs are to access multiple files at the same time the user is responsible for structuring the words so that the mount-open-read-write sequence is correct.
This has been done by design to ensure that the absolute minimum overhead is involved, unless explicitly implemented by the user.
Currently SD access is subjectively observed to be very fast, by no benchmarks or statistics have been collected.
The "echo characters to screen" operation may be a bottleneck, eliminating this or other bottlenecks has not been explored yet.
Nothing to be sorry about. I was trying to figure this SD stuff out and also run my Spinner off a rapidly depleting battery.....let's just say things got confusing until I realized the battery was an issue. Once I got my house in order (and maybe back to following the instructions ) I was up and running with IPservices and then HTTP. I'm still curious and still having fun, so all is good with my PropForth adventure!!
I was hoping my 172 error experiences might be something cakaz could benefit from.
Sorry, I have misunderstanding everythibg about test-2.1.1 SD txt.
1 I used no-formatting SD-cards.
I thought I don't need to format because SD-cards can read/write on PC.
2 After loading sd_driver.f & sdfs.f , I did power-reset not reboot.
3 I was wrong how to test for sd_driver.f.
Again, I start to retry loading PropForthKernel.spin to eeprom.
I did procedure"test-2.1.1 SD.txt" again.
Used Kingston2GB(SDSC) formatted on PC.
All Messages are same as procedure"test-2.1.1 SD.txt".
After power-reset, message is ok.
But after I insert another SD-catd, error occured.
I re-insert SD-card(Kingston2G). But error remained.
CON:Prop0 Cog0 RESET - last status: 0 ok
CON:Prop0 Cog1 RESET - last status: 0 ok
CON:Prop0 Cog2 RESET - last status: 0 ok
CON:Prop0 Cog3 RESET - last status: 0 ok
CON:Prop0 Cog4 RESET - last status: 0 ok
CON:Prop0 PROP REBOOT PropForth v4.52011MAY3117:301CON:Prop0 Cog5 RESET - last status: 0 ok
CON:Prop0 Cog6 RESET - last status: 168 UNKNOWN ERROR
Prop0 Cog6 RESET - last status: 168 UNKNOWN ERROR
Prop0 Cog6 ok
Maybe system is broken. And Kingston2GB need to format again.
So I loaded PropForthKernel.spin again. Re-install everything.
Is there another way to avoid re-install.
After power-reset, message is ok.
But after I insert another SD-catd, error occured. Re-install everything.Is there another way to avoid re-install.
Sorry to be so long to respond.
If it works after instal, it works. If it is saved to SD, it will work again after power cycle.
REMEMBER - Each Cog that accesses the SD Must "mountsys" or "mountusr" Before lt will work. This got me a couple times, please check if this is involved in the issue.
It was fun to see the projects at UPEC yesterday. I held Prospero the Farmer Bot in my hands, and saw Ray's video displays.
I gave a brief presentation on Propforth, demonstrating the load process using caskaz demo on a Quickstart board, and discussing the v4.5 and v5.0 releases. There seems to be some interest, we'll see if new users begin posting. There will likely be more interest when the final kernel version comes out.
Today Sal informed me that the v5 kernel looks like a possible September arrival. The big difference will be the change in the assembler optimization. The old method caused assembler optimizations to consume cog memory; the new method in v5.x should allow the space used for optimization to be reused via "load from SD" and "forget after use".
Sal and Marco (kuroneko) did some test on the MultiChannel Synchronous Serial. I will try to get the findings form issue 27 and post a summary. The result is bug fixes to LogicAnalyzer.f and MCS.f, we will determine how to release the changes shortly.
caskaz's SD issue appear to involve SD v1 cards and/or MMC cards. We are trying to find a spec for these to ensure that we are compliant, but it appears the there may not have been much to go on for early implementations. The question becomes "how much effort to we want to put into rare early device support when a new one costs $8?"
We hope to resolve these issues and post a new release candidate (RC1) when complete.
Prof Braino, I was great to meet you. Thanks for the presentation, it has me thinking about Fourth. I'm still not completely sure what it is, but I'm more inclined to check it out now.
If it works after instal, it works. If it is saved to SD, it will work again after power cycle.
REMEMBER - Each Cog that accesses the SD Must "mountsys" or "mountusr" Before lt will work. This got me a couple times, please check if this is involved in the issue.
Hi prof_braino.
Thanks!
I tried again. It works fine after power cycle.
Comments
Hi prof_braino.
I don't think there is hardware issue.
I made sd_loader on this SD-I/F-Board.
sd_loader works fine now.
And sd_init of sd_driver also work fine. I watch another function.
For example, sd_driver's blockread is different to my sd_loader's way.
Sal's code is difficult. I can't understand it yet.
I continue to read it.
Can you test:
will free up the cog memory
this must be run on every cog which ran sd_init, which is where the memory
gets allocated to the sd driver.
Please show me result(about each commands) of WORD"test" when debug-mode in sd_driver.f.
The sd_unit code appears to work. It frees up the COG memory. This is goodness!!
I've been playing with the IPServer and using Telnet to get in an play on the Spinneret. I really like this setup. I was seeing some error (172 errors from SD) after reboot/reset but I'm not sure if this is power issues or something else. No cause for alarm or an official trouble report yet.
This is my iPad running a Telnet session into the Spinner running PropForth......how cool!!
The testing and the FUN continues. Tonight, my 9 year old daughter started learning about pinout, pinhi, pinlo and delms so she can write blinking words! It's Forth for the family!!
Thanks for the sd_uninit solution. I'll keep banging away at it with my released variables.
Rick
I re-make 2-wire_LCD for PF4.5.
And I changed curcuit.
I added level-shift(3.3V -> 5V) because LCD's D0-D7 and RS is pulled up to 5V inside LCD-controller(HD44780).
Default is 16-Character4-Line LCD.
If another LCD, use lcd-setup.
Incase of 16-Character2-Line LCD
Inside lcd_demo1/lcd_demo2, add "10 2 lcd_setup".
My post number "300"!! Wonderful!!
It had passed 1-year since I had found out PropForth. That' was PropForth2.7.
Thanks for testing. This word should make it into the v5.0 non-kerenl extensions package, let me know of any other needs you run across.
Please find the ANSI support for Telnet in the downloads page, I don't think ANSI.f has made it into the download archive yet. This might be a source of fun to play with.
Glad your daughter likes it.
I have never used forth before. Can you give a brief description of its advantages and some cases where things where easier to achieve with forth over spin?
Or is forth just a special kind of language and forth-people like to have their favorite language on every device the work with?
best regards
Stefan
I have abstracted from the sd-driver a general purpose spi word set (PF_SPI attachment). While timing depends somewhat on the nature of the spi device, I have the following limited results for the uM-FPU chip in microseconds.
shiftout 1 byte - Caskaz: 544 PF4.5 sd-driver: 341 PF4.5 Assembler: 9
shiftin 1 byte PF4.5 sd-driver: 142 PF4.5 Assembler: 3
I will post an updated version of my FPU application using the assembler word set.
NickL
Hi Stefan
Forth is really fun to use on microcontrollers. This is its main advantage in general. The specific points are 1) interactive 2) very small 3) almost as fast as assembler
The interactive development cycle in forth allows developers to achive many more design-code-test cycles per period of time than non-interactive PC-hosted development environments. This promotes many more small test cycles, as opposed to writing the whole application and try to debug everything at once.
Forth is specifically designed to work on tiny micro controllers, and is pretty much the same on any microcontroller, except for the actual hardware differences.
Spin is specifically designed to wok on the prop, and is done very well. Those guys are very clever. Use Spin on the prop is first recommendation.
If you like C, Spin looks similar, so this it i s easier than learning a stack based language.
If one knows Spin and does not know Forth, there is no advantage to Forth. If one knows Forth and does not know Spin, knowledge and code from other projects directly applies to the prop.
To me, Forth is very well suited to real time, embedded systems, on micro controllers and up. To me, C is very well suited to writing operating systems for PC work stations. Since the Prop is a micro controller, I choose forth as my tool. I could use Spin, but I don't need to. You could use Spin, and I could still interface to your application; interfaces are language and machine independent. The tool does not matter, its how it is used that counts.
Some people are picky about "the right tool for the right job". I would not use a screw driver to stir paint, and I would not use a microwave to make toast (OK, I did once but that's a different story
-edit- I can't speak for any Forth person but my self, but as far as I am concerned, -edit -
Forth people like to like to have their favorite language on every device the work with, if they work with micro controllers or environments with limited resources, and constraints on time. Not only is it fun, often it is the only way to make the application work at all in the allotted time with the available resources.
Use forth only if you find it fun.
WOW! This is very cool. Thanks a bunch.
Please note, Sal is re-doing the assembler material for the summer release. It will be easier to use the assembler, but rebuilding the kernel will have another step. This doesn't affect anything at the moment since we don't have all the details, just be aware.
Do you have a C3? That part is very nice and has 5 SPI devices, I believe. I'm saving C3 for end of summer when the VGA material is brought forward from 3.6 to 5.0.
Way to go! Thanks for tolerating the changes. Hopefully, V5.0 kernel will be the final version.
I found a HD44780 16x2 display, an OPTREX DMC16230. Should I build the 2-wire interface board exactly as you did, or would you make changes?
So far I think the parts list is:
TC4040
TD62083
(3) RN1210
47uH
(2) 10K
10K variable
100uF
.01uF
47uF Tantalum
22uF Tantalum
1N5817
HT7750A
RN1210 is easy to get for me. How do you?
If not RN1210, You can use NPN-Tr and base-resister.
I use VR on contrast-adjustement.
If you want to control contrast from propforth, use PWM(other cog).
NCO same as brightness is not used on contrast-adjustment.
So when you use only VR on contrast, you don't need to build contrast's curcuit(RN1210 10k 100uF).
I recommend you test operation by connecting TC4040(counter IC) and TD62083 on breadboard at first.
Please build I/F board after you test LCD's demo.
If you find out code-bug and curcuit-bug, teach me.
By the way,PF5.0 is final?
PF 5.0 is NOT final
Sal will not begin his internal regression test for at least another month. He DOES find things, and adds new tests as each new function is complete, a rearranges the documentation.
We have a review conference call where he tells me of changes, and I write up documentation as needed and time permitting.
Then I run through it a couple times to find any points of confusion. If I get stuck, I send it to you guys when I need help. These tare the alpha and beta I send you.
After Sal's developer test, and at least one review discussion on conference call, and several passes of my regression test, we decide that nothing has changed between the current Beta and the previous Beta. When two consecutive Betas are identical, we update the time stamp and name it Release Candidate. This is what I post on the google code site.
As of today, Sal pretty much knows exactly what he wants to and how to do it, he just hasn't written it down in the form of source code yet. He is usually accurate to within three days of his estimated completion time. The delays come from my testing issues.
LCD:
Did not check the availability of parts yet, but I may try the NPN-Tr & base resistor alternative; what value is base resistor?
Will try controlling contrast from Prop AFTER I duplicate your circuit, as I am not good at hardware.
May skip the contrast circuit and use variable resistor depending on parts in my drawer.
Will build on breadboard first
SD:
Ran Transcend 2Gig microSD to be most similar to your equipment.
Collecting logs, will post on completion.
Fresh card (Transcend 2Gig microSD) that was Windows identified as NOT formatted gave a -1 debug error and would not initialize with sd_scripts
After Formatting with FAT32, the card read correctly. This could be the bug?
Anyway, the debug made it run a LONG time and I forgot my place.
I used a transecnd 2Gig microSD to match your equipment
The uSD was NOT recognized as formatted by windows.
Propforth gave Error 166.
Captured logs of loading propforthkernel.spin; uncommenting the debug constants in sd_driver.f and sdfs.f, loading them; running saveforth, and reboot.
At some point, I moved the teraterm window, and spoiled the fl (fast load) text stream.
The definition of _sd_CrEaTe was NOT in the dictionary. I noticed this a couple times in regression testing.
I reloaded propforthkernel.spin; WITHOUT uncommenting the debug constants in sd_driver.f and sdfs.f, loaded them; ran saveforth, and rebooted.
ran sd_scripts.f
worked as required.
1) first issue may be due to completely uninitialized card does not respond as expected?
2) second issue may due to interference with teraterm in clipboard copy operation?
attached logs
RN1210's internal base-resistor is 4.7k-ohm.
About sd_driver.f;
I found out my idea was wrong.
I think sd_driver.f is ok.
After loading sd_driver.f, it seems to work sd_blockread & sd_blockread.
1 sd_blockread <----- Kingston 2G sd_blockread ENTER Block: 1 _sd_cmdr8data readlen: 512 _sd_cmdr8 CMD: 17 ARG: 512 RESPONSE: 0 .. .. _sd_cmdr16 CMD: 13 ARG: 0 _sd_cmdr8 CMD: 13 ARG: 0 RESPONSE: 0 RESPONSE: 0 sd_blockwrite EXIT
But after loading sd_driver.f & sdfs.f, executeing saveforth is strange.
Kingston 2GB SDSC Reboot CON:Prop0 Cog0 RESET - last status: 0 ok CON:Prop0 Cog1 RESET - last status: 0 ok CON:Prop0 Cog2 RESET - last status: 0 ok CON:Prop0 Cog3 RESET - last status: 0 ok CON:Prop0 Cog4 RESET - last status: 0 ok CON:Prop0 PROP REBOOT PropForth v4.5 2011MAY31 17:30 1 CON:Prop0 Cog5 RESET - last status: 0 ok CON:Prop0 Cog6 RESET - last status: 172 UNKNOWN ERROR <---- error code AC in _sd_blockread ---- It takes 26seconds ---- CON:Prop0 Cog0 RESET - last status: 7 LOCK TIMEOUT Prop0 Cog0 RESET - last status: 7 LOCK TIMEOUT Prop0 Cog0 ok
I thought sd_driver was strange from 172 UNKNOWN ERROR.
But this idea is wrong?
Any idea?
Thanks for the 4.7kOhm, I will try that.
The long time-out is is similar to the error I saw from my misformatted card as in log post #47.
Possibly try reformatting the card and running the SD test again, that's what I did and it worked the second time.
Seems like the Prop would be a great place to start. I only know enough SPIN to make PASM work, anyway. But I wonder if FORTH on the Prop is a suitable substitute for PASM for implementing things like SPI and I2C?
(BTW, it was an IBM researcher who was working on three-dimension data storage in crystals that fired up my interest in FORTH. He swore by the language. Nothing else in his experience allowed him to develop applications in so little time... In this instance we were articulating a platter that held his magic crystals while they were being interrogated by lasers.)
I was seeing similar "172 UNKNOWN ERROR" from various places when I was testing and playing with having sd_driver.f adn sdfs.f on EEPROM and loading and unloading them to free memory when not in use.
The following teraTerm output is from me doing an fsload of my sd_driver.f and sdfs.f from EEPROM - at the end of that script, mountsys and mountusr are defind and the mountsys word is executed. As you can see, all off that happens on Cog0:
. . . earlier output from script trimmed to keep it short! :smile: . [ifdef _sd_debug Prop0 Cog1 ok Prop0 Cog1 ok Prop0 Cog1 ok decimal Prop0 Cog1 ok Prop0 Cog1 ok Prop0 Cog1 ok Prop0 Cog0 ok decimal Prop0 Cog0 ok [ifndef mountsys : mountsys 0000000001 sd_mount ; ] Prop0 Cog0 ok [ifndef mountusr : mountusr 65538 sd_mount ; ] Prop0 Cog0 ok mountsys Prop0 Cog0 ok fread .sdcardinfo SDCard size: 1,927,160 Kbytes File System: sys Start Block: 1 End Block: 65,538 File System Size (blocks): 65,537 File System Size (bytes): 32,760 Kbytes File System: usr Start Block: 65,538 End Block: 3,854,336 File System Size (blocks): 3,788,798 File System Size (bytes): 1,894,390 Kbytes Prop0 Cog0 ok ls 337 .partion-sys/ 130 .sdcardinfo 136 .autousr.f 133 .autoload.f Prop0 Cog0 ok Prop0 Cog6 ok
At this point, the sd-driver.f and sdfs.f words are loaded and mountsys and mountusr have been created, also, mountsys has run on Cog0. As you can see below, if you do 'ls' from the Cog6 prompt, you get the 172 error. You need to do 'mountsys' on Cog6 so it can access the SD card.
Prop0 Cog6 ok ls CON:Prop0 Cog6 RESET - last status: 172 UNKNOWN ERROR Prop0 Cog6 RESET - last status: 172 UNKNOWN ERROR Prop0 Cog6 ok mountsys Prop0 Cog6 ok ls 337 .partion-sys/ 130 .sdcardinfo 136 .autousr.f 133 .autoload.f Prop0 Cog6 ok
I kept running into problems like this when I was testing the HTTP and IPSERVICES features. Often, one COG would load the SD system and have done a mountsys but another COG was trying to load the IP words and not be able to see the SD. Having the mount apply to a COG takes some planning and getting used to.
Hope this helps!
Rick
http://www.6502.org/source/
has this free download
http://www.6502.org/source/forth65.zip
I would send you a 386, except the shipping costs are more than I can handle. (Digging it out of the basement is more than I can handle at the monent). My forth pc is a Pentium 2; Forth runs crazy fast but it takes 3 minutes to boot to windows 98 before I can open the DOS window.. I am too lazy to make a native forth disk. Dig out that old PC that Aunt MArtha refused to take, and use that. It will be fine. Easier still it to find a discarded Laptop incapable of surfing the net, it will also be fine.
I recommend Frank Sargent's Pygmy Forth for use on the PC. It is brilliant and simple.
Probably not, if you ask many folks on these forums, but thats what we the forth team are doing. If your goal is to have more fun without bleaching you hair, forth is a good option. Sal Sanci made SPI for the EEPROM and Nick Lordi made a general SPI wordset, so clearly it can be done by loosely coupled widely dispersed team. Nobody has needed I2C yet so I nominate YOU to start. The PASM stuff (or more specifically prop assembler in the forth environment) is just the series of byte codes loaded into cog memory. The assembler, disassembler, and debugger etc are going to be optimized next release, if you start playing now you will be ready to jump in and kick butt by August release of v5.
This has been my experience too, except for the IBM, crystals, lasers and three dimensional storage part. But be aware that for every "success" story there are many not-success stories, so forth is not for everyone and is not a magic silver bullet as many disappointed managers wished. Folks that actually know something about what going on have the most success, "yours truely" being the exception that proves the rule.
Post here or PM me and we will get you up and running.
Sorry, this is not so clear.
There is only one access to the SD, only one file is open at a time.
Each cog must mount the partition (mountsys for system or mountusr for user).
The last file opened is the current file for all subsequent accesses until the next command that sets the file.
If one or more cogs are to access multiple files at the same time the user is responsible for structuring the words so that the mount-open-read-write sequence is correct.
This has been done by design to ensure that the absolute minimum overhead is involved, unless explicitly implemented by the user.
Currently SD access is subjectively observed to be very fast, by no benchmarks or statistics have been collected.
The "echo characters to screen" operation may be a bottleneck, eliminating this or other bottlenecks has not been explored yet.
Nothing to be sorry about. I was trying to figure this SD stuff out and also run my Spinner off a rapidly depleting battery.....let's just say things got confusing until I realized the battery was an issue. Once I got my house in order (and maybe back to following the instructions
I was hoping my 172 error experiences might be something cakaz could benefit from.
Rick
Sorry, I have misunderstanding everythibg about test-2.1.1 SD txt.
1 I used no-formatting SD-cards.
I thought I don't need to format because SD-cards can read/write on PC.
2 After loading sd_driver.f & sdfs.f , I did power-reset not reboot.
3 I was wrong how to test for sd_driver.f.
Again, I start to retry loading PropForthKernel.spin to eeprom.
I did procedure"test-2.1.1 SD.txt" again.
Used Kingston2GB(SDSC) formatted on PC.
All Messages are same as procedure"test-2.1.1 SD.txt".
After power-reset, message is ok.
But after I insert another SD-catd, error occured.
I re-insert SD-card(Kingston2G). But error remained.
CON:Prop0 Cog0 RESET - last status: 0 ok CON:Prop0 Cog1 RESET - last status: 0 ok CON:Prop0 Cog2 RESET - last status: 0 ok CON:Prop0 Cog3 RESET - last status: 0 ok CON:Prop0 Cog4 RESET - last status: 0 ok CON:Prop0 PROP REBOOT PropForth v4.5 2011MAY31 17:30 1 CON:Prop0 Cog5 RESET - last status: 0 ok CON:Prop0 Cog6 RESET - last status: 168 UNKNOWN ERROR Prop0 Cog6 RESET - last status: 168 UNKNOWN ERROR Prop0 Cog6 ok
Maybe system is broken. And Kingston2GB need to format again.
So I loaded PropForthKernel.spin again. Re-install everything.
Is there another way to avoid re-install.
If no SD-card, system don't be broken.
http://forums.parallax.com/showthread.php?132515-Quick-Start-Touch-Demo-plus-Forth&p=1012362&viewfull=1#post1012362
Sorry to be so long to respond.
If it works after instal, it works. If it is saved to SD, it will work again after power cycle.
REMEMBER - Each Cog that accesses the SD Must "mountsys" or "mountusr" Before lt will work. This got me a couple times, please check if this is involved in the issue.
I gave a brief presentation on Propforth, demonstrating the load process using caskaz demo on a Quickstart board, and discussing the v4.5 and v5.0 releases. There seems to be some interest, we'll see if new users begin posting. There will likely be more interest when the final kernel version comes out.
Today Sal informed me that the v5 kernel looks like a possible September arrival. The big difference will be the change in the assembler optimization. The old method caused assembler optimizations to consume cog memory; the new method in v5.x should allow the space used for optimization to be reused via "load from SD" and "forget after use".
Sal and Marco (kuroneko) did some test on the MultiChannel Synchronous Serial. I will try to get the findings form issue 27 and post a summary. The result is bug fixes to LogicAnalyzer.f and MCS.f, we will determine how to release the changes shortly.
caskaz's SD issue appear to involve SD v1 cards and/or MMC cards. We are trying to find a spec for these to ensure that we are compliant, but it appears the there may not have been much to go on for early implementations. The question becomes "how much effort to we want to put into rare early device support when a new one costs $8?"
We hope to resolve these issues and post a new release candidate (RC1) when complete.
Hi prof_braino.
Thanks!
I tried again. It works fine after power cycle.