Thank you for such a nice compliment. That means a lot to me, coming from a true professional.
I always wanted to learn PASM, but never set the time aside, and now that I am into the C scene, I doubt that I ever will. Anyhow, I never knew that about PASM. I can see where that would be a big turn off to the language.
That is all very interesting and quite an acheivement. Do you have any idea how many people are actively using Tachyon at this point?
Thanks Bruce, I don't see myself as a "true professional", I just like to have fun and muck around and make some money while I do it
You shouldn't really regard PASM as a language. Sure, while it is "assembly language", from my POV I think it's a necessity to know the assembly language of any micro I use, that way I can choose what to code in knowing the limitations and the capabilities of the core CPU, rather than being limited by the language itself. Take Spin for instance, while it's "slow" it is still perfectly fine for the vast majority of programming on the Propeller with special PASM objects to handle the real-time grunt just as the Propeller with it's multiple CPUs was designed to do. If you were to judge the Prop based on Spin you would miss out on what it was really capable of because of not knowing PASM. Yet PASM is just another assembly language, they are all very straightforward really, simple operations that work on a bunch of registers normally. Once you are familiar with the basics of assembly then it becomes easier to learn assembly for a new CPU and being familiar with the architecture sure helps too, as does being familiar with digital logic. All simple stuff really.
While the Propeller chip itself is very different from other CPUs, each cog is really a fairly simple nicely self-contained 32-bit CPU with a limited but efficient instruction set for addressing 512 longs of memory/registers. In this it works really well. The 32k hub RAM is more like an external multiport memory chip and there are only basic instructions for reading and writing to this as well as some hub instructions, so you can't run assembly from this. Know the CPU and you know the chip and then it is quite clear why we have the Spin interpreter and why with the limited memory on each cog that the cog that is loaded up with the Spin interpreter kernel can't run user assembly code at the same time, it needs to be off-loaded into another cog.
In the meantime I've posted on the Tachyon thread asking for user to raise their hands but even just a casual perusal of the thread indicates that there have been quite a number using it with D.P and MJB more recently describing projects they have successfully completed.
One more question pertaining to the LCD issue and in reference to using your latest schematic with diodes....
Earlier in this discussion, you referenced 5V:
It's unlikely that the LCD needs a 5V input signal since it was happy with half of that in your tests which is in keeping with the SX chip's TTL compatible inputs I believe.
During my test on the Prop BOE with the diodes, I used 3.3V for V+(per schematic) instead of 5V, and it worked fine. However, I wonder if I would be better off tying the 10K to 5V or 3.3V?
One more question pertaining to the LCD issue and in reference to using your latest schematic with diodes....
Earlier in this discussion, you referenced 5V:
During my test on the Prop BOE with the diodes, I used 3.3V for V+(per schematic) instead of 5V, and it worked fine. However, I wonder if I would be better off tying the 10K to 5V or 3.3V?
I suspect that the Vih of the LCD is 2V TTL compatible so it doesn't matter if you pullup to 3.3V or even 5V is fine although due to the Prop I/O clamping the high voltage will probably be more like 4V so there is no real advantage using 5V unless it is more convenient.
Comments
Thanks Bruce, I don't see myself as a "true professional", I just like to have fun and muck around and make some money while I do it
You shouldn't really regard PASM as a language. Sure, while it is "assembly language", from my POV I think it's a necessity to know the assembly language of any micro I use, that way I can choose what to code in knowing the limitations and the capabilities of the core CPU, rather than being limited by the language itself. Take Spin for instance, while it's "slow" it is still perfectly fine for the vast majority of programming on the Propeller with special PASM objects to handle the real-time grunt just as the Propeller with it's multiple CPUs was designed to do. If you were to judge the Prop based on Spin you would miss out on what it was really capable of because of not knowing PASM. Yet PASM is just another assembly language, they are all very straightforward really, simple operations that work on a bunch of registers normally. Once you are familiar with the basics of assembly then it becomes easier to learn assembly for a new CPU and being familiar with the architecture sure helps too, as does being familiar with digital logic. All simple stuff really.
While the Propeller chip itself is very different from other CPUs, each cog is really a fairly simple nicely self-contained 32-bit CPU with a limited but efficient instruction set for addressing 512 longs of memory/registers. In this it works really well. The 32k hub RAM is more like an external multiport memory chip and there are only basic instructions for reading and writing to this as well as some hub instructions, so you can't run assembly from this. Know the CPU and you know the chip and then it is quite clear why we have the Spin interpreter and why with the limited memory on each cog that the cog that is loaded up with the Spin interpreter kernel can't run user assembly code at the same time, it needs to be off-loaded into another cog.
In the meantime I've posted on the Tachyon thread asking for user to raise their hands but even just a casual perusal of the thread indicates that there have been quite a number using it with D.P and MJB more recently describing projects they have successfully completed.
One more question pertaining to the LCD issue and in reference to using your latest schematic with diodes....
Earlier in this discussion, you referenced 5V:
During my test on the Prop BOE with the diodes, I used 3.3V for V+(per schematic) instead of 5V, and it worked fine. However, I wonder if I would be better off tying the 10K to 5V or 3.3V?
I suspect that the Vih of the LCD is 2V TTL compatible so it doesn't matter if you pullup to 3.3V or even 5V is fine although due to the Prop I/O clamping the high voltage will probably be more like 4V so there is no real advantage using 5V unless it is more convenient.
I will do my best not to pester you for a bit, so you can work on your projects
Thank you for all of your help.