OK,
I got rid of the problems that I was having with compiling by blowing away the old spin std library and installing a new one in a fresh directory. I then brought up one of my old versions and started in on bringing it up to date. What a nightmare. I think what I need to do is basically start over! Ojects have disappeared. Entry points have changed and so on. I think it will be easier to start with a clean sheet of paper.
Jim
@avsa242
Jessie I am trying an experment with the Propellartool under wine and I have encountered some issues. This is from the com.serial.ansi.spin2 Library
``
PUB binin = getbin
PUB rx_bin = getbin
PUB get_bin = getbin
PUB getbin(): b
' Receive CR-terminated string representing a binary value
' Returns: the corresponding binary value
gets_max(@_str_buff, SER_STR_BUFF_SZ)
return stl.atoib(@_str_buff, stl.IBIN)
``
Proptool under Wine does not like
PUB binin = getbin
nor does it like return stl.atoib(@...
Any suggestions?
Jim
Generally speaking, my library and objects/classes aren't compatible with Propeller Tool - it's just too limiting and doesn't work well under Wine. Many of them use features that only FlexSpin supports. I do note this in the Compiler compatibility section of the README.md that's included in every one of my repositories.
In that code above, I use the build-time function name aliases that FlexSpin supports. The syntax there is PUB alias_name = existing_method_name. I did this in many of the function names in my library when I updated the API months ago in an effort to try to retain compatibility with programs written using the old function names. I did it this way because there's some (albeit small) memory and processing overhead writing it using run-time alias methods like:
PUB binin(): b
return getbin()
My suggestion is to just use FlexSpin to avoid the headache of having to rewrite everything custom (because there are undoubtedly other objects you'll run into the same issue with), but in the above instance, you could just remove the alias definitions and use the method names that are there (or if you want you could rename them; it's your call).
As for the stl.atoib line, what is the error it comes up with?
@avsa242
Jessie,
I was attempting to compile a program under proptool because flexprop does not support "REG" function that Chip used in an ADC demo he wrote that uses an ISR to provide 8 channels of calibrated ADC data. The output results are in mv. Eric says that flexprop will probably never support that so I was trying to see if I could get Proptool under wine to compile the program for me. Not going to happen unless I go with fullduplexserial+ and not use your terminal program. I was hoping to view the results on a terminal instead of on a VGA monitor, too much trouble to set up the VGA. It appears that it is going to be easier to modify the program to just run in a cog. I have plenty to spare so I guess it rewrite time. I just hope I understand his PASM ISR code well enough to turn it into a cog run program.
The error for stl.atoib is "Expected an expression term"
Thanks for your input and giving me some insight into your thinking.
Jim
@avsa242
Jessie, is the Send command compatible with flexprop and printf? It looks like a useful construct and if it works, I would like to use it.
Jim
I think @ersmith is probably who you want to ask about compatibility with FlexProp (if I understand what you mean). I think he added send support a long time ago, though I've never used it. I think it's essentially a built-in specific-purpose method pointer. For any of the drivers I've written that have some sort of terminal I/O, I wrote before send was implemented or before I knew about it, so I went about things a different way: I #include a common set of terminal I/O routines with the driver that has text output capability (e.g., serial, vga, oled, etc) - all they really need is an elemental routine for drawing characters (putchar()). I'm not sure which way is more efficient or "better" fundamentally. Method pointers are definitely a really neat way of solving some problems.
FlexProp supports send. Whether or not use of send is compatible with printf depends on what "printf" you're talking about. Generally speaking if you're using a "printf" defined in some communication package (e.g. a serial package) then you should make the send pointer be the single character communication function from that package (e.g. "tx") if you want to use both printf and send at the same time.
@avsa242
Jessie,
I have been away from programing for a while and this week went back to work on my robot project. When I tried to compile using flexprop, I get the dollowing:
PUB syncwd_len(bytes=-2): curr_width
' Set length of syncword, in bytes
' Valid values: 3, 4, 5 (default: 5)
' Any other value polls the chip and returns the current setting
curr_width := 0
readreg(core.SETUP_AW, 1, @curr_width)
case bytes
3, 4, 5:
bytes -= 2 ' adjust to bitfield value
other:
return ((curr_width & core.AW_BITS) + 2)
bytes := ((curr_width & core.AW_MASK) | bytes)
writereg(core.SETUP_AW, 1, @bytes)
@RS_Jim , @avsa242 : The compiler was supposed to be able to handle bytes as an ordinary user variable, but I missed a case when the variable is a parameter with a default value. That's fixed in the github sources now. Sorry for the confusion, and thanks for the bug report.
No problem I thought I remembered reading that (some?) new keywords were intended to be usable as variables too, but I figured it'd be less confusing to just avoid naming them the same.
Happy new year.
Comments
Yup good point 👍
OK,
I got rid of the problems that I was having with compiling by blowing away the old spin std library and installing a new one in a fresh directory. I then brought up one of my old versions and started in on bringing it up to date. What a nightmare. I think what I need to do is basically start over! Ojects have disappeared. Entry points have changed and so on. I think it will be easier to start with a clean sheet of paper.
Jim
@avsa242
Jessie I am trying an experment with the Propellartool under wine and I have encountered some issues. This is from the com.serial.ansi.spin2 Library
``
PUB binin = getbin
PUB rx_bin = getbin
PUB get_bin = getbin
PUB getbin(): b
' Receive CR-terminated string representing a binary value
' Returns: the corresponding binary value
gets_max(@_str_buff, SER_STR_BUFF_SZ)
return stl.atoib(@_str_buff, stl.IBIN)
``
Proptool under Wine does not like
PUB binin = getbin
nor does it like return stl.atoib(@...
Any suggestions?
Jim
@RS_Jim
Generally speaking, my library and objects/classes aren't compatible with Propeller Tool - it's just too limiting and doesn't work well under Wine. Many of them use features that only FlexSpin supports. I do note this in the
Compiler compatibilitysection of the README.md that's included in every one of my repositories.In that code above, I use the build-time function name aliases that FlexSpin supports. The syntax there is
PUB alias_name = existing_method_name. I did this in many of the function names in my library when I updated the API months ago in an effort to try to retain compatibility with programs written using the old function names. I did it this way because there's some (albeit small) memory and processing overhead writing it using run-time alias methods like:PUB binin(): b return getbin()My suggestion is to just use FlexSpin to avoid the headache of having to rewrite everything custom (because there are undoubtedly other objects you'll run into the same issue with), but in the above instance, you could just remove the alias definitions and use the method names that are there (or if you want you could rename them; it's your call).
As for the
stl.atoibline, what is the error it comes up with?Cheers
Jesse
@avsa242
Jessie,
I was attempting to compile a program under proptool because flexprop does not support "REG" function that Chip used in an ADC demo he wrote that uses an ISR to provide 8 channels of calibrated ADC data. The output results are in mv. Eric says that flexprop will probably never support that so I was trying to see if I could get Proptool under wine to compile the program for me. Not going to happen unless I go with fullduplexserial+ and not use your terminal program. I was hoping to view the results on a terminal instead of on a VGA monitor, too much trouble to set up the VGA. It appears that it is going to be easier to modify the program to just run in a cog. I have plenty to spare so I guess it rewrite time. I just hope I understand his PASM ISR code well enough to turn it into a cog run program.
The error for stl.atoib is "Expected an expression term"
Thanks for your input and giving me some insight into your thinking.
Jim
@avsa242
Jessie, is the Send command compatible with flexprop and printf? It looks like a useful construct and if it works, I would like to use it.
Jim
I think @ersmith is probably who you want to ask about compatibility with FlexProp
(if I understand what you mean). I think he added
sendsupport a long time ago, though I've never used it. I think it's essentially a built-in specific-purpose method pointer. For any of the drivers I've written that have some sort of terminal I/O, I wrote beforesendwas implemented or before I knew about it, so I went about things a different way: I#includea common set of terminal I/O routines with the driver that has text output capability (e.g., serial, vga, oled, etc) - all they really need is an elemental routine for drawing characters (putchar()). I'm not sure which way is more efficient or "better" fundamentally. Method pointers are definitely a really neat way of solving some problems.FlexProp supports send. Whether or not use of send is compatible with printf depends on what "printf" you're talking about. Generally speaking if you're using a "printf" defined in some communication package (e.g. a serial package) then you should make the send pointer be the single character communication function from that package (e.g. "tx") if you want to use both printf and send at the same time.
Thanks Eric, I will do some playing with this and see what happens.
Jim
@avsa242
Jessie,
I have been away from programing for a while and this week went back to work on my robot project. When I tried to compile using flexprop, I get the dollowing:
PUB syncwd_len(bytes=-2): curr_width ' Set length of syncword, in bytes ' Valid values: 3, 4, 5 (default: 5) ' Any other value polls the chip and returns the current setting curr_width := 0 readreg(core.SETUP_AW, 1, @curr_width) case bytes 3, 4, 5: bytes -= 2 ' adjust to bitfield value other: return ((curr_width & core.AW_BITS) + 2) bytes := ((curr_width & core.AW_MASK) | bytes) writereg(core.SETUP_AW, 1, @bytes)When compiling i get the following errors:
/home/jim/Library/New_P2robot/wireless.transceiver.nrf24l01.spin2:802: error: syntax error, unexpected end of line, expecting '(' /home/jim/Library/New_P2robot/wireless.transceiver.nrf24l01.spin2:803: error: syntax error, unexpected ',' /home/jim/Library/New_P2robot/wireless.transceiver.nrf24l01.spin2:808: error: syntax error, unexpected :=, expecting '(' /home/jim/Library/New_P2robot/wireless.transceiver.nrf24l01.spin2:809: error: syntax error, unexpected ')', expecting '('any guesses as to what is happening? This is with @EricSmith latest version of flexprop.
Jim
@RS_Jim
Hi Jim,
I think there's a new reserved word
bytesin spin2, so my variable of the same name clashes with it. I'll submit a fix soon, thanks for catching this.Cheers
@RS_Jim
It should be fixed in latest git now (both the nrf24l01-spin repository and the copy in p2-spin-standard-library).
@RS_Jim , @avsa242 : The compiler was supposed to be able to handle
bytesas an ordinary user variable, but I missed a case when the variable is a parameter with a default value. That's fixed in the github sources now. Sorry for the confusion, and thanks for the bug report.No problem
I thought I remembered reading that (some?) new keywords were intended to be usable as variables too, but I figured it'd be less confusing to just avoid naming them the same.
Happy new year.
@avsa242 & @ersmith
Thanks for the quick replies. I guess at this point, I would be wise to reinstall latest flexprop and spin stardard library.
Jim
@avsa242
Jessie,
This old man is having a memory block! How do I get the library to download from Github?
Jim
Hi Jim,
If it's a copy you already have, you can cd into its directory and type
git pullto update it.If you're trying to get a new copy:
git clone https://github.com/avsa242/p2-spin-standard-library.gitand it'll create a new dir.Cheers
@avsa242
thanks Jessie, I actually needed to do both.
Jim