This is such a neat feature. It's a shame that it doesn't work right on Google Docs, at least. It would be so nice to be able to embed animations into documentation.
Chip,
Here's the file. It doesn't show the animation on this link, but if you download it (upper right corner button), then the file you download has the animation still.
I tried adding it to a google doc, and it animates when I add it, but if I share the doc, and open that link then it's not animating anymore. So it has the same issue you had.
Could you please upload the same Hub animation .png file you created as a zipped file?
The animated .png Roy Eltham uploaded to google drive doesn't run on my browser either (Firefox), but, when I'd downloaded and saved it locally, at my C: drive, it runs fine, by oppening it with IrfanView.
Also, the Hub animation arrived here (downloaded from forum post) with a lenght of 27kB, while Roy's came with 807 kB, fully featured (including the epilepsy episody trigger ).
P.S. Too soon: now Roy's animation runs fine, by right-clicking at the file I've downloaded from Gdrive, and choosing "open with Firefox". Still no luck with the Hub-one (cause it came with only 27kB, from the forum).
For me
- didn't animate in google drive view (not unenxpected)
- didn't animate in 'windows 10 photos' (default program that opens PNGs)
- did animate when brought into Chrome browser as a file
I don't think it's a browser thing, I think Google Docs is stripping it down to the first image in the animation when it saves. Google Drive is also doing that for it's built in viewer.
I think for Docs it's doing it because it can't print an animation, so it reduces it to a static image.
The browsers all display the animation fine here (and have for years).
I just tried in the latest MS Edge browser, and my animated png plays fine. MS changed Edge over to using chromium rendering pages not long ago, so it makes sense that it works now.
Looking at the wiki article, they do list the newer Edge browser as working. The older one is what doesn't work.
It must be that Google Docs strips it down when it saves it. This format is so memory efficient. It would sure be awesome if Google Docs would preserve the whole thing, but then use just the first frame if somebody wanted to create a PDF.
At one point, I created another animated PNG and it converted the grey title text to white! I did not have transparency turned on. Not sure why it did that. I had to make it dark blue, instead, in order to get it to render properly. This is so typical of modern computing. All kinds of strange problems cropping up, making things not very repeatable. I wish things worked consistently.
Or, just use the right tool for the job. You can login to YouTube under the Parallax name/pw, create a playlist of "P2 Documentation Animations"
and upload them to that location. Then, insert the video into the Google doc in the right place. Added bonus: others will see the animations without being buried in the doc, too.
I've been cleaning up and standardizing the DEBUG displays. Today I added velocity sensitivity to the MIDI display. I attached a GIF at the end of the Spin2 documentation. Soon I will document all this stuff. Just need to do some clean-up first.
I'm seeing some weird behavior with PNut v34z. If this has already been discussed I apologize. I've been reviewing some old SPIN2 code on github, propeller/resources/Accessory Test Code/Pins.spin2. When PNut opens this file it contains two weird characters at the beginning of the file (see attached photo) which it complains about if you try and compile it. Notepad, Wordpad, Word, the github RAW view, Propeller Tool 2.3.0.0 alpha nor the default visual code editor see these characters. Also, PNut is adding extra lines in the code (see attached photo). Where Propeller Tool has an empty line it looks like PNut is adding a space on the line then a second empty line and then a third line with another space.
I wouldn't worry too much about that -- Propeller Tool has a better editing component than PNut. Also, if you want to drive pins high or low, use pinhigh() and pinlow().
Here's one just for grins: In the propeller/resources/Accessory Test Code/Pins.spin2 file PNut v34z complains about the following:
!outa[pin] with the error message 'Expected "="'. This is the SPIN1 method of toggling a pin. I'm pretty sure pint(pin) is the correct SPIN2 replacement. What's interesting is !=outa[pin] passes the parser/compiler(?) test. I'm curious to see what it actually does, I just didn't want to try it on my eval board.
Here's one just for grins: In the propeller/resources/Accessory Test Code/Pins.spin2 file PNut v34z complains about the following:
!outa[pin] with the error message 'Expected "="'. This is the SPIN1 method of toggling a pin. I'm pretty sure pint(pin) is the correct SPIN2 replacement. What's interesting is passes the parser/compiler(?) test. I'm curious to see what it actually does, I just didn't want to try it on my eval board.
!=outa[pin] will invert all the bits in register[$1FA + pin].
I'm seeing some weird behavior with PNut v34z. If this has already been discussed I apologize. I've been reviewing some old SPIN2 code on github, propeller/resources/Accessory Test Code/Pins.spin2. When PNut opens this file it contains two weird characters at the beginning of the file (see attached photo) which it complains about if you try and compile it. Notepad, Wordpad, Word, the github RAW view, Propeller Tool 2.3.0.0 alpha nor the default visual code editor see these characters. Also, PNut is adding extra lines in the code (see attached photo). Where Propeller Tool has an empty line it looks like PNut is adding a space on the line then a second empty line and then a third line with another space.
The code has probably been saved with PropTool with the extended character set being used. Copy and paste into Notepad and delete those two characters and save.
Here's one just for grins: In the propeller/resources/Accessory Test Code/Pins.spin2 file PNut v34z complains about the following:
!outa[pin] with the error message 'Expected "="'. This is the SPIN1 method of toggling a pin. I'm pretty sure pint(pin) is the correct SPIN2 replacement. What's interesting is !=outa[pin] passes the parser/compiler(?) test. I'm curious to see what it actually does, I just didn't want to try it on my eval board.
That code is for RevA eval boards only. The subfolder should be renamed to make that clear.
Perhaps we could ask @"Jeff Martin" to help with that.
Well that explains it. Marking that directory as "Rev A Only" is probably a good idea. I've been trying to establish a logical "Learning Path" for SPIN2. Reading through all the forum traffic is impossible. My preferred method is to study example code, however, a lot of existing code is poorly documented. At a minimum, a date and target (i.e. Rev A/B/C) would be helpful. Thanks.
Note: The getms() feature fell out, and I'm hoping that @cgracey will put it back, even if it means getting rid of @getsec() which isn't as useful.
After playing with flash timing recently which has operations that varies from the milliseconds to hundreds of seconds range I tend to agree. The getct() method will wrap in around 17s @ 250MHz and that already hit me when timing the blocking chip erase. But if I choose getsec() instead, I often see zero seconds when I time things that happen to be short like erasing a single sector that only take 900ms. Milliseconds is a nice in-between value to have that covers lots more bases. I know with only 32 bits it will still wrap in 49 days vs 136 years but this is probably still useful in many cases.
So Chip, Is there going to be an easy way in Spin2 to be able to time things down to the millisecond or will doing that always require some inline assembly? None of the current Spin2 timing APIs currently provide the full 64 bit value. The GETSEC() method could be rather useful for doing this measurement if it only reported in milliseconds either instead of, or as well as seconds perhaps as a second return parameter.
To date I've found the waitus() and waitms() methods are extremely convenient to use rather than scaling everything manually, so it would be great to have the Spin2 API giving us similarly easy timestamping capabilities without resorting to extra inline assembly in lots of places which may not always be 100% compatible in FastSpin (that is my fear).
This may not be compatible with FastSpin (which I don't use), but it does seem to work in standard Spin. My MS_001 constant is configured for 200MHz which I have standardized on.
pub get_ms() : ms | lo, hi
'' Return milliseconds after reset (32 bits).
'' -- system counter is fixed; cannot be changed by user
org
getct hi wc ' get cnt (now)
getct lo
stalli ' stall interrupts to protect cordic operation
setq hi ' divide cnt by ticks/ms
qdiv lo, ##MS_001
getqx ms
allowi ' allow interrupts
end
Comments
Here's the file. It doesn't show the animation on this link, but if you download it (upper right corner button), then the file you download has the animation still.
https://drive.google.com/file/d/1Ec7mUomx2cR-iMH3c80eHX4oZfVk8vUS/view
(note: it's just a few frames flashing back and forth, insert epilepsy warning)
I tried adding it to a google doc, and it animates when I add it, but if I share the doc, and open that link then it's not animating anymore. So it has the same issue you had.
Could you please upload the same Hub animation .png file you created as a zipped file?
The animated .png Roy Eltham uploaded to google drive doesn't run on my browser either (Firefox), but, when I'd downloaded and saved it locally, at my C: drive, it runs fine, by oppening it with IrfanView.
Also, the Hub animation arrived here (downloaded from forum post) with a lenght of 27kB, while Roy's came with 807 kB, fully featured (including the epilepsy episody trigger
P.S. Too soon: now Roy's animation runs fine, by right-clicking at the file I've downloaded from Gdrive, and choosing "open with Firefox". Still no luck with the Hub-one (cause it came with only 27kB, from the forum).
- didn't animate in google drive view (not unenxpected)
- didn't animate in 'windows 10 photos' (default program that opens PNGs)
- did animate when brought into Chrome browser as a file
I think for Docs it's doing it because it can't print an animation, so it reduces it to a static image.
The browsers all display the animation fine here (and have for years).
Are you using MS Edge?
According to : https://en.wikipedia.org/wiki/APNG
neither Edge, nor the deprecated IE provide any support to APNGs. Perhaps (as usual), what MS doesn't understand, it chops out, with a jigsaw...
Looking at the wiki article, they do list the newer Edge browser as working. The older one is what doesn't work.
https://github.com/davidmz/apng-canvas
The linked Github page has some explanations about the mechanism that is used to support apngs, at browsers not natively meant to use them.
Sorry by any confusion.
To be clear: I don't use IE either (due to the same reasonings)...
It must be that Google Docs strips it down when it saves it. This format is so memory efficient. It would sure be awesome if Google Docs would preserve the whole thing, but then use just the first frame if somebody wanted to create a PDF.
At one point, I created another animated PNG and it converted the grey title text to white! I did not have transparency turned on. Not sure why it did that. I had to make it dark blue, instead, in order to get it to render properly. This is so typical of modern computing. All kinds of strange problems cropping up, making things not very repeatable. I wish things worked consistently.
and upload them to that location. Then, insert the video into the Google doc in the right place. Added bonus: others will see the animations without being buried in the doc, too.
Ken Gracey
I found this site:
https://ezgif.com/
They allowed me to set infinite repeat on my GIF animation AND they optimized the file, compressing it by 90%!!!
So, you can make GIF's as small as animated PNGs, after all. Before, GIF was 10x the size as animated PNG.
I was able to insert the optimized GIF into the silicon documentation (page 60) and it works as expected now, with only a 163KB footprint.
This means we can start adding animations to documentation with little overhead.
!outa[pin] with the error message 'Expected "="'. This is the SPIN1 method of toggling a pin. I'm pretty sure pint(pin) is the correct SPIN2 replacement. What's interesting is !=outa[pin] passes the parser/compiler(?) test. I'm curious to see what it actually does, I just didn't want to try it on my eval board.
!=outa[pin] will invert all the bits in register[$1FA + pin].
That code is for RevA eval boards only. The subfolder should be renamed to make that clear.
Perhaps we could ask @"Jeff Martin" to help with that.
Here's the link in question : https://github.com/parallaxinc/propeller/tree/master/resources/Accessory Test Code
-- https://www.nutsvolts.com/magazine/article/an-introduction-to-the-parallax-propeller-2
Note: The getms() feature fell out, and I'm hoping that @cgracey will put it back, even if it means getting rid of @getsec() which isn't as useful.
So Chip, Is there going to be an easy way in Spin2 to be able to time things down to the millisecond or will doing that always require some inline assembly? None of the current Spin2 timing APIs currently provide the full 64 bit value. The GETSEC() method could be rather useful for doing this measurement if it only reported in milliseconds either instead of, or as well as seconds perhaps as a second return parameter.
To date I've found the waitus() and waitms() methods are extremely convenient to use rather than scaling everything manually, so it would be great to have the Spin2 API giving us similarly easy timestamping capabilities without resorting to extra inline assembly in lots of places which may not always be 100% compatible in FastSpin (that is my fear).
pub get_ms() : ms | lo, hi '' Return milliseconds after reset (32 bits). '' -- system counter is fixed; cannot be changed by user org getct hi wc ' get cnt (now) getct lo stalli ' stall interrupts to protect cordic operation setq hi ' divide cnt by ticks/ms qdiv lo, ##MS_001 getqx ms allowi ' allow interrupts endI've got GETMS() back in. Will be in next release.