Chip,
Noticed a problem when compiling FemtoBasic with v34S. It's fine with fastspin 4.1.8.
A global variable with the same name as a local variable in the parameter list of a PUB/PRI prototype causes an error in pnut but not in fastspin.
eg massFlag
var
long massFlag
PUB usingFormat(massFlag)
I'm a little torn as it's a local with the same name as a global. Should it work or cause an error???
Oh, and I noticed a file using <lf> instead of <cr><lf> causes pnut to error.
Chip,
Noticed a problem when compiling FemtoBasic with v34S. It's fine with fastspin 4.1.8.
A global variable with the same name as a local variable in the parameter list of a PUB/PRI prototype causes an error in pnut but not in fastspin.
eg massFlag
var
long massFlag
PUB usingFormat(massFlag)
I'm a little torn as it's a local with the same name as a global. Should it work or cause an error???
Oh, and I noticed a file using <lf> instead of <cr><lf> causes pnut to error.
Chip,
Noticed a problem when compiling FemtoBasic with v34S. It's fine with fastspin 4.1.8.
A global variable with the same name as a local variable in the parameter list of a PUB/PRI prototype causes an error in pnut but not in fastspin.
eg massFlag
var
long massFlag
PUB usingFormat(massFlag)
I'm a little torn as it's a local with the same name as a global. Should it work or cause an error???
Oh, and I noticed a file using <lf> instead of <cr><lf> causes pnut to error.
Names must be unique in Spin2 to avoid ambiguity.
Could you give an example of the IF issue?
This file is an OBJ in another file. The error reports "No PUB methods found"
Any spin2 file with LF line endings shows up as one giant line inside of PNUT's editor, and the compiler chokes at the first line ending.
Ah, I understand now. I can make PNut better at this by maybe using these rules, internally:
$0D, $0A ---> $0D
Lone $0A ---> $0D (and set flag to save with $0A for EOL)
Another way for consideration (avoids an operation on the first case, and avoids using 0D "CR" as a line ending, which is not valid in certain editors)
$0D, $0A ---> $0D, $0A (ie. do nothing)
Lone $0A ---> $0D, $0A (and set flag to remove $0D for EOL)[/quote]
Or use 0A as a single ending, with a flag to insert 0D. Or split on 0A and trim 0D if exists. Gosh, a few options to save using 2 bytes internally too !
Sure, this is internal, but your code might be extended later so having CR as an internal line ending might risk a future trip-up.
Any spin2 file with LF line endings shows up as one giant line inside of PNUT's editor, and the compiler chokes at the first line ending.
Ah, I understand now. I can make PNut better at this by maybe using these rules, internally:
$0D, $0A ---> $0D
Lone $0A ---> $0D (and set flag to save with $0A for EOL)
I think you will find that, for internal processing...
1. If a <lf> follows a <cr> then strip the <lf>
2. If a <lf> is not preceded by a <cr> then replace with <cr>
This allows for the cases of
1. multiple <cr> which are acceptable
2. multiple <lf> which are acceptable
So, it's necessary to keep the last character, before any modification, as you are reading the file in.
Personally, I would not re-write the file with the <lf> and <cr> changes made. It's been a bugbear for more than 40 years!!!
A little history
In the days of teleprinters/flexowriters/etc, the <cr> "carriage return" returned the carriage to the start of line. A <lf> "line feed" advance the carriage one line. In the early days these characters were not represented by ASCII characterset, but charactersets devised by various companies. For instance, the baudot code was a 5 bit code for telex machines.
As glass teletypes (videos) developed, and communications was slow, some saved a character in the transmission by performing a <cr><lf> on receipt of a <cr> or <lf> depending on the manufacturer. Around similar times, the ASCII codeset was formed. Note many mainframes at the time had adopted IBM's EBCDIC codeset specifically so that they could exchange data with the leader of the time being IBM. Many minis however adopted the ASCII codeset, which IIRC was originally only 7 bits. Some minis (including the Friden/Singer/ICL that I worked on) used only 6 bit ASCII giving just 64 printable uppercase characters. Most printers originally supported only uppercase.
Anyway, back to the crlf problem. As the glass teletypes took over, many of these manufacturers saw the opportunity to sell their videos to other companies. Shortly thereafter the microcontroller was born. Many of these video companies built their videos with the Intel 8008 micro as the base with Intel 1702 EEPROMs. Thus these videos were "programmable" and therefore could emulate the mainframe and minis terminals. So there was no requirement to enforce a standard for the crlf because the OEM manufacturers catered to the various minis and mainframes by firmware and sometimes a few dip switches
IBM, Apple, CPM, UNIX, etc all compounded to the crlf problem by their different stance, as it carried over into files
Not that cr lf thing again. A line feed is a line feed to the next line in the same column, and a carriage return is a return of the "carriage" to the left column or margin.
I frequently and purposely use CR to continually print an update on the left side and only advance to the next line when I give it a LF, which it should.
I have been using Mecrisp Forth and it only outputs a LF after a line so I have to tell whatever ANSI terminal I'm using to add a CR !^%$!
Some Forths or CLIs only output a CR, and I have to add a LF. Same deal.
Are you sure you were able to do that in spin1? Isn't ++ an assignment (and cogid a read-only "variable")
I've just tried building this with OpenSpin for the P1, and it doesn't like it:
PUB Main | cardCogID
cardCogID := cogid++
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2018 Parallax Inc. DBA Parallax Semiconductor.
Version 1.00.81 Compiled on Sep 3 2018 09:56:10
Compiling...
test.spin
test.spin(3:23) : error : Expected end of line
Line:
cardcogid := cogid++
Offending Item: ++
The ++ after a variable is post increment. The value of the variable is read first for any expression involved, then the value of the variable is incremented. You can't use ++ on a function.
x := 10
y := x++
z := x++
ser.printf("x:%d y:%d z:%d\n", x, y, z)
The above will print: x:12 y:10 z:11 and that is exactly correct.
Thanks Roy.
Yes cogID is indeed a function and cogid++ did not work on P1 either.
Seems I incorrectly translated a +1 into a ++ a long time back but without being able to test it at the time
I guess that's what I get when I translated a big chunk of code over a year ago but was then unable to test the changes.
Ray,
You need to set P59^ switch on. This will prevent the SD card from booting and allows the serial to start.
pnut does the reset sequence different to loadp2 that we use with fastspin.
The current P2D2 USB serial has enhancement that only reset the P2 on a valid short DTR load pulse while at the same time pulling up P59 to force the P2 into serial load mode. This means it will always load up new code even if you have a bootable SD card or Flash present. No need to pull that card out, then DTR changes from connect/disconnects do not reset the P2 on P2D2 but unfortunately the P2 eval only has a simple capacitor which always resets the P2.
I don't see why it works just fine with Fastspin but I have to take out my uSD card with PNut...
It's possible to interrupt the SD bootload with another reset right in the middle of transfers which might disable SD bootload during this second reset. I know, I've been able to get loadp2 to override the SD on the P2 eval board this way if I retry quickly enough in the middle of a boot check.
Yes, loadp2 usually follows fastspin. I use the W10 command line and a bat file to compile and then load, and it does a fastspin and then loadp2.
I use a build task in Visual Code that will build code with either Pnut or Fastspin and then load the correct .bin or .binary with loadp2. Also using your syntax highlighter for editing.
Yes, loadp2 usually follows fastspin. I use the W10 command line and a bat file to compile and then load, and it does a fastspin and then loadp2.
I use a build task in Visual Code that will build code with either Pnut or Fastspin and then load the correct .bin or .binary with loadp2. Also using your syntax highlighter for editing.
Excellent
It's been a couple of years since I did the VSCode setup. Guess I need to see how to use build code again.
I think there was some discussion on this a while ago, but could PNut and other compilers be made to warn if the two arguments to a D,S instruction following an SCA-type instruction differ? This will encourage people to write forward-compatible code that will still work if the decision is made in a future version of the silicon to dump the result into the next instruction's D, instead of its S, which would allow a two-instruction Y = M*X + B, while still allowing the current Y += M*X.
Here is a question for the best way to do it in spin2.
I have a count "n" for a time period in system clocks, and of course I have "f" = _clkfreq.
In that time, I have processed "b" bytes.
Now I want to calculate the Bytes/Second transfer. Of course I can scale the values to ensure no overflows and underflows.
t(seconds) = n / f
Thus Bps = b / t(sec) = b * f / n
How can cordic help here and it it worthwhile using ???
Comments
Noticed a problem when compiling FemtoBasic with v34S. It's fine with fastspin 4.1.8.
A global variable with the same name as a local variable in the parameter list of a PUB/PRI prototype causes an error in pnut but not in fastspin.
eg massFlag
I'm a little torn as it's a local with the same name as a global. Should it work or cause an error???
Oh, and I noticed a file using <lf> instead of <cr><lf> causes pnut to error.
Names must be unique in Spin2 to avoid ambiguity.
Could you give an example of the IF issue?
Any spin2 file with LF line endings shows up as one giant line inside of PNUT's editor, and the compiler chokes at the first line ending.
EDIT: For example, see the attached file, which is vga_text_demo.spin2 but converted to use LF (Unix-style) line endings.
Ah, I understand now. I can make PNut better at this by maybe using these rules, internally:
$0D, $0A ---> $0D
Lone $0A ---> $0D (and set flag to save with $0A for EOL)
This file is an OBJ in another file. The error reports "No PUB methods found"
Another way for consideration (avoids an operation on the first case, and avoids using 0D "CR" as a line ending, which is not valid in certain editors)
$0D, $0A ---> $0D, $0A (ie. do nothing)
Lone $0A ---> $0D, $0A (and set flag to remove $0D for EOL)[/quote]
Or use 0A as a single ending, with a flag to insert 0D. Or split on 0A and trim 0D if exists. Gosh, a few options to save using 2 bytes internally too !
Sure, this is internal, but your code might be extended later so having CR as an internal line ending might risk a future trip-up.
I presume spin2 does not support the P1 module#constant syntax? The "." syntax works fine.
I think you will find that, for internal processing...
1. If a <lf> follows a <cr> then strip the <lf>
2. If a <lf> is not preceded by a <cr> then replace with <cr>
This allows for the cases of
1. multiple <cr> which are acceptable
2. multiple <lf> which are acceptable
So, it's necessary to keep the last character, before any modification, as you are reading the file in.
Personally, I would not re-write the file with the <lf> and <cr> changes made. It's been a bugbear for more than 40 years!!!
A little history
In the days of teleprinters/flexowriters/etc, the <cr> "carriage return" returned the carriage to the start of line. A <lf> "line feed" advance the carriage one line. In the early days these characters were not represented by ASCII characterset, but charactersets devised by various companies. For instance, the baudot code was a 5 bit code for telex machines.
As glass teletypes (videos) developed, and communications was slow, some saved a character in the transmission by performing a <cr><lf> on receipt of a <cr> or <lf> depending on the manufacturer. Around similar times, the ASCII codeset was formed. Note many mainframes at the time had adopted IBM's EBCDIC codeset specifically so that they could exchange data with the leader of the time being IBM. Many minis however adopted the ASCII codeset, which IIRC was originally only 7 bits. Some minis (including the Friden/Singer/ICL that I worked on) used only 6 bit ASCII giving just 64 printable uppercase characters. Most printers originally supported only uppercase.
Anyway, back to the crlf problem. As the glass teletypes took over, many of these manufacturers saw the opportunity to sell their videos to other companies. Shortly thereafter the microcontroller was born. Many of these video companies built their videos with the Intel 8008 micro as the base with Intel 1702 EEPROMs. Thus these videos were "programmable" and therefore could emulate the mainframe and minis terminals. So there was no requirement to enforce a standard for the crlf because the OEM manufacturers catered to the various minis and mainframes by firmware and sometimes a few dip switches
IBM, Apple, CPM, UNIX, etc all compounded to the crlf problem by their different stance, as it carried over into files
I frequently and purposely use CR to continually print an update on the left side and only advance to the next line when I give it a LF, which it should.
I have been using Mecrisp Forth and it only outputs a LF after a line so I have to tell whatever ANSI terminal I'm using to add a CR !^%$!
Some Forths or CLIs only output a CR, and I have to add a LF. Same deal.
Are you sure you were able to do that in spin1? Isn't ++ an assignment (and cogid a read-only "variable")
I've just tried building this with OpenSpin for the P1, and it doesn't like it:
PUB Main | cardCogID cardCogID := cogid++ Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2018 Parallax Inc. DBA Parallax Semiconductor. Version 1.00.81 Compiled on Sep 3 2018 09:56:10 Compiling... test.spin test.spin(3:23) : error : Expected end of line Line: cardcogid := cogid++ Offending Item: ++x := 10 y := x++ z := x++ ser.printf("x:%d y:%d z:%d\n", x, y, z)The above will print: x:12 y:10 z:11 and that is exactly correct.Yes cogID is indeed a function and cogid++ did not work on P1 either.
Seems I incorrectly translated a +1 into a ++ a long time back but without being able to test it at the time
I guess that's what I get when I translated a big chunk of code over a year ago but was then unable to test the changes.
Is there some tweak I need to do somewhere?
Pull out the SD card.
That worked.
Not so convenient for me though...
You need to set P59^ switch on. This will prevent the SD card from booting and allows the serial to start.
pnut does the reset sequence different to loadp2 that we use with fastspin.
It's possible to interrupt the SD bootload with another reset right in the middle of transfers which might disable SD bootload during this second reset. I know, I've been able to get loadp2 to override the SD on the P2 eval board this way if I retry quickly enough in the middle of a boot check.
It's been a couple of years since I did the VSCode setup. Guess I need to see how to use build code again.
ie multiply and return the upper 32 bits
SCA does that, unsigned. SCAS does it signed, but shifts arithmetically right by 30 instead of 32.
Here is a question for the best way to do it in spin2.
I have a count "n" for a time period in system clocks, and of course I have "f" = _clkfreq.
In that time, I have processed "b" bytes.
Now I want to calculate the Bytes/Second transfer. Of course I can scale the values to ensure no overflows and underflows.
t(seconds) = n / f
Thus Bps = b / t(sec) = b * f / n
How can cordic help here and it it worthwhile using ???