@Rayman said:
That is a cool feature of FlexProp where you can do Spin1 on P2 and Spin2 on P1, if you want.
Chip really listened to Spin2 feature requests and delivered on a language that is much better, IMHO.
So, if I were to do something on P1 again, I might be very tempted to do it with FlexProp and Spin2.
OTOH, there is a lot of existing Spin1 code for P1, so might not work the best....
You can certainly use Spin1 objects from Spin2 code with FlexProp (for that matter you can use C or BASIC files as objects, too). You might sometimes have to explicitly give the file extension, like:
obj
ser: "FullDuplexSerial.spin"
although if there's no possibility for conflict (no .spin2 version of the file) I think the compiler can find it just as "FullDuplexSerial".
I've released version 6.8.0 of FlexProp on both github and my Patreon page (see my signature for links). The changes in this version of the compiler include:
Version 6.8.0
- Added support for `%"xyzw"` constants in Spin2
- Added locking for host file system I/O
- Added `--compress` flag to compress binaries (courtesy of Ada)
- Fixed incorrect inline assembly for `#outb` and other hw registers
- Made `@foo.bar` work when `bar` is a label
- Supported PNut v43 `{Spin2_vNN}` version comments
FlexProp 6.9.1 is available from Patreon and from github (see my signature for links). This is mainly a bug fix release. The main improvement over 6.8.x (besides the many bug fixes) is an optimization to remove identical functions. This can be useful for small access functions, because often the generated code ends up being the same even though the objects involved are superficially different.
Arrg! Flexprop 6.9.1 totally messes up my EtherCat test program. I can't say what is actually causing it but it looks like the memory layout is messed up. I get garbled logfile output and sometimes printf hangs. Eric, have you changed anything of the alignment of struct member variables?
6.6.1 ran fine, 6.8.0 had the bool initializer problem but still compiled and ran without problems. 6.9.1 doesn't work at all. Unfortunatelly, I don't have much time this weekend. And this will definitely take some time to debug. The code is big and uses a lot of pointers, structures, buffers and dynamic memory allocation. So it's not unlikely that it's caused by my own mistakes that just different outcomes as memory layout changed...
@ManAtWork : if your structs have any "bool" members then you should probably change them to "uint8_t" (or "uint32_t" if you wanted them to be 32 bits). The size of bool has changed between different compiler versions.
@ersmith said:
@ManAtWork : if your structs have any "bool" members then you should probably change them to "uint8_t" (or "uint32_t" if you wanted them to be 32 bits). The size of bool has changed between different compiler versions.
It turned out that it has nothing to do with bool. I already use uint8_t in all structs that need a specific layout and size because they are sent over the network.
I did some shotgun debugguing and deleted or commented out all irrelevant code until I got a minimal skeleton that still reproduces the problem. It runs only in a single cog and doesn't call any hardware-dependant drivers so it should run on a plain KISS board or any other P2 board if the _xtlfreq is adjusted. It basically calls Print3() in debuglog.c and then DumpBuffer(). If I use compiler V6.8.0 or if I comment out the static EC_TaskDescr taskBuffer[EC_MaxNumTasks]; it runs correctly and prints out
But if I use compiler 6.9.1 and don't comment out the taskBuffer declaration it crashes just at the printf() at line 201 of debuglog.c. It looks a bit like a stack overflow inside printf() but that shouldn't happen as it runs in cog0 and the main stack. I also verified that the log buffer and the format string for printf() are not overwritten. Their addresses and hex dumps look reasonable. As debuglog.c is tested quite well and works without any problems with hundreds of calls to Print0..Print5() when using compiler V6.8.0 I don't finds any obvious bugs.
@JRoark : somehow reading data from strings got messed up in 6.9 (so it's not your bug, it's mine). That'll be fixed in the next release.
@ManAtWork : the problem is in bool, I forgot to update the alignment requirement when I updated the size of bool, so if any structs use bool then memory near them can be corrupted. That's fixed in the next release, or you can work around it for now by changing all bool to uint8_t.
Hi,
I wanted to make a tile driver 8x8 (which I want to include in a version of Taqoz later), which needs 3bytes for two chars sharing one byte for colors - save the space! It is derived from Erics example, many thanks here!
Questions:
1. There are some miracles for me: What for is the NOP in line 109 in the tile driver needed???? It was needed, when I inserted line 108. Thanks for any hints!
2. Are there other 8x8 fonts available in this format? Especially I would like a font with subtiles like CPC6128. I mean the first row after the ascii chars.
Christof
@"Christof Eb." said:
Hi,
I wanted to make a tile driver 8x8 (which I want to include in a version of Taqoz later), which needs 3bytes for two chars sharing one byte for colors - save the space! It is derived from Erics example, many thanks here!
Questions:
1. There are some miracles for me: What for is the NOP in line 109 in the tile driver needed???? It was needed, when I inserted line 108. Thanks for any hints!
I don't know why that NOP would be required. Have you tried moving it around? Does it have to be in just that spot, or anywhere at the beginning? I doubt it's a timing issue (that is initialization code, not time critical) so probably it has something to do with memory alignment. Maybe something in the code that's loaded into LUT needs to be at a particular address in HUB RAM? That shouldn't be the case, but maybe there's a bug.
Are there other 8x8 fonts available in this format? Especially I would like a font with subtiles like CPC6128. I mean the first row after the ascii chars.
There's a tool for converting X window .bdf fonts into .bin files: it's called "makebitmap" and you can find it in the repository at https://github.com/totalspectrum/p2_vga_text, which is a more complete (and possibly more recent) version of the demo that's included with FlexProp. With makebitmap you can include a map file to specify which Unicode characters should be taken from the font and put at which position in the P2 font file.
@"Christof Eb." said:
1. There are some miracles for me: What for is the NOP in line 109 in the tile driver needed???? It was needed, when I inserted line 108. Thanks for any hints!
I get a bunch of compile warnings that you should probably be fixing:
unscii-8.spin2:16: warning: function getfont returns a value but was declared without a return variable: this flexspin extension is deprecated
demoTile12C.spin2:60: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:61: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:66: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:67: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:68: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:69: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:74: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:75: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:79: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:80: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:81: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:82: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:83: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:88: warning: function start returns a value but was declared without a return variable: this flexspin extension is deprecated
Looks like there is lingering imprecise addresses supplied to a FIT directive and a SETQ2. I'd fix LINE_HANDLER_END's use with setq2 #(LINE_HANDLER_END-LINE_HANDLER) and fit LINE_HANDLER_END+1. Then for tidiness, make FIELD_HANDLER_END = $39f and the matching setq2 #(FIELD_HANDLER_END-FIELD_HANDLER) and fit FIELD_HANDLER_END+1.
That's my quick look done. Unlikely I've found anything that's a bug though.
@evanh said:
Looks like there is lingering imprecise addresses supplied to a FIT directive and a SETQ2. I'd fix LINE_HANDLER_END's use with setq2 #(LINE_HANDLER_END-LINE_HANDLER) and fit LINE_HANDLER_END+1. Then for tidiness, make FIELD_HANDLER_END = $39f and the matching setq2 #(FIELD_HANDLER_END-FIELD_HANDLER) and fit FIELD_HANDLER_END+1.
That's my quick look done. Unlikely I've found anything that's a bug though.
Thanks for having a look into this! As my 3/2driver cannot have 256 colors but only Background+8+Inverse or Background+16, I should be able to shorten the color table very much. This will free up space for the routines sitting now in lut. And I don't need dynamic loading of these routines. So the plan is to simplify and bring the routines "back" into cog. The assembler of Taqoz is made for short routines and I was now busy to bring in the possibility for forward jumps and calls. Let's see, if I will come to understand this NOP thingy in the process....
@"Christof Eb." said:
Hi,
I wanted to make a tile driver 8x8 (which I want to include in a version of Taqoz later), which needs 3bytes for two chars sharing one byte for colors - save the space! It is derived from Erics example, many thanks here!
Questions:
1. There are some miracles for me: What for is the NOP in line 109 in the tile driver needed???? It was needed, when I inserted line 108. Thanks for any hints!
I don't know why that NOP would be required. Have you tried moving it around? Does it have to be in just that spot, or anywhere at the beginning? I doubt it's a timing issue (that is initialization code, not time critical) so probably it has something to do with memory alignment. Maybe something in the code that's loaded into LUT needs to be at a particular address in HUB RAM? That shouldn't be the case, but maybe there's a bug.
Are there other 8x8 fonts available in this format? Especially I would like a font with subtiles like CPC6128. I mean the first row after the ascii chars.
There's a tool for converting X window .bdf fonts into .bin files: it's called "makebitmap" and you can find it in the repository at https://github.com/totalspectrum/p2_vga_text, which is a more complete (and possibly more recent) version of the demo that's included with FlexProp. With makebitmap you can include a map file to specify which Unicode characters should be taken from the font and put at which position in the P2 font file.
@"Christof Eb." said:
1. There are some miracles for me: What for is the NOP in line 109 in the tile driver needed???? It was needed, when I inserted line 108. Thanks for any hints!
I get a bunch of compile warnings that you should probably be fixing:
unscii-8.spin2:16: warning: function getfont returns a value but was declared without a return variable: this flexspin extension is deprecated
demoTile12C.spin2:60: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:61: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:66: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:67: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:68: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:69: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:74: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:75: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:79: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:80: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:81: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:82: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:83: warning: mixing tabs and spaces for indentation on same line
demoTile12C.spin2:88: warning: function start returns a value but was declared without a return variable: this flexspin extension is deprecated
Well, yes, I try to avoid SPIN2. It is just .... that Parallax customers are forced to learn this superfluous special language, that uses non visible indentation as critical element of the language.....
Edit: Propellertool solves the none-visibility problem though.
@"Christof Eb." said:
Well, yes, I try to avoid SPIN2. It is just .... that Parallax customers are forced to learn this superfluous special language, that uses non visible indentation as critical element of the language.....
Edit: Propellertool solves the none-visibility problem though.
What do you have against semantically-meaningful whitespace? It forces you to correctly indent your code.
FYI, most decent editors can be configured to subtly shows low-contrast dots or dashes where spaces or tabs are, so you can see them when you want to without it being distracting. This is sometimes its own feature (e.g. VS Code, Sublime Text), or just the old-fashioned list mode toned-down to be less obnoxious (e.g. vim).
What do you have against semantically-meaningful whitespace? It forces you to correctly indent your code.
Might be mis-remembering, here because I haven't touched SPIN since 2011 but I seem to remember forgetting to indent and the interpreter didn't know any better. Program simply didn't work.
DO/LOOP (Basic) needs to be intact or the interpreter/compiler picks up on it.
What do you have against semantically-meaningful whitespace? It forces you to correctly indent your code.
Might be mis-remembering, here because I haven't touched SPIN since 2011 but I seem to remember forgetting to indent and the interpreter didn't know any better. Program simply didn't work.
DO/LOOP (Basic) needs to be intact or the interpreter/compiler picks up on it.
Craig
The interpreter can't read your mind about missing whitespace, the same way it can't read your mind about missing curly braces. In any language, if you write broken code, it won't work. What's your point?
@"Christof Eb." said:
Hi,
I wanted to make a tile driver 8x8 (which I want to include in a version of Taqoz later), which needs 3bytes for two chars sharing one byte for colors - save the space! It is derived from Erics example, many thanks here!
Questions:
1. There are some miracles for me: What for is the NOP in line 109 in the tile driver needed???? It was needed, when I inserted line 108. Thanks for any hints!
I don't know why that NOP would be required. Have you tried moving it around? Does it have to be in just that spot, or anywhere at the beginning? I doubt it's a timing issue (that is initialization code, not time critical) so probably it has something to do with memory alignment. Maybe something in the code that's loaded into LUT needs to be at a particular address in HUB RAM? That shouldn't be the case, but maybe there's a bug.
The method to move the NOP was successful -thank you-, and yes it was my bug, a # too much.
mov bgcolor,color_palette is needed instead of mov bgcolor,#color_palette . I suppose, that the fancy "color" triggers false sync impulses....
I lost several hours debugging non working Spin code to find a tab instead of spaces. New Flexprop warns about this.
Today I use Spin only to write low level drivers, as I can use them not only in Flexprop environment. All high level/user interface stuff=Basic.
Comments
Yah, I modified every object from the Obex I used on my only Prop1 project but still it was a nice way to get going quickly.
You can certainly use Spin1 objects from Spin2 code with FlexProp (for that matter you can use C or BASIC files as objects, too). You might sometimes have to explicitly give the file extension, like:
although if there's no possibility for conflict (no .spin2 version of the file) I think the compiler can find it just as "FullDuplexSerial".
I've released version 6.8.0 of FlexProp on both github and my Patreon page (see my signature for links). The changes in this version of the compiler include:
Version 6.8.0 - Added support for `%"xyzw"` constants in Spin2 - Added locking for host file system I/O - Added `--compress` flag to compress binaries (courtesy of Ada) - Fixed incorrect inline assembly for `#outb` and other hw registers - Made `@foo.bar` work when `bar` is a label - Supported PNut v43 `{Spin2_vNN}` version commentsneed to bring this back to the top
FlexProp 6.9.1 is available from Patreon and from github (see my signature for links). This is mainly a bug fix release. The main improvement over 6.8.x (besides the many bug fixes) is an optimization to remove identical functions. This can be useful for small access functions, because often the generated code ends up being the same even though the objects involved are superficially different.
Hi Eric,
Just picked-up on a typo in the Basic manual.
Cheers.
Craig
A quickie re: the IDE.
I can change the editor font and it sticks but the compiler-output font resets to the original, each time I fire-up the IDE.
Craig
@Mickster : Thanks for catching these!
Arrg! Flexprop 6.9.1 totally messes up my EtherCat test program. I can't say what is actually causing it but it looks like the memory layout is messed up. I get garbled logfile output and sometimes printf hangs. Eric, have you changed anything of the alignment of struct member variables?
6.6.1 ran fine, 6.8.0 had the bool initializer problem but still compiled and ran without problems. 6.9.1 doesn't work at all. Unfortunatelly, I don't have much time this weekend. And this will definitely take some time to debug. The code is big and uses a lot of pointers, structures, buffers and dynamic memory allocation. So it's not unlikely that it's caused by my own mistakes that just different outcomes as memory layout changed...
Bool got changed back to being 1 byte (was 4 bytes for a while)
@ManAtWork : if your structs have any "bool" members then you should probably change them to "uint8_t" (or "uint32_t" if you wanted them to be 32 bits). The size of bool has changed between different compiler versions.
@ersmith After a bit of an extended absence, I'm back playing. It appears FlexBASIC V6.9.1 has issues with SETTIME. See the example below:
settime "2023-12-25 01:30:15" print "Date is: ";date$() print "Time is: ";time$()When compiled this code yields:
Is this a "Jeff Problem" or is SETTIME misbehaving?
It turned out that it has nothing to do with bool. I already use uint8_t in all structs that need a specific layout and size because they are sent over the network.
I did some shotgun debugguing and deleted or commented out all irrelevant code until I got a minimal skeleton that still reproduces the problem. It runs only in a single cog and doesn't call any hardware-dependant drivers so it should run on a plain KISS board or any other P2 board if the _xtlfreq is adjusted. It basically calls
Print3()in debuglog.c and thenDumpBuffer(). If I use compiler V6.8.0 or if I comment out thestatic EC_TaskDescr taskBuffer[EC_MaxNumTasks];it runs correctly and prints outBut if I use compiler 6.9.1 and don't comment out the taskBuffer declaration it crashes just at the printf() at line 201 of debuglog.c. It looks a bit like a stack overflow inside printf() but that shouldn't happen as it runs in cog0 and the main stack. I also verified that the log buffer and the format string for printf() are not overwritten. Their addresses and hex dumps look reasonable. As debuglog.c is tested quite well and works without any problems with hundreds of calls to Print0..Print5() when using compiler V6.8.0 I don't finds any obvious bugs.
@JRoark : somehow reading data from strings got messed up in 6.9 (so it's not your bug, it's mine). That'll be fixed in the next release.
@ManAtWork : the problem is in bool, I forgot to update the alignment requirement when I updated the size of bool, so if any structs use
boolthen memory near them can be corrupted. That's fixed in the next release, or you can work around it for now by changing allbooltouint8_t.Thank you both for the bug reports.
Thanks, Eric, that's a great relief. Sometimes, I begin to doubt my sanity.
That's funny....with this EtherCAT stuff, I frequently doubt your sanity
Craig
Hi,
I wanted to make a tile driver 8x8 (which I want to include in a version of Taqoz later), which needs 3bytes for two chars sharing one byte for colors - save the space! It is derived from Erics example, many thanks here!
Questions:
1. There are some miracles for me: What for is the NOP in line 109 in the tile driver needed???? It was needed, when I inserted line 108. Thanks for any hints!
2. Are there other 8x8 fonts available in this format? Especially I would like a font with subtiles like CPC6128. I mean the first row after the ascii chars.
Christof
I don't know why that NOP would be required. Have you tried moving it around? Does it have to be in just that spot, or anywhere at the beginning? I doubt it's a timing issue (that is initialization code, not time critical) so probably it has something to do with memory alignment. Maybe something in the code that's loaded into LUT needs to be at a particular address in HUB RAM? That shouldn't be the case, but maybe there's a bug.
There's a tool for converting X window .bdf fonts into .bin files: it's called "makebitmap" and you can find it in the repository at https://github.com/totalspectrum/p2_vga_text, which is a more complete (and possibly more recent) version of the demo that's included with FlexProp. With makebitmap you can include a map file to specify which Unicode characters should be taken from the font and put at which position in the P2 font file.
I get a bunch of compile warnings that you should probably be fixing:
Looks like there is lingering imprecise addresses supplied to a FIT directive and a SETQ2. I'd fix LINE_HANDLER_END's use with
setq2 #(LINE_HANDLER_END-LINE_HANDLER)andfit LINE_HANDLER_END+1. Then for tidiness, makeFIELD_HANDLER_END = $39fand the matchingsetq2 #(FIELD_HANDLER_END-FIELD_HANDLER)andfit FIELD_HANDLER_END+1.That's my quick look done. Unlikely I've found anything that's a bug though.
Thanks for having a look into this! As my 3/2driver cannot have 256 colors but only Background+8+Inverse or Background+16, I should be able to shorten the color table very much. This will free up space for the routines sitting now in lut. And I don't need dynamic loading of these routines. So the plan is to simplify and bring the routines "back" into cog. The assembler of Taqoz is made for short routines and I was now busy to bring in the possibility for forward jumps and calls. Let's see, if I will come to understand this NOP thingy in the process....
Thank you for the answer!
Christof
Well, yes, I try to avoid SPIN2. It is just .... that Parallax customers are forced to learn this superfluous special language, that uses non visible indentation as critical element of the language.....
Edit: Propellertool solves the none-visibility problem though.
What do you have against semantically-meaningful whitespace? It forces you to correctly indent your code.
FYI, most decent editors can be configured to subtly shows low-contrast dots or dashes where spaces or tabs are, so you can see them when you want to without it being distracting. This is sometimes its own feature (e.g. VS Code, Sublime Text), or just the old-fashioned list mode toned-down to be less obnoxious (e.g.
vim).Might be mis-remembering, here because I haven't touched SPIN since 2011 but I seem to remember forgetting to indent and the interpreter didn't know any better. Program simply didn't work.
DO/LOOP (Basic) needs to be intact or the interpreter/compiler picks up on it.
Craig
The interpreter can't read your mind about missing whitespace, the same way it can't read your mind about missing curly braces. In any language, if you write broken code, it won't work. What's your point?
Interpreter: "Run-time Error: DO without LOOP"
Compiler: "Compile Error: DO without LOOP"
The method to move the NOP was successful -thank you-, and yes it was my bug, a # too much.
mov bgcolor,color_palette is needed instead of mov bgcolor,#color_palette . I suppose, that the fancy "color" triggers false sync impulses....
I lost several hours debugging non working Spin code to find a tab instead of spaces. New Flexprop warns about this.
Today I use Spin only to write low level drivers, as I can use them not only in Flexprop environment. All high level/user interface stuff=Basic.
Think the FlexProp VGA demo can also work at 720p, see attached.
Doesn't like 1080p though...