The error goes away if the empty parens are dropped from the getVersion method. Unfortunately, PNut requires that () must be there.
There is no complaint if the non-array usb1.getVersion() syntax is used.
Tested with fastspin 4.3.1 and b4.3.1-14.
Not sure what's going on with the SD card timing. The low-level code for driving the card is in include/filesys/fatfs/sdmm.cc, but I pretty much just took that from the default bit-banging example that came with FatFs.
Yes, I saw that. Title of code is "Foolproof MMCv3/SDv1/SDv2 (in SPI mode) control module".
Well, apparently you can fool it with certain cards (hopefully a very small subset) when pins are shared with flash and/or boot code...
Ok, I tested out the codes above. But, I still have the same issue with my SDHC card...
uSD mounts the first time I run it, but won't mount the second time, unless I physically remove the card and stick it back in.
I think this must have something to do with the way these pins are shared with flash and also used for booting.
No problem with my regular 2 GB SD card (non- SDHC).
I used to have more cards for testing around...
I'll have to try out @Cluso99 code and see if it does any better.
BTW: Your code seems to create an empty hello.txt file if none exists. Is that what you intended? I think there are some flags if FatFs to prevent this...
The problem with DO causes the Flash to fail, not the SD card. To be specific, SD fails to release (ie not drive) the DO pin which causes problems with anything attached to the DO pin. But it does not cause any problem with the SD card itself.
However, if you have other things attached to the SD pins, then this can affect the loading on those pins, and could be the cause of a timing issue. I was very careful with timing issues in the ROM code (and other code) to ensure that the inherent pin delays within the P2 did not cause any problems. I've posted timing diagrams previously.
@Cluso99 I just tried this card with your CPM code and it shows the same behavior... Works the first time you load, but you have to physically remove the card to get it to work a second time...
To allow easy switch between the Eval board and my custom boards, I created a file called "PropPins.h" that I guess I'll include in source files that needs to use Prop pins... Is there a better way?
For the FatFS program I then have this, with the attached included.
I do something similar in spin (a child object though, rather than an include). It'll have clock setup (in the rare case of a board design out in the wild that has something other than a 5MHz xtal), SD pins, LED pins, etc
Yeah, I like the pins-in-child-object style. (Usually I call it platform.spin...) The main upside is that it works in compilers without a preprocessor, but the downside is that you can't do conditional compilation based on it (like linking different objects for different input devices or smth like that)
With fastspin, child objects also have the advantage of being cross-language compatible...
For the big game™, I've actually written a very overkill system where the build script generates a platform.spin from a target definition (where the common definitions for related targets (such as VGA vs. TV builds for the same board) can be grouped). Looks a bit like this:
...and ends up generating a spin file like this: (as you can see, not all settings are reflected here; some are given as preproccessor defines on the command line ("-D TVTYPE_TV -D AUDIOTYPE_STEREO -D HAVE_SVIDEO" for this example, if you care). Some settings also weren't given and thus defaulted (notably, the clock settings))
It generates one of these for every defined target in its build directory (which is included as a library dir when compiling spin code). Again, very overkill if you don't already have a very complex build script (which I had, so adding this functionality was trivial)
Anyone know how to change the heap size from its default of 4kB in Fastspin C?
Included documentation below only mentions the HEAPSIZE constant in a top level object file, and I am running a single C file, no Spin2 objects, at least not directly. In any case I've tried adding this to my C file:
#define HEAPSIZE 100000
and also this
const HEAPSIZE=100000;
however neither seems to help. What else would I need to do to increase the default heap size?
Documentation only has this:
## Memory Management
There are some built in functions for doing memory allocation. These are intended for C or BASIC, but may be used by Spin programs as well.
### Heap allocation
The main function is `_gc_alloc_managed(siz)`, which allocates `siz` bytes of memory managed by the garbage collector. It returns 0 if not enough memory is avilable, otherwise returns a pointer to the start of the memory (like C's `malloc`). As long as there is some reference in COG or HUB memory to the pointer which got returned, the memory will be considered "in use". If there is no more such reference then the garbage collector will feel free to reclaim it. There's also `_gc_alloc(siz)` which is similar but marks the memory so it will never be reclaimed, and `_gc_free(ptr)` which explicitly frees a pointer previously allocated by `_gc_alloc` or `_gc_alloc_managed`.
The size of the heap is determined by a constant `HEAPSIZE` declared in the top level object. If none is given then a (small) default value is used.
Example:
```
' put this CON in the top level object to specify how much memory should be provided for
' memory allocation (the "heap"). The default is 4K on P2, 256 bytes on P1
CON
HEAPSIZE = 32768 ' or however much memory you want to provide for the allocator
' here's a function to allocate memory
' "siz" is the size in bytes
PUB allocmem(size) : ptr
ptr := _gc_alloc_managed(size)
```
Anyone know how to change the heap size from its default of 4kB in Fastspin C?
Included documentation below only mentions the HEAPSIZE constant in a top level object file, and I am running a single C file, no Spin2 objects, at least not directly. In any case I've tried adding this to my C file:
#define HEAPSIZE 100000
and also this
const HEAPSIZE=100000;
Try:
enum { heapsize=100000 };
I'd like to get either the #define or const form to work too, but for technical reasons these are hard for the compiler to recognize . Also note that in C the constant must be lower case. That'll be fixed in github soon so that either all upper or all lower will work.
I was wondering about heapsize too ...
Thanks. Looked all over but couldn’t find anything...
How do you manage garbage collection in FlexC?
If malloc() is unable to allocate memory, then garbage collection is triggered and any managed pointers previously allocated but no longer referenced are freed. Then the malloc() is re-tried.
By default memory returned by malloc() is *not* managed, so in ordinary C code the garbage collection will do nothing. However, you can explicitly mark a pointer returned by malloc() as manged by calling _gc_manage(ptr). Or, you can allocate the memory as managed from the start by using _gc_alloc_managed(n) instead of malloc(n). In both of those cases the pointers may be freed by garbage collection if no references to them are found (there are no 32 bit values in the heap or stack that point to the start of the blocks).
Thanks Eric that worked. One thing I found is that the resulting binary size using the heap method is still large. I was hoping if I was to allocate a large frame buffer structure on the heap instead of statically via an array it would not contribute to the binary image size, but it still seems to. I guess you need to include this heap space in the binary for some reason (to guarantee it will be available?).
Thanks Eric that worked. One thing I found is that the resulting binary size using the heap method is still large. I was hoping if I was to allocate a large frame buffer structure on the heap instead of statically via an array it would not contribute to the binary image size, but it still seems to.
Yes, the current implementation just allocates a static array which is part of the binary image. Eventually I'd like to remove this, but it's not a big priority: it won't change the memory footprint, just the disk storage footprint.
I started looking at the warning list and fixing those up...
Noticed that I redefined the same int several times...
Shouldn't that be error? In Visual C++ that gives an error...
It depends on exactly what you're defining. It could be a bug in fastspin, but it could also just be hitting parts of the standard that are compiler dependent. You can always use -Werror to turn those warnings into errors.
Visual Studio is telling me that defines like this:
#define pin_sd_miso 44
Should be changed to constant expressions. But, that doesn't seem to work...
Is that possible in FastSpin?
a) constexpr is a C++ feature (roughly equivalent to CON in spin (unlike const, which does not guarantee compile-time evaluation)). I don't think fastspin supports it, but constexpr variables should(tm) be trivial for Eric to add. (as opposed to constexpr functions)
b) WTF Visual Studio? Why is it doing code style suggestions like that by default?
c) You should definitely change it to
Visual Studio is telling me that defines like this:
#define pin_sd_miso 44
Should be changed to constant expressions. But, that doesn't seem to work...
Is that possible in FastSpin?
No, as @Wuerfel_21 said that's a C++ only feature and not implemented in fastspin. Anyway, Visual Studio's suggestion is rather dubious, so I wouldn't worry about that.
You'd think this is way too fast, but it works...
Also, this should be linked to the clock speed, but this is with the clock at 300 MHz
Might have to get the scope to see how fast it's actually going at...
Actually, I can tell by the assembly that this is going to be <15 MHz at 300 MHz clock.
Also, assembly looks very similar to fsrw for P2 where there's a note that that pause() delay can be as low as 14 with 320 MHz clock.
It's probably expecting braces around every group of 64 values. If you specify -Wall with GCC it generates a warning about this. Try the attached file.
Comments
Thanks, Garry. I'll look into it.
Yes, I saw that. Title of code is "Foolproof MMCv3/SDv1/SDv2 (in SPI mode) control module".
Well, apparently you can fool it with certain cards (hopefully a very small subset) when pins are shared with flash and/or boot code...
However, if you have other things attached to the SD pins, then this can affect the loading on those pins, and could be the cause of a timing issue. I was very careful with timing issues in the ROM code (and other code) to ensure that the inherent pin delays within the P2 did not cause any problems. I've posted timing diagrams previously.
For the FatFS program I then have this, with the attached included.
With fastspin, child objects also have the advantage of being cross-language compatible...
For the big game™, I've actually written a very overkill system where the build script generates a platform.spin from a target definition (where the common definitions for related targets (such as VGA vs. TV builds for the same board) can be grouped). Looks a bit like this:
VENTILATOR_COMMON = { audiotype: :stereo, input: 'in_ps2_snes', player2:true, pins: { # SPI pins SPI_MISO: 21, #DO SPI_CLK: 24, SPI_MOSI: 20, #DI SD_CS: 25, RAM_CS: 26, # Video pins TVPINS: 0b001_0101, VGAPINS: 0b10_00001_10_00000_000000_000_0_11111100, # Audio pins AUDIO_LEFT: 11, AUDIO_RIGHT: 10, # Input pins PS2_DATA: 8, PS2_CLOCK: 9, SNES_CLOCK: 16, SNES_LATCH: 17, SNES_PLAYER1: 19, SNES_PLAYER2: 18, }, }.freeze target_p1("ventilator-debug",debug: true, **VENTILATOR_COMMON, tvtype: :tv, svideo: true, ) target_p1("ventilator-vga-debug",debug: true, **VENTILATOR_COMMON, tvtype: :rgb64, )...and ends up generating a spin file like this: (as you can see, not all settings are reflected here; some are given as preproccessor defines on the command line ("-D TVTYPE_TV -D AUDIOTYPE_STEREO -D HAVE_SVIDEO" for this example, if you care). Some settings also weren't given and thus defaulted (notably, the clock settings)) It generates one of these for every defined target in its build directory (which is included as a library dir when compiling spin code). Again, very overkill if you don't already have a very complex build script (which I had, so adding this functionality was trivial)
Included documentation below only mentions the HEAPSIZE constant in a top level object file, and I am running a single C file, no Spin2 objects, at least not directly. In any case I've tried adding this to my C file:
and also this
however neither seems to help. What else would I need to do to increase the default heap size?
Documentation only has this:
EXFAT seems to require 64 bit integers, so that's not going to happen for a while.
Try:
enum { heapsize=100000 };I'd like to get either the #define or const form to work too, but for technical reasons these are hard for the compiler to recognizeThanks. Looked all over but couldn’t find anything...
How do you manage garbage collection in FlexC?
If malloc() is unable to allocate memory, then garbage collection is triggered and any managed pointers previously allocated but no longer referenced are freed. Then the malloc() is re-tried.
By default memory returned by malloc() is *not* managed, so in ordinary C code the garbage collection will do nothing. However, you can explicitly mark a pointer returned by malloc() as manged by calling _gc_manage(ptr). Or, you can allocate the memory as managed from the start by using _gc_alloc_managed(n) instead of malloc(n). In both of those cases the pointers may be freed by garbage collection if no references to them are found (there are no 32 bit values in the heap or stack that point to the start of the blocks).
Thanks Eric that worked.
Noticed that I redefined the same int several times...
Shouldn't that be error? In Visual C++ that gives an error...
I think you need: #include <stdbool.h>
Yes, the current implementation just allocates a static array which is part of the binary image. Eventually I'd like to remove this, but it's not a big priority: it won't change the memory footprint, just the disk storage footprint.
It depends on exactly what you're defining. It could be a bug in fastspin, but it could also just be hitting parts of the standard that are compiler dependent. You can always use -Werror to turn those warnings into errors.
int pr = f_puts("First string in my file. What great text for a file!\n", &Fil);So, pr was being defined 3 times in the same function.
Seemed to work fine anyway, but should probably be an error...
Visual Studio is telling me that defines like this:
Should be changed to constant expressions. But, that doesn't seem to work...
Is that possible in FastSpin?
a) constexpr is a C++ feature (roughly equivalent to CON in spin (unlike const, which does not guarantee compile-time evaluation)). I don't think fastspin supports it, but constexpr variables should(tm) be trivial for Eric to add. (as opposed to constexpr functions)
b) WTF Visual Studio? Why is it doing code style suggestions like that by default?
c) You should definitely change it to to avoid weird syntax issues
No, as @Wuerfel_21 said that's a C++ only feature and not implemented in fastspin. Anyway, Visual Studio's suggestion is rather dubious, so I wouldn't worry about that.
Surprisingly, I was able to change the delay to make it work:
You'd think this is way too fast, but it works...
Also, this should be linked to the clock speed, but this is with the clock at 300 MHz
Might have to get the scope to see how fast it's actually going at...
Actually, I can tell by the assembly that this is going to be <15 MHz at 300 MHz clock.
Also, assembly looks very similar to fsrw for P2 where there's a note that that pause() delay can be as low as 14 with 320 MHz clock.
Never mind, I googled it and found // is still a comment in this case. Heh, last time I looked up any C language, Google didn't even exist.
It seems to choke on initializing the 2D int array in the attached...
Gives this error: >fft.c:3: error: wrong kind of initializer for array type
Should one be able to declare a 2D array like this:
int fft[64][64]={ +8192, +8192, ... (lots of more integers here)