Seems it's been a year since I touched this and back then, I did a hack to make the code work with both PropTool and FlexProp.
But, seems this fix didn't propagate to all my setups...
PUB Read8(Dpin, Cpin): Value|Dpin2, CPin2, pValue 'read 8 bits
'Note: 24Dec22: Had to adapt code to work with both FlexProp and PropTool.
' FlexProp puts Value before Dpin in memory, but PropTool leaves Value after Cpin
pValue:=Value:=@Value 'This way, the third variable will have @Value in both FlexProp and PropTool
Dpin2:=Dpin
Cpin2:=Cpin
SendCommand(Read8_,@Dpin2)
'wait for this command to finish
repeat
until command==0
return Value
@Rayman said:
Actually, seems like the hack still works, just didn't implement everywhere, what a mess...
This is what Git is for... Whatever investment of time it may cost to learn is well worth always knowing exactly how all the copies on each of your computers differ from what you expect.
@Rayman said:
I'm a bit surprised that the compiler doesn't give a warning when initializing a static structure with index beyond what is declared...
That's fairly common for C compilers (C actually lets you index wherever you want in an array, and it's up to you to make sure it's within bounds). That said, I will add a warning for this case (it'll be useful for BASIC, where you really shouldn't be trying to reference an array out of bounds).
I'm not convinced about the warning for C. I've often implemented variable-sized arrays by having a structure with a length field and an array of size 1. Then I dynamically allocate enough memory to hold as many elements as I need and use the length field in the structure to bounds check an index at runtime. Something like this: typedef struct { int length; int data[1]; } DynamicIntArray;
I would make the array zero length but that is usually not allowed by C compilers. Anyway, I would hate to get a warning every time I use this technique. I try to make sure my code compiles without any warnings and it's not clear how I would get around this one.
On another note, how many people here are using C on the P2? From looking at the posts it seems most people are using Spin, PASM, or Basic.
@"David Betz" said:
I would make the array zero length but that is usually not allowed by C compilers.
The correct way is to actually leave the size field empty, like int data[]. The funny name for this is "flexible array member" and it's part of C99. I am not sure of flexC actually takes it.
@"David Betz" said:
I would make the array zero length but that is usually not allowed by C compilers.
The correct way is to actually leave the size field empty, like int data[]. The funny name for this is "flexible array member" and it's part of C99. I am not sure of flexC actually takes it.
I don’t think the version of C I was using at the time supported that. I mostly use C++ these days.
@"David Betz" said:
On another note, how many people here are using C on the P2? From looking at the posts it seems most people are using Spin, PASM, or Basic.
I both prefer and use C myself. But since Flexspin has not problem integrating multiple languages in one build, I make many shareable utility functions in Spin2 so that they can be used with PNut as well.
@"David Betz" said:
On another note, how many people here are using C on the P2? From looking at the posts it seems most people are using Spin, PASM, or Basic.
I both prefer and use C myself. But since Flexspin has not problem integrating multiple languages in one build, I make many shareable utility functions in Spin2 so that they can be used with PNut as well.
It is very useful that FlexSpin allows code from multiple languages to be linked together into a single program. Eric has given us an invaluable tool.
It is very useful that FlexSpin allows code from multiple languages to be linked together into a single program. Eric has given us an invaluable tool.
There is a lot of C code here and there. The example: while my player is written in Basic, the mp3 decoder is in C, as there was the Adafruit mp3 decoder and then several Eric's updates allowed it to run on P2 without need to rewrite several thousands lines of code to Spin or anything else.
I've made the warnings about array indices out of range be controlled by a flag (-Warray-index) which is on by default, but like all warnings may be disabled either globally on the command line or on a per-function basis via function attributes. Also, the warning does not happen if the array index is not an explicit constant, so something like:
i=2; p->arr[i] = 0;
will never generate a warning, even if the array is only declared with one element.
I'm not able to reproduce this at all. When you say "the latest git repo" do you mean that you built from source, or that you downloaded the latest binary release? What does the loadp2 command line look like (it's printed in the Compiler Output pane at the bottom of the window). Does it happen with all programs you try to run, or just some of them? If you use the Commands > Configure Commands... menu item to switch back to P2 defaults, does it still happen?
I deleted ~/flexprop.config.2 and restarted the app and works now. I had reset the default settings and it still continued to give that error. but after removing the config file it seems ok.
Loading it into cog or lut won't help with that one. The REP issue is because the optimizer can't see the loop properly when you manually write it out like that. When it generates REPs itself, it inserts a dummy instruction at the bottom so it can work with it.
I'm happy with those directives. Nearly all my Pasm is timing crafted. Though I did use SETQ+QDIV for quick 64-bit division the other day. I left that as a plain __asm {} for the optimiser to handle as it saw fit. It was tacked on after a tight loop that used two 32-bit registers to accumulate many samples into 64-bits.
@Rayman said:
Resurrecting some old C code with inline assembly...
Seems asm{} blocks used to need an "end" at the end, but now gives error:
i2c.h:250: error: conditional assembly endif without if
I don't think end was ever needed in C asm blocks (they are delimited with { and }). I guess that end was tolerated and/or ignored in such blocks at one time, but it is used now as the marker for the end of conditional assembly, so that's no longer possible.
Also, not sure if I can ignore this or not:
i2c.h:230: warning: REP in inline assembly may interfere with optimization
It depends on what you're trying to do. In general it's probably better to write the loops in C with the inline assembly inside the loop: the less inline assembly, the better. If you need exact timing for something, you should mark the code as asm const to tell the optimizer to leave it alone.
Also, not sure if I can ignore this or not:
i2c.h:230: warning: REP in inline assembly may interfere with optimization
@Rayman Can you tell me what I2C library you're using? I'm currently trying to get an INA219 IMU sensor to work with Arduino code, and getting I2C to work has been much harder than I thought it would be.
It looks like that aligning code is not working at least since version 6.0.x. Tried 6.0.5 to actual version.
The words alignl and alignw are treated as a symbol instead of a keyword. This comes only to your attention if one used these instructions multiple times in the same file. Then you get the following error message from second occurrence on.
It looks like that aligning code is not working at least since version 6.0.x. Tried 6.0.5 to actual version.
The words alignl and alignw are treated as a symbol instead of a keyword. This comes only to your attention if one used these instructions multiple times in the same file. Then you get the following error message from second occurrence on.
Changing hub value for symbol alignl
At least the last working version I use is 5.0.4.
alignl is a Spin2 keyword and is not recognized in Spin1. Make sure the file you're using has a .spin2 extension if you want to use Spin2 features (whether on P1 or P2).
Really old versions of the compiler used to treat both languages almost the same and probably accepted alignl in Spin1 code, but as the Spin2 language developed and diverged from Spin1 this became impossible, and so the compiler is stricter now about the file extension.
@ersmith said: alignl is a Spin2 keyword and is not recognized in Spin1. Make sure the file you're using has a .spin2 extension if you want to use Spin2 features (whether on P1 or P2).
Thanks, you are right with .spin2 extension. But I wondering why this problem occurs if one use the -2 option on flexspin. I would expect that it compiles using P2 specification regardless of the file extension.
@ersmith said: alignl is a Spin2 keyword and is not recognized in Spin1. Make sure the file you're using has a .spin2 extension if you want to use Spin2 features (whether on P1 or P2).
Thanks, you are right with .spin2 extension. But I wondering why this problem occurs if one use the -2 option on flexspin. I would expect that it compiles using P2 specification regardless of the file extension.
Spin1 and Spin2 are different (but related) languages, much like C and C++. From FlexProp's perspective this has nothing to do with which processor you are compiling for. You can use FlexProp to compile Spin1 for P2 or Spin2 for P1 (as long as the programs do not use any hardware specific features, of course).
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....
Comments
Think I found the problem using WinDiff...
Seems it's been a year since I touched this and back then, I did a hack to make the code work with both PropTool and FlexProp.
But, seems this fix didn't propagate to all my setups...
Seems the above hack no longer works...
Fixed for the moment like this:
PUB Read8(Dpin, Cpin): Value|Dpin2, CPin2, pValue 'read 8 bits 'Note: 24Dec22: Had to adapt code to work with both FlexProp and PropTool. ' FlexProp puts Value before Dpin in memory, but PropTool leaves Value after Cpin pValue:=Value:=@Value 'This way, the third variable will have @Value in both FlexProp and PropTool Dpin2:=Dpin Cpin2:=Cpin SendCommand(Read8_,@Dpin2) 'wait for this command to finish repeat until command==0 return ValueActually, seems like the hack still works, just didn't implement everywhere, what a mess...
This is what Git is for... Whatever investment of time it may cost to learn is well worth always knowing exactly how all the copies on each of your computers differ from what you expect.
It is actually there: https://github.com/GitRayman/Antares/blob/main/SPI.spin2
Looks like didn't check in the fix though...
I'm not convinced about the warning for C. I've often implemented variable-sized arrays by having a structure with a length field and an array of size 1. Then I dynamically allocate enough memory to hold as many elements as I need and use the length field in the structure to bounds check an index at runtime. Something like this:
typedef struct { int length; int data[1]; } DynamicIntArray;I would make the array zero length but that is usually not allowed by C compilers. Anyway, I would hate to get a warning every time I use this technique. I try to make sure my code compiles without any warnings and it's not clear how I would get around this one.
On another note, how many people here are using C on the P2? From looking at the posts it seems most people are using Spin, PASM, or Basic.
The correct way is to actually leave the size field empty, like
int data[]. The funny name for this is "flexible array member" and it's part of C99. I am not sure of flexC actually takes it.I don’t think the version of C I was using at the time supported that. I mostly use C++ these days.
I both prefer and use C myself. But since Flexspin has not problem integrating multiple languages in one build, I make many shareable utility functions in Spin2 so that they can be used with PNut as well.
It is very useful that FlexSpin allows code from multiple languages to be linked together into a single program. Eric has given us an invaluable tool.
There is a lot of C code here and there. The example: while my player is written in Basic, the mp3 decoder is in C, as there was the Adafruit mp3 decoder and then several Eric's updates allowed it to run on P2 without need to rewrite several thousands lines of code to Spin or anything else.
I've made the warnings about array indices out of range be controlled by a flag (-Warray-index) which is on by default, but like all warnings may be disabled either globally on the command line or on a per-function basis via function attributes. Also, the warning does not happen if the array index is not an explicit constant, so something like:
will never generate a warning, even if the array is only declared with one element.
@ersmith
Just grabbed the latest git repo and I get
too many files specified on command line
This is using Compile & Run on a mac.
This is happening on the loadp2 command
I'm not able to reproduce this at all. When you say "the latest git repo" do you mean that you built from source, or that you downloaded the latest binary release? What does the loadp2 command line look like (it's printed in the
Compiler Outputpane at the bottom of the window). Does it happen with all programs you try to run, or just some of them? If you use the Commands > Configure Commands... menu item to switch back to P2 defaults, does it still happen?I deleted ~/flexprop.config.2 and restarted the app and works now. I had reset the default settings and it still continued to give that error. but after removing the config file it seems ok.
Resurrecting some old C code with inline assembly...
Seems asm{} blocks used to need an "end" at the end, but now gives error:
i2c.h:250: error: conditional assembly endif without if
Also, not sure if I can ignore this or not:
i2c.h:230: warning: REP in inline assembly may interfere with optimization
Multiple solutions for that:
constorvolatilemodifier. eg:__asm const { // non-optimised, inlined nop }__asm volatile { // non-optimised, Fcached nop }__attribute__((cog))or__attribute__((lut))modifier. eg:void funcname( void ) __attribute__((cog)) { __asm { nop } }PS: Be aware that setting the function to cogexec permanently loads that function into the cog. Thereby reducing free cog space.
Loading it into cog or lut won't help with that one. The REP issue is because the optimizer can't see the loop properly when you manually write it out like that. When it generates REPs itself, it inserts a dummy instruction at the bottom so it can work with it.
Huh, I thought I'd already tested that. Must of had them combined at the time.
You can of course write a normal DJNZ loop and have the optimizer convert it to REP.
I'm happy with those directives. Nearly all my Pasm is timing crafted. Though I did use SETQ+QDIV for quick 64-bit division the other day. I left that as a plain
__asm {}for the optimiser to handle as it saw fit. It was tacked on after a tight loop that used two 32-bit registers to accumulate many samples into 64-bits.I don't think
endwas ever needed in C asm blocks (they are delimited with{and}). I guess thatendwas tolerated and/or ignored in such blocks at one time, but it is used now as the marker for the end of conditional assembly, so that's no longer possible.It depends on what you're trying to do. In general it's probably better to write the loops in C with the inline assembly inside the loop: the less inline assembly, the better. If you need exact timing for something, you should mark the code as
asm constto tell the optimizer to leave it alone.>
@Rayman Can you tell me what I2C library you're using? I'm currently trying to get an INA219 IMU sensor to work with Arduino code, and getting I2C to work has been much harder than I thought it would be.
I think this is the latest (attached).
If you want to automatically generate code to use an earlier version you can try P2C:
https://forums.parallax.com/discussion/173312/
This does remind me that I want to, one day, create a "Wire" named version that can be a P2 drop in for Arduino code...
Thanks @Rayman
@ersmith
It looks like that aligning code is not working at least since version 6.0.x. Tried 6.0.5 to actual version.
The words alignl and alignw are treated as a symbol instead of a keyword. This comes only to your attention if one used these instructions multiple times in the same file. Then you get the following error message from second occurrence on.
Changing hub value for symbol alignlAt least the last working version I use is 5.0.4.
alignlis a Spin2 keyword and is not recognized in Spin1. Make sure the file you're using has a .spin2 extension if you want to use Spin2 features (whether on P1 or P2).Really old versions of the compiler used to treat both languages almost the same and probably accepted
alignlin Spin1 code, but as the Spin2 language developed and diverged from Spin1 this became impossible, and so the compiler is stricter now about the file extension.Thanks, you are right with .spin2 extension. But I wondering why this problem occurs if one use the -2 option on flexspin. I would expect that it compiles using P2 specification regardless of the file extension.
Spin1 and Spin2 are different (but related) languages, much like C and C++. From FlexProp's perspective this has nothing to do with which processor you are compiling for. You can use FlexProp to compile Spin1 for P2 or Spin2 for P1 (as long as the programs do not use any hardware specific features, of course).
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....