I'm thinking I will supply standard height female socket headers loose by default but I can solder them on if requested.
I think that approach does make the most sense. I only know that I would definately want headers, but not yet sure whether male or female?
Most small dev boards seem to come with loose male pin headers, which you often you want to solder pointing down (for plugging into a breadboard).
If you're using duPont hook-up wires, then of course you can use either male or female duPont connectors, to allow connecting to either female or male headers.
Bear in mind that the dev board will have pin headers so the P2D2 would need female headers to plug-in bottoms up! I will release some dev boards details shortly!
After a hiccup in the ordering process the pcbs finally arrived today. They had queried about how the v-groove would cut into copper on the edge of the pcb and this was lost in my emails and not showing on the job status page. Once I eventually found it 5 days later after wondering what was happening, they proceeded by increasing the edges of the pcb by 0.2mm, hence the delays. I will make up a panel tomorrow and test, and then if it is all good I can proceed with getting these assembled and shipped.
I know, I'm a bit late. Is there still one board left for me? What would shipping to Germany cost? Or is there anybody from Europe here so we could bundle shipping?
Very nice! That component density on the right hand side of the board is truly a work of Art! (perhaps some magic art?).
Thanks! Placement is everything when it comes to laying out a pcb. Having connectors in the right place and accessible, crystals close and tight to the chips, "broad ways" from regulator to chips, and effective direct decoupling as well as choice of component and package. Multi-layer boards make it easy to get some of this right without even trying but I try to make it work just as well with cost effective 2 layer boards and minimal vias. Then I get sneaky and use resistor networks since they are like much smaller resistors but in an easy to manually handle package. I used to use 0805 components but now they look like hippos next to 0603, which even seem too big sometimes
If I was definitely going to large volume runs and the design is proven I might even go to 4 layer and 0402 components even, but in the case of the P2D2, the size is dictated to a large extent by the P2 and the large number of header pins.
However I am doing up P2PAL, an extra thin "layer" for the P2D2 that surface mounts to the entire back of the pcb up to the 50mil "smd" headers which includes an ESP32 module, HyperRAM, a proper spring loaded microSD socket, LEDs, reset etc. This can even be soldered on after-market.
Then there is my P2LAB, the dev board that the P2D2 plugs into to which includes IOMOD and mikroBUS headers, a JAMMA edge connector etc, and all the connectors that you would expect such as audio, HDMI, VGA, USB etc. But if you want, you can still place this P2LAB into a standard enclosure for commercial projects. I like to flip the box and use the lid as the base so that I only need to notch holes from the edge of the box for the connectors and then this also hides the lid screws if I cut keyhole mounts in the lid (as a base). Then I can make up a nice durable label by laser printing onto polyester laser label sheets using my HP laser because the genuine black toner is a strong even shiny black.
@"Peter Jakacki" Does your P2 PAL board need the ESP32 and other parts, or can there still be a basic HyperRAM only version? i.e. Can these be optional?
How did you plan to map the pins? Were the ESP serial pins also going to work with P62/P63?
If it is still thin enough and can interoperate with the existing pin mapping I have I may like Wifi as well, as I have a Wifi part on my board that could be replaced by ESP32, but possibly not if it uses up a lot of other P2 pins. I had some muxing logic on my board that allowed USB if it was plugged in, and Wifi if USB was not plugged in. This was controlled by an AVR on board, which also contained the USB - serial interface like your EFM part.
@"Peter Jakacki" Does your P2 PAL board need the ESP32 and other parts, or can there still be a basic HyperRAM only version? i.e. Can these be optional?
How did you plan to map the pins? Were the ESP serial pins also going to work with P62/P63?
If it is still thin enough and can interoperate with the existing pin mapping I have I may like Wifi as well, as I have a Wifi part on my board that could be replaced by ESP32, but possibly not if it uses up a lot of other P2 pins. I had some muxing logic on my board that allowed USB if it was plugged in, and Wifi if USB was not plugged in. This was controlled by an AVR on board, which also contained the USB - serial interface like your EFM part.
I'm still thinking about how the ESP32 module will connect but certainly the serial port is a no-brainer. But the serial transmit from the ESP32 would be resistor coupled so that it can be overridden from the USB or from the direct Prop plug connection. In fact, I may get the UB3 chip to disconnect it's serial with a pullup still connected whenever it is not plugged into USB (attn: jmg!)
Here is a basic plan of the P2PAL pcb as I am moving components around the board until I'm happy with it. I had swapped the microSD and ESP positions since HyperRAM also needed to be up closer to the P32 group but could connect to the P40 group if that works out as a better choice.
Of course, you can have a P2PAL with just the HyperRAM if you want. It is also easy enough to hand solder the ESP32 module on afterwards too. I sourced some microSD sockets from LCSC at a very very good price, so that's why I allowed for it on the P2PAL just so I can easily get to the card and once it is inserted it is well protected.
@rogloh - do you have a plain pdf of your schematic? I noticed that you use 22r series termination for USB. I know that the P2 has built-in 1.5k and 15k and it doesn't hurt to allow for termination, but do we still need them?
Rather than a buffered and jumpered serial mux option I like the automatic override that comes from plugging in USB or a Prop Plug. It shouldn't matter if the WiFi receives data even when USB is plugged in either.
Is there a preference for the HyperRAM on P32 etc or can they go elsewhere. I'm guessing that the 32-bit alignment helps though.
P32..P39 data bus alignment really helps with this optimization ozpropdev found and uses in the HyperRAM code, allows writing data in a single instruction without the streamer. If you can put it there too, all the better.
@rogloh - do you have a plain pdf of your schematic? I noticed that you use 22r series termination for USB. I know that the P2 has built-in 1.5k and 15k and it doesn't hurt to allow for termination, but do we still need them?
Rather than a buffered and jumpered serial mux option I like the automatic override that comes from plugging in USB or a Prop Plug. It shouldn't matter if the WiFi receives data even when USB is plugged in either.
I do have a pdf schematic but (for now anyway) don't want to release the entire thing. Yeah the automatic override is nicer. I put in those jumpers that way really just for experimenting with. No need to require strapping options in the final thing. One thing that could be good though is to allow USB connection without always losing the wifi (for debug testing of wifi applications while you still download with USB etc), in that case having the ability to still be able to send wifi data to other P2 pins is handy, so perhaps some holes for optional jumpers to strap wifi to P2 pins would be good there.
Those resistors are recommended for the ATMEL micro's USB IIRC, that was not a USB prop interface.
.. I noticed that you use 22r series termination for USB. I know that the P2 has built-in 1.5k and 15k and it doesn't hurt to allow for termination, but do we still need them?
I think those 22R can also be used as jumpers, eg the Eval A IIRC had them, to allow USB-for-Power alone, so errant P2 pins do not fire some USB charger into a higher power mode....
Looks like Eval B has removed those entirely, so it is safer, and purely USB 2A AUX only.
Some vendors use 22R/27R to improve ESD and RFI.
The EFM8UB3 has 8kV ESD spec, but I see SiLabs still suggest an ESD part, perhaps to get to 15kV ratings ?
.. I noticed that you use 22r series termination for USB. I know that the P2 has built-in 1.5k and 15k and it doesn't hurt to allow for termination, but do we still need them?
I think those 22R can also be used as jumpers, eg the Eval A IIRC had them, to allow USB-for-Power alone, so errant P2 pins do not fire some USB charger into a higher power mode....
Looks like Eval B has removed those entirely, so it is safer, and purely USB 2A AUX only.
Some vendors use 22R/27R to improve ESD and RFI.
The EFM8UB3 has 8kV ESD spec, but I see SiLabs still suggest an ESD part, perhaps to get to 15kV ratings ?
I sourced some esd diodes from LCSC at a very good price. The part that is used on the EVAL USB is frightfully expensive for such a tiny component.
After glitches and delays with getting the new pcbs and stencil back, I am about to start assembling the first panel for testing. I expect all to go well but I was just trying out a new stencil alignment checker using a mounted smartphone set up for super macro so that I can get precise alignment although next time I will have fiducials on a the edge strips of the paneled pcbs.
BTW, even though this stencil looked like it was aligned, the camera revealed it was not so::
While I am getting these pcbs assembled here is what the P2PAL companion for the P2D2 will look like more or less, since I'm not quite finished. This is a thin pcb that surface mount solders onto the back of the P2D2 effectively becoming part of the pcb itself and includes an ESP32 module, a proper push-push microSD connector, a dedicated 8MB PSRAM in QPI mode, and HyperRAM as well as a larger RTC cap plus reset button and indicators. I may include a few more indicators before I am finally done. The ESP32 module is running direct from the 3.6V from the switcher and therefore has plenty of peak current capability when needed.
note: the board outline is incorrect on this 3d render since the ESP32 pcb antenna juts out but the pcb edge is further back and the mounting holes are castellated (cut in half for smd).
P2PAL is looking very interesting Peter. I'm also hoping the P2PAL might also assist us thermally if it has a reasonable sized ground plane on the reverse side to help dissipate more heat from the P2 it gets attached to.
I wonder if the P2PAL MicroSD could have two options, maybe with a solder jumper to change it. The main (default) option is just using the usual 4 pin SPI mode SD card from the regular P2 boot pins P58-P61 as you have wired above. The second option is for people wanting to try the higher performance 6 pin SD mode, perhaps by reusing the the 6 pins for PSRAM if that part is not fitted. That way you get the possibility of having the main SD or flash on the P2D2 as the P2's boot device, plus a separate second independent SD card for application use and potentially operated in the higher speed SD mode. Obviously you couldn't boot directly from it if it was strapped for the SD mode unless there is some other multi stage boot loader already on flash/internal SD to support that.
I'm just thinking what might be useful for different people. For the people who want the higher performance option they might have to cut a default PCB jumper track and solder bridge to the other side of the three way solder jumper etc, like they might do on other AdaFruit/SparkFun boards etc. I had this option on my own board and though I've not written the SD mode code for that yet I did put a SD controller into the P1V and got SD init and reads working there in this 4 bit SD mode after digging online for timing data, so it's quite achievable. The P2 streamer should be able to assist the transfers if the SD nibbles are suitably aligned on the 0-3 pin group of 8 I would expect (needs to be checked if this needs to be the lower or upper nibble of the 8 pin group, or doesn't matter, same for PSRAM). Maybe we could speed up the P2's SD accesses by 4x or more using the SD mode, particularly if it can clock even faster when in native SD mode as some cards do IIRC.
In your layout above it looks like your SD tracks run fairly close by to where your PSRAM option is anyway so placing some extra solder jumpers near there may be achievable...? Otherwise a second board variant might be a different way to achieve it.
The only downside is that all these things can start eating up pins of port B, so keeping as many of them optional is preferable. I suspect given how this P2D2 design is evolving some people might start to use port B for fixed use items like onboard RAM + SD + wifi/serial (and perhaps also video/network/USB/i2c) and this still leaves port A completely free for general use, but everyone will still want the ability to customise as much as possible for their own purposes so keeping peripherals optional wherever possible is definitely the way to go.
Update: What I rather like is that it looks like your P2PAL option should still allow 4-5 pins for VGA on P43-47 (depending on if you did a dedicated Reset for HyperRAM or just share the main reset line), plus two spare pins for USB (or PS/2) on P54-P55 even when fully populated with both HyperRAM and either PSRAM/Flash/SD mode cards (if you get to support that option too). That still allows a rather flexible peripheral combination with Port A remaining completely free for application use. I like it.
After I made up some of the new pcbs I had to check them plus I had solder paste problems finding also that the switching regulator doesn't self align well during reflow and shorts itself out. But the board itself works great and I had a busy past week or so catching up on other stuff and so next week I should be right to get these assembled and tested. I had also ordered the standard height female headers which I will ship with the boards unsoldered. It may be that I if I get the P2PAL add-on and P2LAB dev board finished this week that I have them back early January.
Here is the TAQOZ (reloaded) console firing up and reporting.
KERNEL Parallax P2 *TAQOZ* Extensible Firmware V2.2 'CHIP' 300MHz 191021-0900
MODULES:
*EASYNET* WIZnet NETWORK SERVERS 160707.1500
*W5500* WIZNET W5500 driver for TAQOZ V1.0 191007
*CLKGEN* Si5351 Clock generator 190800-0000
*TEXT* VGA BMP TEXT 190800-0000
*BMV* BMV VIDEO PLAYER 190800-0000
*WAVE* WAVE AUDIO FILE PLAYER 190800-0000
*BMP* BMP FILE VIEWER 190800-0000
*AV* AUDIO & VIDEO DRIVERS 190614-0000
*ASMEX* PASM2 instruction exerciser 191014-0000
*SPIRAM* LY68L6400 8MB SPI RAM ACCESS 191020-0000
*DECOMPILER* A decompiler for TAQOZ 190825-0000
*RTC* RV-3028 RTC DATE and TIME 190800-0000
*I2C* I2C BUS DRIVER 191000-0000
*DISK* SD DISK REPORTING & FORMATTING TOOLS 190800-0000
*EASYFILE* SD CARD and FAT32 with VIRTUAL MEMORY 190800-0000
*SMARTPINS* SMARTPIN FUNCTIONS and drive modes 190800-0000
*P2CLOCK* P2 CLOCK CONTROL 190800-0000
*EXTEND* Primary kernel extensions 191117-1600
*SPIFLASH*
MEMORY MAP
CODE: $0000_8B4A 35,658 bytes
WORDS: $0000_BB71 12,029 bytes
DATA: $0007_E17A 378 bytes
64K FREE: 12,327 bytes
HARDWARE
PCB P2D2r4
CLOCK IN 20MHZ
DEVICES
SD CARD 63GB SANDISK SD SC64G REV$80 #38883160 DATE:2019/8
SPI FLASH 16MB WINBOND $EF40_1800 #4837448895114529879
I2C DEVICES
$A4 RV-3028 RTC
$C4 Si5351A CLOCK GEN
2019/12/25 WED 10:09:12
-------------------------------------------------------------------------------
TAQOZ# fibos ---
fibo(1) = 458 cycles= 1,526ns @300MHz result = 1
fibo(6) = 778 cycles= 2,593ns @300MHz result = 8
fibo(11) = 1,098 cycles= 3,660ns @300MHz result = 89
fibo(16) = 1,418 cycles= 4,726ns @300MHz result = 987
fibo(21) = 1,738 cycles= 5,793ns @300MHz result = 10,946
fibo(26) = 2,058 cycles= 6,860ns @300MHz result = 121,393
fibo(31) = 2,378 cycles= 7,926ns @300MHz result = 1,346,269
fibo(36) = 2,698 cycles= 8,993ns @300MHz result = 14,930,352
fibo(41) = 3,018 cycles= 10,060ns @300MHz result = 165,580,141
fibo(46) = 3,338 cycles= 11,126ns @300MHz result = 1,836,311,903 ok
TAQOZ#
Comments
I think that approach does make the most sense. I only know that I would definately want headers, but not yet sure whether male or female?
Most small dev boards seem to come with loose male pin headers, which you often you want to solder pointing down (for plugging into a breadboard).
If you're using duPont hook-up wires, then of course you can use either male or female duPont connectors, to allow connecting to either female or male headers.
I'd also be happy to solder the header on myself.
Sorry if I'm rambling... just my 2c thoughts.
I would prefer that headers in question remain unsoldered.
Thanks
Thanks! Placement is everything when it comes to laying out a pcb. Having connectors in the right place and accessible, crystals close and tight to the chips, "broad ways" from regulator to chips, and effective direct decoupling as well as choice of component and package. Multi-layer boards make it easy to get some of this right without even trying but I try to make it work just as well with cost effective 2 layer boards and minimal vias. Then I get sneaky and use resistor networks since they are like much smaller resistors but in an easy to manually handle package. I used to use 0805 components but now they look like hippos next to 0603, which even seem too big sometimes
If I was definitely going to large volume runs and the design is proven I might even go to 4 layer and 0402 components even, but in the case of the P2D2, the size is dictated to a large extent by the P2 and the large number of header pins.
However I am doing up P2PAL, an extra thin "layer" for the P2D2 that surface mounts to the entire back of the pcb up to the 50mil "smd" headers which includes an ESP32 module, HyperRAM, a proper spring loaded microSD socket, LEDs, reset etc. This can even be soldered on after-market.
Then there is my P2LAB, the dev board that the P2D2 plugs into to which includes IOMOD and mikroBUS headers, a JAMMA edge connector etc, and all the connectors that you would expect such as audio, HDMI, VGA, USB etc. But if you want, you can still place this P2LAB into a standard enclosure for commercial projects. I like to flip the box and use the lid as the base so that I only need to notch holes from the edge of the box for the connectors and then this also hides the lid screws if I cut keyhole mounts in the lid (as a base). Then I can make up a nice durable label by laser printing onto polyester laser label sheets using my HP laser because the genuine black toner is a strong even shiny black.
How did you plan to map the pins? Were the ESP serial pins also going to work with P62/P63?
If it is still thin enough and can interoperate with the existing pin mapping I have I may like Wifi as well, as I have a Wifi part on my board that could be replaced by ESP32, but possibly not if it uses up a lot of other P2 pins. I had some muxing logic on my board that allowed USB if it was plugged in, and Wifi if USB was not plugged in. This was controlled by an AVR on board, which also contained the USB - serial interface like your EFM part.
I'm still thinking about how the ESP32 module will connect but certainly the serial port is a no-brainer. But the serial transmit from the ESP32 would be resistor coupled so that it can be overridden from the USB or from the direct Prop plug connection. In fact, I may get the UB3 chip to disconnect it's serial with a pullup still connected whenever it is not plugged into USB (attn: jmg!)
Here is a basic plan of the P2PAL pcb as I am moving components around the board until I'm happy with it. I had swapped the microSD and ESP positions since HyperRAM also needed to be up closer to the P32 group but could connect to the P40 group if that works out as a better choice.
Of course, you can have a P2PAL with just the HyperRAM if you want. It is also easy enough to hand solder the ESP32 module on afterwards too. I sourced some microSD sockets from LCSC at a very very good price, so that's why I allowed for it on the P2PAL just so I can easily get to the card and once it is inserted it is well protected.
Rather than a buffered and jumpered serial mux option I like the automatic override that comes from plugging in USB or a Prop Plug. It shouldn't matter if the WiFi receives data even when USB is plugged in either.
Is there a preference for the HyperRAM on P32 etc or can they go elsewhere. I'm guessing that the 32-bit alignment helps though.
wfbyte inb (or ina)
I do have a pdf schematic but (for now anyway) don't want to release the entire thing. Yeah the automatic override is nicer. I put in those jumpers that way really just for experimenting with. No need to require strapping options in the final thing. One thing that could be good though is to allow USB connection without always losing the wifi (for debug testing of wifi applications while you still download with USB etc), in that case having the ability to still be able to send wifi data to other P2 pins is handy, so perhaps some holes for optional jumpers to strap wifi to P2 pins would be good there.
Those resistors are recommended for the ATMEL micro's USB IIRC, that was not a USB prop interface.
Looks like Eval B has removed those entirely, so it is safer, and purely USB 2A AUX only.
Some vendors use 22R/27R to improve ESD and RFI.
The EFM8UB3 has 8kV ESD spec, but I see SiLabs still suggest an ESD part, perhaps to get to 15kV ratings ?
I sourced some esd diodes from LCSC at a very good price. The part that is used on the EVAL USB is frightfully expensive for such a tiny component.
'Vol verwachting klopt mijn hart'
BTW, even though this stencil looked like it was aligned, the camera revealed it was not so::
note: the board outline is incorrect on this 3d render since the ESP32 pcb antenna juts out but the pcb edge is further back and the mounting holes are castellated (cut in half for smd).
I wonder if the P2PAL MicroSD could have two options, maybe with a solder jumper to change it. The main (default) option is just using the usual 4 pin SPI mode SD card from the regular P2 boot pins P58-P61 as you have wired above. The second option is for people wanting to try the higher performance 6 pin SD mode, perhaps by reusing the the 6 pins for PSRAM if that part is not fitted. That way you get the possibility of having the main SD or flash on the P2D2 as the P2's boot device, plus a separate second independent SD card for application use and potentially operated in the higher speed SD mode. Obviously you couldn't boot directly from it if it was strapped for the SD mode unless there is some other multi stage boot loader already on flash/internal SD to support that.
I'm just thinking what might be useful for different people. For the people who want the higher performance option they might have to cut a default PCB jumper track and solder bridge to the other side of the three way solder jumper etc, like they might do on other AdaFruit/SparkFun boards etc. I had this option on my own board and though I've not written the SD mode code for that yet I did put a SD controller into the P1V and got SD init and reads working there in this 4 bit SD mode after digging online for timing data, so it's quite achievable. The P2 streamer should be able to assist the transfers if the SD nibbles are suitably aligned on the 0-3 pin group of 8 I would expect (needs to be checked if this needs to be the lower or upper nibble of the 8 pin group, or doesn't matter, same for PSRAM). Maybe we could speed up the P2's SD accesses by 4x or more using the SD mode, particularly if it can clock even faster when in native SD mode as some cards do IIRC.
In your layout above it looks like your SD tracks run fairly close by to where your PSRAM option is anyway so placing some extra solder jumpers near there may be achievable...? Otherwise a second board variant might be a different way to achieve it.
The only downside is that all these things can start eating up pins of port B, so keeping as many of them optional is preferable. I suspect given how this P2D2 design is evolving some people might start to use port B for fixed use items like onboard RAM + SD + wifi/serial (and perhaps also video/network/USB/i2c) and this still leaves port A completely free for general use, but everyone will still want the ability to customise as much as possible for their own purposes so keeping peripherals optional wherever possible is definitely the way to go.
Update: What I rather like is that it looks like your P2PAL option should still allow 4-5 pins for VGA on P43-47 (depending on if you did a dedicated Reset for HyperRAM or just share the main reset line), plus two spare pins for USB (or PS/2) on P54-P55 even when fully populated with both HyperRAM and either PSRAM/Flash/SD mode cards (if you get to support that option too). That still allows a rather flexible peripheral combination with Port A remaining completely free for application use. I like it.
It does look great! I'm looking forward to trying it out
Any progress on this board worth sharing with us?
Merry chipmas !
Here is the TAQOZ (reloaded) console firing up and reporting.
KERNEL Parallax P2 *TAQOZ* Extensible Firmware V2.2 'CHIP' 300MHz 191021-0900 MODULES: *EASYNET* WIZnet NETWORK SERVERS 160707.1500 *W5500* WIZNET W5500 driver for TAQOZ V1.0 191007 *CLKGEN* Si5351 Clock generator 190800-0000 *TEXT* VGA BMP TEXT 190800-0000 *BMV* BMV VIDEO PLAYER 190800-0000 *WAVE* WAVE AUDIO FILE PLAYER 190800-0000 *BMP* BMP FILE VIEWER 190800-0000 *AV* AUDIO & VIDEO DRIVERS 190614-0000 *ASMEX* PASM2 instruction exerciser 191014-0000 *SPIRAM* LY68L6400 8MB SPI RAM ACCESS 191020-0000 *DECOMPILER* A decompiler for TAQOZ 190825-0000 *RTC* RV-3028 RTC DATE and TIME 190800-0000 *I2C* I2C BUS DRIVER 191000-0000 *DISK* SD DISK REPORTING & FORMATTING TOOLS 190800-0000 *EASYFILE* SD CARD and FAT32 with VIRTUAL MEMORY 190800-0000 *SMARTPINS* SMARTPIN FUNCTIONS and drive modes 190800-0000 *P2CLOCK* P2 CLOCK CONTROL 190800-0000 *EXTEND* Primary kernel extensions 191117-1600 *SPIFLASH* MEMORY MAP CODE: $0000_8B4A 35,658 bytes WORDS: $0000_BB71 12,029 bytes DATA: $0007_E17A 378 bytes 64K FREE: 12,327 bytes HARDWARE PCB P2D2r4 CLOCK IN 20MHZ DEVICES SD CARD 63GB SANDISK SD SC64G REV$80 #38883160 DATE:2019/8 SPI FLASH 16MB WINBOND $EF40_1800 #4837448895114529879 I2C DEVICES $A4 RV-3028 RTC $C4 Si5351A CLOCK GEN 2019/12/25 WED 10:09:12 ------------------------------------------------------------------------------- TAQOZ# fibos --- fibo(1) = 458 cycles= 1,526ns @300MHz result = 1 fibo(6) = 778 cycles= 2,593ns @300MHz result = 8 fibo(11) = 1,098 cycles= 3,660ns @300MHz result = 89 fibo(16) = 1,418 cycles= 4,726ns @300MHz result = 987 fibo(21) = 1,738 cycles= 5,793ns @300MHz result = 10,946 fibo(26) = 2,058 cycles= 6,860ns @300MHz result = 121,393 fibo(31) = 2,378 cycles= 7,926ns @300MHz result = 1,346,269 fibo(36) = 2,698 cycles= 8,993ns @300MHz result = 14,930,352 fibo(41) = 3,018 cycles= 10,060ns @300MHz result = 165,580,141 fibo(46) = 3,338 cycles= 11,126ns @300MHz result = 1,836,311,903 ok TAQOZ#