@"Peter Jakacki", as I PM'd you I am OK with EFM8 (and RTC). I'll develop the USB by myself.
Sounds good, and I know I should bite the bullet with getting some code running on the EFM chip it's just that the overly complicated tools annoy me. I have done a lot of 8051 assembler before and written code for Silabs chips too. I guess I should just write some monitor functions for it anyway.
At the moment I don't see any problem.
I will load the RTC option and heatsink PCB by default on these ones, just let me know if you want the CP2102N loaded in place of the EFM8. The CP2102N will provide USB serial but you will still need to manually reset the P2 via the on-board reset switch when loading code since this chip doesn't have DTR and the RTS pin which goes to P57 is cut for the CP2102N.
I will post the ordering options back on the P2D2 thread shortly.
I'm thinking of ordering some CH340E 2Mbd USB serial chips in MSOP10 for about 37 cents each. Then I can order 5 pcbs from JCLPCB for $2. Let's see, a USB serial converter for under a $1 or just integrate the chip.
FTDI were too greedy so they ended up missing the boat for volume - karma
They have made some dirty moves. The only thing that goes in favor of FTDI is the fact that many Linux distros include readily available drivers for FT devices in their repository. Sadly, not so much for Silicon labs (the exception being the CP2130, that doesn't even need drivers under Linux and works well with libusb).
That was a Linux lifetime ago that you had to install CP2102 drivers manually. I'm running Linux Mint 19.1 and found an old CP2102 device and plugged it in, no problems.
Output from dmesg
[48381.264526] usb 1-2: new full-speed USB device number 10 using xhci_hcd
[48393.027633] usb 1-2: new full-speed USB device number 11 using xhci_hcd
[48393.177373] usb 1-2: New USB device found, idVendor=10c4, idProduct=ea60
[48393.177381] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[48393.177387] usb 1-2: Product: CE-00722 Serial Communications Controller
[48393.177415] usb 1-2: Manufacturer: Silicon Labs
[48393.177419] usb 1-2: SerialNumber: 7201
[48393.915283] usbcore: registered new interface driver cp210x
[48393.915739] usbserial: USB Serial support registered for cp210x
[48393.915995] cp210x 1-2:1.0: cp210x converter detected
[48393.918881] usb 1-2: cp210x converter now attached to ttyUSB0
The Prop was even running an old version of Tachyon 2015!
Propeller .:.:--TACHYON--:.:. Forth V27150621.2330
VER: Propeller .:.:--TACHYON--:.:. Forth V27150621.2330
FREQ: 80MHZ (PLLEN OSCEN XTAL1 PLL16X)
NAMES: $537B...715F for 7,652
CODE: $0924...451F for 15,355
CALLS: 278 vectors free
RAM: 3,676 bytes free
BUILD: FIRMWARE BUILD DATE 654545:466665
BOOTS: 36
BOOT: EXTEND.boot
POLL:
MODULES LOADED:
3E14: VGA.fth VGA text driver 150622-1400
1A81: EXTEND.fth Tachyon Forth Propeller hardware debugger and explorer - 150615-0000
@"Peter Jakacki", as I PM'd you I am OK with EFM8 (and RTC). I'll develop the USB by myself.
Curious what do you have functioning on EFM8UB3 and USB ?
Exactly on EFM8UB3 nothing. But I have my Thunderboard EFM8UB3 (22€) on the way. I am familiar on the 8051 core so I know it will not represent an issue.
The main problem is that I still don't have a P2 in my hands and thus I can't start preparing and develop what I need. I need the EFM8 on the P2D2 and if presently Peter have troubles with that chip I don't want that this delay the P2D2r2/3 delivery ... thus I'll program the EFM8 by myself. I have paid enough attention with Peter that things such i2c was connected in the way that can sweet also my needs and anyway, even if Peter comes out with his firmware I will most probably develop mine to better adapt to my project/idea.
@Peter, your work is impressive !!
But let me ask to you two things, and forgive my ignorance please.
How fast are you reading data from SD card ?
Where are you buffering the data to show those videos ?
@Peter, your work is impressive !!
But let me ask to you two things, and forgive my ignorance please.
How fast are you reading data from SD card ?
Where are you buffering the data to show those videos ?
Welcome back Alberto, long time no Prop!
The data is read from the SD card at about 1/10 of the clock speed so up to 3MB/s in multi-block mode. Each frame is read into a small buffer first and when the display is synched it will set the new 8-bit palette and then load the framebuffer in reverse due to each frame being a bmp where the image is vertically flipped. Since each frame is 320x240 it only needs 80k for the buffer and there is a routine to double up the pixels and lines for 640x480.
There is a glitch at present with synchronizing the reading of a sound block which should really only occur at the start of a frame synch wait otherwise the frame update will come late and glitch the display.
I remember you developed extra hardware for the P1 so that you could output higher resolution images than the P1 could manage. As you can see the P2 can do that very easily.
This is the one-liner that reads in a new frame into the bmp buffer in multi-block mode.
Peter,
I gather you are using 300 MHz by default these days. No unexplained glitches or crashes reoccurring at all?
Funny thing happened on my way to the forum .... I had trouble with running my P2D2 over 160MHz or so although it worked fine otherwise. So I cooled the module in the freezer and tried again. Nada.
This is not right I thought and then I decided to check my bake recipe for the module, I wasn't using the one for the R2 version with 25MHz clock! That was easily fixed and P2D2 is once again happy to be running at 300MHz but the chip is too hot to hold at close to 70'C iirc so I like to "idle" it back to 250MHz normally. But yes, at 300MHz it can run day and night although it is only using 4 cogs when playing videos, one for TAQOZ console, one for filling the audio buffer, another for streaming audio, and one for VGA while the video plays via the console cog.
I converted a Mandelbrot routine that Martin H who has been a member here, had posted on the 6502 forum a couple of years ago. His routine would output an 80x80 gray-scale ASCII plot so I converted it to output a much larger VGA image instead in about 200 bytes of TAQOZ code.
TAQOZ
FORGET *MANDELBROT*
: *MANDELBROT* ;
( NOTE: Adapted from a routine written by Martin H )
20 := #MAXITER
220 := #MAXVAL
-229 := #MINVAL
pub SCALE 5 << ;
20 SCALE := #RESCALE
\ These variables hold values during the escape calculation.
long CREAL
long CIMAG
long ZREAL
long ZIMAG
long ESCCNT
\ stores the row column values from the stack for the escape calculation.
pri INIT_VARS
SCALE DUP CREAL ! ZREAL !
SCALE DUP CIMAG ! ZIMAG !
1 ESCCNT ! ;
\ Compute squares, but rescale to remove extra scaling factor.
pri ZSQ @ ABS DUP #RESCALE */ ;
\ Increment ESCCNT and compare to max iterations.
pri COUNT? ESCCNT ++ ESCCNT @ #MAXITER > ;
\ Performs a single iteration of the escape calculation.
pri DOESCAPE
ZREAL ZSQ ZIMAG ZSQ 2DUP +
#RESCALE 4* > IF
2DROP TRUE
ELSE
- CREAL @ + ( result )
ZREAL @ ABS ZIMAG @ ABS #RESCALE 2/ */
--- workaround for */ sign bug
ZREAL @ ZIMAG @ XOR 31 >> IF NEGATE THEN ( result val )
CIMAG @ + ZIMAG ! ZREAL !
COUNT?
THEN ;
\ Iterates on a single cell to compute its escape factor.
pri DOCELL ( row cell -- )
INIT_VARS BEGIN DOESCAPE UNTIL
--- expand the color and plot the pixel
ESCCNT @ 11 W* PIXEL! 1 X+!
;
\ For each cell in a row.
pri DOROW #MAXVAL #MINVAL DO DUP I DOCELL LOOP DROP ;
\ For each row in the set.
pub MANDELBROT
CLRSCR !PALETTE TL
#MAXVAL #MINVAL DO 1 Y+! 0 x I DOROW LOOP
;
pub ZOOM ( n -- ) SCALE ' #RESCALE :=! MANDELBROT ;
\ Run the computation with defaults
pub GO 200 ZOOM ;
END
I think my cheap VGA cable was playing up and killing the red. Anyway, I added extra controls to allow me to pan and zoom etc. Here is the updated image.
and panned and zoomed even more.
edit: disabled view image inline - too big
Wow Peter. Never ceases to amaze me how you can do such complex code in a few short instructions in taqoz. I still have trouble in wrapping my head around the code you publish
Now that I've tidied up the code a bit more I added some more controls and told it to zoom to 3200 in one area with 20 max iterations but then compared that with 250 iterations. Boy, what a difference!
You can see the same "tardigrade type appendages" although the colors are graded differently to suit the iterations.
Now that I've added these extras the Mandelbrot "program" is getting a bit unwieldy at 398 bytes!
I just realized that I'm wasting my time ..... taking screenshots with a camera. The whole bitmap and caboodle is right there, all I need to do is tidy up the header and write it to a file and I have my own fbgrab in bmp format.
The data is read from the SD card at about 1/10 of the clock speed so up to 3MB/s in multi-block mode. Each frame is read into a small buffer first and when the display is synched it will set the new 8-bit palette and then load the framebuffer in reverse due to each frame being a bmp where the image is vertically flipped. Since each frame is 320x240 it only needs 80k for the buffer and there is a routine to double up the pixels and lines for 640x480.
There is a glitch at present with synchronizing the reading of a sound block which should really only occur at the start of a frame synch wait otherwise the frame update will come late and glitch the display.
I remember you developed extra hardware for the P1 so that you could output higher resolution images than the P1 could manage. As you can see the P2 can do that very easily.
This is the one-liner that reads in a new frame into the bmp buffer in multi-block mode.
Thank you Peter, I'm back again waiting for the P2 challenge
While, I'm developing a new hardware With FPGA, but can´t read any about Prop2 still. Will be a great "micro" as I can see... Anxious to get it comertial version !!!. Have fun !!
@btxsistemas - I have some P2D2s I need to get out to people. Maybe you want one?
I wrote a quick n dirty fbgrab that seems to work well enough.
pre FBGRAB ( <name> )
--- setup a simple BMP header in BMP display memory
BMP 134 + " BM" W@ OVER W! 308736 SWAP 2+ !
--- allow a file to be created if it does not exsist
308736 MAKE
--- open <name> and save memory if valid
[C] FOPEN @FILE IF BMP 134 + @FILE 308736 SDWRS THEN
;
Oh Peter, I appreciate too much your offer, but I could not use that pchips right now, cause I can't understand any about the P2 programming still..Sorry.
I've pained to wait until comertial vertion is ready, and begin to read the documentation at that moment. Anyway thank you so much !!!!
By the way taking in advance this. Is there now, any place, where to download P2 spin doc's, P2 asm doc's. To get begin reading some of this ?
Click on the Propeller 2 discussion button and you will see the announcement threads. The one youll need is the P2 where to get documents from. There are no spin2 docs yet.
Comments
Sounds good, and I know I should bite the bullet with getting some code running on the EFM chip it's just that the overly complicated tools annoy me. I have done a lot of 8051 assembler before and written code for Silabs chips too. I guess I should just write some monitor functions for it anyway.
At the moment I don't see any problem.
I will load the RTC option and heatsink PCB by default on these ones, just let me know if you want the CP2102N loaded in place of the EFM8. The CP2102N will provide USB serial but you will still need to manually reset the P2 via the on-board reset switch when loading code since this chip doesn't have DTR and the RTS pin which goes to P57 is cut for the CP2102N.
I will post the ordering options back on the P2D2 thread shortly.
The QFN20 doesn't have the DTR but the larger pin count CP2102N (the newer version of the venerable CP2102) does.
I'm not here every day so. Trust me on this.
Thanks
Kind regards, Samuel Lourenço
Output from dmesg
The Prop was even running an old version of Tachyon 2015!
Exactly on EFM8UB3 nothing. But I have my Thunderboard EFM8UB3 (22€) on the way. I am familiar on the 8051 core so I know it will not represent an issue.
The main problem is that I still don't have a P2 in my hands and thus I can't start preparing and develop what I need. I need the EFM8 on the P2D2 and if presently Peter have troubles with that chip I don't want that this delay the P2D2r2/3 delivery ... thus I'll program the EFM8 by myself. I have paid enough attention with Peter that things such i2c was connected in the way that can sweet also my needs and anyway, even if Peter comes out with his firmware I will most probably develop mine to better adapt to my project/idea.
But let me ask to you two things, and forgive my ignorance please.
How fast are you reading data from SD card ?
Where are you buffering the data to show those videos ?
Welcome back Alberto, long time no Prop!
The data is read from the SD card at about 1/10 of the clock speed so up to 3MB/s in multi-block mode. Each frame is read into a small buffer first and when the display is synched it will set the new 8-bit palette and then load the framebuffer in reverse due to each frame being a bmp where the image is vertically flipped. Since each frame is 320x240 it only needs 80k for the buffer and there is a routine to double up the pixels and lines for 640x480.
There is a glitch at present with synchronizing the reading of a sound block which should really only occur at the start of a frame synch wait otherwise the frame update will come late and glitch the display.
I remember you developed extra hardware for the P1 so that you could output higher resolution images than the P1 could manage. As you can see the P2 can do that very easily.
This is the one-liner that reads in a new frame into the bmp buffer in multi-block mode.
I gather you are using 300 MHz by default these days. No unexplained glitches or crashes reoccurring at all?
Funny thing happened on my way to the forum .... I had trouble with running my P2D2 over 160MHz or so although it worked fine otherwise. So I cooled the module in the freezer and tried again. Nada.
This is not right I thought and then I decided to check my bake recipe for the module, I wasn't using the one for the R2 version with 25MHz clock!
TAQOZ FORGET *MANDELBROT* : *MANDELBROT* ; ( NOTE: Adapted from a routine written by Martin H ) 20 := #MAXITER 220 := #MAXVAL -229 := #MINVAL pub SCALE 5 << ; 20 SCALE := #RESCALE \ These variables hold values during the escape calculation. long CREAL long CIMAG long ZREAL long ZIMAG long ESCCNT \ stores the row column values from the stack for the escape calculation. pri INIT_VARS SCALE DUP CREAL ! ZREAL ! SCALE DUP CIMAG ! ZIMAG ! 1 ESCCNT ! ; \ Compute squares, but rescale to remove extra scaling factor. pri ZSQ @ ABS DUP #RESCALE */ ; \ Increment ESCCNT and compare to max iterations. pri COUNT? ESCCNT ++ ESCCNT @ #MAXITER > ; \ Performs a single iteration of the escape calculation. pri DOESCAPE ZREAL ZSQ ZIMAG ZSQ 2DUP + #RESCALE 4* > IF 2DROP TRUE ELSE - CREAL @ + ( result ) ZREAL @ ABS ZIMAG @ ABS #RESCALE 2/ */ --- workaround for */ sign bug ZREAL @ ZIMAG @ XOR 31 >> IF NEGATE THEN ( result val ) CIMAG @ + ZIMAG ! ZREAL ! COUNT? THEN ; \ Iterates on a single cell to compute its escape factor. pri DOCELL ( row cell -- ) INIT_VARS BEGIN DOESCAPE UNTIL --- expand the color and plot the pixel ESCCNT @ 11 W* PIXEL! 1 X+! ; \ For each cell in a row. pri DOROW #MAXVAL #MINVAL DO DUP I DOCELL LOOP DROP ; \ For each row in the set. pub MANDELBROT CLRSCR !PALETTE TL #MAXVAL #MINVAL DO 1 Y+! 0 x I DOROW LOOP ; pub ZOOM ( n -- ) SCALE ' #RESCALE :=! MANDELBROT ; \ Run the computation with defaults pub GO 200 ZOOM ; ENDand panned and zoomed even more.
edit: disabled view image inline - too big
You can see the same "tardigrade type appendages" although the colors are graded differently to suit the iterations.
Now that I've added these extras the Mandelbrot "program" is getting a bit unwieldy at 398 bytes!
under 400 bytes - I might be not able to write Hello World in COBOL keeping Standard requirements within 400 bytes source.
cool stuff you are doing there down under.
Enjoy!
Mike
Now I will have to fire up my FTP server too.
Thank you Peter, I'm back again waiting for the P2 challenge
While, I'm developing a new hardware With FPGA, but can´t read any about Prop2 still. Will be a great "micro" as I can see... Anxious to get it comertial version !!!. Have fun !!
I wrote a quick n dirty fbgrab that seems to work well enough.
I've pained to wait until comertial vertion is ready, and begin to read the documentation at that moment. Anyway thank you so much !!!!
By the way taking in advance this. Is there now, any place, where to download P2 spin doc's, P2 asm doc's. To get begin reading some of this ?
So Martin, are you thinking about using the P2 yourself?
I could really use a couple of P2D2's. How do I order?
Thanks
Rich