Here is the HyperRam schematic based on various HyperRam notes on various threads. I added the XNOR for LCD Clock Doubling. I assume the plan discussed was using parallel HR? I assume Y output replaces P_CLK. Not quite sure the concept of clock doubling if the data is already updated on each high and low transition of CK to the HR. Maybe, the PCLK on the Prop is running 1/2 speed of the DDR double clocked, so you MUST double the PCLK to sync with the 16 bit wide data transitions.
Maybe someone can clarify the HR concept with LCD. Here is what I assume:
1. Use P1 or P1V to read a full screen of data ( ie 800x480x16 / 8 = 768000bytes from SD to HyperRam1 and 2 at address. 565? 555? 444?
2. Clock the Hyperram starting at address and cycle that range for as long as the screen is active. Not really clear on how this works
3. Use LCD Clock Doubler XNOR to avoid using a counter or extra clock to get fast enough speeds, also used so the clock is only running when data is running.
Data from SD must be read in one byte or word at a time, then written a byte at a time to HR1 and HR2, simultaneously low byte high byte? To save pins use the same 8 pins or writing both HR's, but writes would be /2 speed.
8m / 768k = 10.41 full screens can be stored, all the software needs to do is jump to a different address to cycle for the HR to drive the LCD.
I added the SPI Flash 16m part to both MAX10 and P1 to learn how to use those and see what may be done in the future.
EVE2 is connected to LCD with jumpers, but HR will be jumperable as well once I see what the color config is.
Everything is routing on 2 layers.
Need to study oz and others methods of SPI Flash boot, MAX10 Flash boot. For starters EEPROM is the plan.
P1 and P1V both have a Micro SD and SPI Flash
P1 has RTC.
HyperRams will be jumperable to use either P1 or Max10.
Altera told me regarding FTDI FT2232H that I need to crawl before can walk. I assume that means we are not going to help you. No big deal for now. I like that dual CPxxxx USB device so 1 USB cable/port can program either P1 or P1V, but need to understand how to select either device. Maybe get an eval for it later.
Here is the HyperRam schematic based on various HyperRam notes on various threads. I added the XNOR for LCD Clock Doubling. I assume the plan discussed was using parallel HR?
Maybe someone can clarify the HR concept with LCD. Here is what I assume:
1. Use P1 or P1V to read a full screen of data ( ie 800x480x16 / 8 = 768000bytes from SD to HyperRam1 and 2 at address. 565? 555? 444?
2. Clock the Hyperram starting at address and cycle that range for as long as the screen is active. Not really clear on how this works
3. Use LCD Clock Doubler XNOR to avoid using a counter or extra clock to get fast enough speeds, also used so the clock is only running when data is running.
Close, the main reason for the XNOR doubler, is the RWDS is DDR signal, so changes on new Data, whilst LCD expects a rising clock edge for stable data.
Data from SD must be read in one byte or word at a time, then written a byte at a time to HR1 and HR2, simultaneously low byte high byte? To save pins use the same 8 pins or writing both HR's, but writes would be /2 speed.
? If you parallel the pins, for write, you need to separate them for LCD drive.
8m / 768k = 10.41 full screens can be stored, all the software needs to do is jump to a different address to cycle for the HR to drive the LCD.
That depends on mode chosen..
There are two main approaches I see to HR use.
a) The simplest, is to use linear clocking, where you address once, and use DE to give any required LCD framing.
The unused RAM is simply skipped-over, but there is lots of it...
One down side of this, is the HR is display only, and (I think) unused areas are not refreshed.
That means multi-screen jumps are not so easy.... One appeal of this mode, is it should work even with P1.
Writes have to be done in inactive frame time, but you have 64ms within which to (re)read and write.
b) The more complex drive, uses a little verilog to drive HR in shorter bursts.
This can use a CLUT to do 8:16 colour drive, and the short bursts mean Auto-refresh manages the whole device.
Writes can be more frequent with this approach.
This could use one HR, but the P1V does do more work.
The second HR could be used for XIP designs, or you could pack more into the Display HR, and accept a little speed hit.
Plenty of choices and it's all just software ...
If you wanted to use CLUT that would mean separate pins to map LCD to FPGA.
? If you parallel the pins, for write, you need to separate them for LCD drive
That's what happens when you stare at the screen too long. Thanks for pointing out that obviosly the LCD must have the pins separated. Any thoughts on color bits per RBG? The 16 bits of data need to be spread out over 24 bits of input, not sure how to spread that out symetrically.
The HR>LCD testing is more to try out your ideas for non EVE2 use that may benefit you guys, I personally don't think I will use it for LCD, the EVE2 is cheaper than two HR+XNOR and it is ALL about screen changes for me, video, camera, button ani, etc. Also, changing pages seems like it will have a lag time of SD read > HR which will not suit my needs. FYI FTDI is sending me methods next week to show how to stream a camera to EVE2. If you have some specific ideas you want to try, I will try it but otherwise I will skip it as the HR seems like a significant PASM undertaking and timing challenge for which I am not qualified. I may use the HR's for buffering graphics, video from cameras, etc so I will learn them for memory purposes for sure.
I have not yet looked at the P123 loader. I felt like with all the IO exposed it would be easy to jump something later. I'll look for the P123 schematic later this eve. Yes I was going to ask chip what LE would be needed for 2 cores. A9 is 200k I think. Might be pushing it for 2 cores.
The only schematic I find is in the zipped documents at the top of this thread. Cyclone 5E. 16 Bit/pins from P1, plus 5 other pins. I can't tie up the 24 pins, or they would have to have switches on them. But, maybe a P1 module just for programming the MAX, needs a lot of study for this. Looks like on P1 they have a mux for a switch to route FTDI to either P1 rx/tx/resn or FPGA. I am assuming the P1 loader we are seeing here is only for FPGA programming of the quartus file, not a Spin binary. Also they include the P1 PASM loader Spin file. So, does this imply I can forget the USB blaster or any variant and just build my own P1 blaster? This seems very simple. The issue is finding 21io free or switching. I did not use any Slow speed io, or VREF io pins as they stated higher capacitance. But for loading? May be fine, also maybe the loader has a speed control built in to slow it down.
I am assuming the P1 loader we are seeing here is only for FPGA programming of the quartus file, not a Spin binary. Also they include the P1 PASM loader Spin file. So, does this imply I can forget the USB blaster or any variant and just build my own P1 blaster? This seems very simple. The issue is finding 21io free or switching. ...
There are many boot choices for RAM based FPGAs offer, looks like that one is a 16b Wide, host-clocked - that's a good choice on a 400+ pin part, but maybe not so good on a 144 pin device...
The MAX10 also looks to have only JTAG as a choice, which could make it quite a lot of work to re-work the P1 to manage JTAG
ie Simple place 16b & issue clock, needs to have JTAG state engines added, and probably SVF support for erase.
A google of
Altera SVF programming using FTDI JTAG
finds quite a few mentions, including some github ones, so you may be able to leverage those ?
I did some work with EFM8 micros as UART-JTAG, I'll look for later..
Connecting the JTAG pins to the P1 seems simple enough, to cover choices.
Thanks for looking at the loader. I see some other forums discuss FTDI and JTAG and it is said that the loader must have an Altera CPLD on it to work. Also others have stated that Altera rejected helping them, they say "buy the Blaster and don't bug us". Not a big deal, I can't imaging loading the Quartus files that often. I would like eventually get it to load from the SPI Flash, internal flash, and explore how to increase hub ram for the main program to as large as possible so in those cases where will be some experimenting. As for dual UART, I looked at the part and that would be nice to have one USB B vertical port, and choose which UART. At a quick glance I did not get how you select which UART is being used. I would really like to stick with my Silabs loader and command line apps. Maybe that part is easily modified.
Edit
Virtual COM Port (VCP) device drivers provided by Silico Labs allow a CP2105-based product to appear as two COM ports in PC applications.
I found this work https://sourceforge.net/p/ixo-jtag/code/HEAD/tree/usb_jtag/trunk/
which has various hardware platforms for JTAG and OpenOCD, but are a little old, and I see things like this : - device/f32x: (currently unfinished) attempt to get the firmware running on SiLabs F32x USB controller
Pity it is tagged unfinished, as the EFM8UB1 (newest F32x) is a low cost USB pathway.
says some info about Code size and speed tests, so it looks like round-trip data was functional, on a COM port basis.
EFM8UB1 comes in 8k & 16k, so the code in either SDCC or Keil looks to have headroom for JTAG IO drivers.
The code is compiled with Keil or SDCC. The conditional compilation on the code automatically detects the compiler.
The work space files, 'Keil_USB_CDC_skeleton.wsp' and SDCC_USB_CDC_skeleton.wsp', are provided for SiLabs IDE.
SMALL memory model Code size
Keil full version and 4K eval (SiLabs) 3754 Bytes (F320 and F340)
SDCC 2.6.0 #4290 (20060718-4290) 4105 Bytes (F320 and F340)
This implementation simply echoes back the TX output of COM port to RX port.
Following transfer speed was observed on loop back, simultaneous bi-direction transfer (WinXP SP2).
SYSCLK Speed (Kbytes/sec)
F320DK 24MHz 150
F340DK 48MHz 280
( EFM8UB1 is 48MHz, similar to F340 )
Though I didn't check about transfer speed of single direction transfer, it'll be much faster, from the record of bus analyzer.
Still, the FT2232H looks like the path of least work ( at a higher price).
Thanks for all the info. I glanced at each link and all of that is way over my head, and I think the learning curve to build the loader may be more than I can afford the time for. Maybe for a later date. One of the concerns is ease of field programming updates and the cost of the devices, but I do see and hear guys using 10 dollar ebay loaders with success so maybe that will not be such a concern. In reality the field updates would not usually be quartus files anyway, but spin.
I was wondering why you don't mate the P1/P1V to a second board and simply have a solid connector between the two? That would open it up for developers and prolong product life-time.
I use NTSC so I wouldn't need some of the features, but I would be interested in the board, simply because it has the HR... BUT having a P1/P1V doesn't suit my long term goals at all.
This is for a specific test platform, but at some point another PCB will mount direct on top with all the connections to the outside world. If you want HR, I can include a breakout for you and send it then you can connect it to whatever. For me, a single P1 is not enough for some things(cores and memory). Also I have wanted to learn about FPGA and the P1v makes it the perfect case for testing. With P1+p1v on the Max10m25, that should allow 16 cores and 32+64 io, and maybe on P1v a larger hub at some point. That holds me over for a year until P2.
Thanks for all the info. I glanced at each link and all of that is way over my head, and I think the learning curve to build the loader may be more than I can afford the time for. Maybe for a later date.
Makes sense to use an external module, to start with.
I see Quartus MAX10 docs say this
There are three file formats supported by the Quartus II software:
• JAM Byte Code ( .jbc ) file
• JAM ™ Standard Test and Programming Language (STAPL) Format ( .jam ) file
• Serial Vector Format ( .svf ) file
You could generate one of each of those, for P1V, and post their size and a snippet from each.
.SVF I have used for smaller CPLDs, and it seems simple to process, if somewhat verbose.
ie you would usually pre-process some of that in the PC, as a simple direct send involves many bytes of payload.
There are JAM/STAPL players for microcontrollers in C, and I found an 8051 version, (~4300 lines) that results in a 24k binary, which seems excessive.
I could not use the CP2105 for dual com usb. It only has 5 GPIO, 2 are already defaulted to tx and rx LED activity on one port, 2 are defaulted for LED activity on the other port. There is only 1 extra GPIO on Enhanced channel and it can only be controlled from enhanced channel, not both. I need two dedicated controls from GPIO on both to be able to have separate RESn controls, but there is only the 1 spare. So I put back the CP2110, added a mux/demux switch and now the Prop loader can tell GPIO to select P1 or P1V to program. I can also add the selector to my command line loaders, just rename one concole app the for P1, one for P1V, and then one of them holds the mux control line low, the other app holes it high. Very simple stuff to route tx, rx, resn.
I could not use the CP2105 for dual com usb. It only has 5 GPIO, 2 are already defaulted to tx and rx LED activity on one port, 2 are defaulted for LED activity on the other port. There is only 1 extra GPIO on Enhanced channel and it can only be controlled from enhanced channel, not both. I need two dedicated controls from GPIO on both to be able to have separate RESn controls, but there is only the 1 spare. ...
I'm not quite seeing that ?
(open drain is how they Tag In)
AN223 Table 4. CP2105 Default Settings TXD_SCI 21 Push-Pull 1 Win32 COM API or USBXpress
RXD_SCI 20 Open-Drain 1 Win32 COM API or USBXpress
RTS_SCI 19 Push-Pull 1 Win32 COM API or USBXpress
CTS_SCI 18 Open-Drain 1 Win32 COM API or USBXpress
GPIO_0_SCI 24 Open-Drain 1 Manually by Host
GPIO_1_SCI 23 Open-Drain 1 Manually by Host
GPIO_2_SCI 22 Push-Pull 1 Manually by Host
SUSPEND_SCI 1 Push-Pull 0 USB Device State
TXD_ECI 13 Open-Drain 1 Win32 COM API or USBXpress
RXD_ECI 12 Open-Drain 1 Win32 COM API or USBXpress
RTS_ECI 11 Open-Drain 1 Win32 COM API or USBXpress
CTS_ECI 10 Open-Drain 1 Win32 COM API or USBXpress
GPIO_0_ECI 15 Push-Pull 1 Manually by Host
GPIO_1_ECI 14 Open-Drain 1 Manually by Host
SUSPEND_ECI 17 Push-Pull 0 USB Device State
In default mode you have RTS_SCI and RTS_ECI for separate RESn control ?
If you flip using OTP, into Modem mode, then you gain DTR_SCI (Pin23) & DTR_ECI (Pin15) as 2 more outputs.
This OTP flip does need a Vpp cap, as per data (also see AN721)
On second look I think could use DTR. However, even still I think I like the idea better of not having to look at the ports and swap at that level/method, but rather have buttons on my loader that specifically state P1 and MAX, which toggles a free GPio to flip the mux/demux switches and routes tx/rx/RESn. This way is faster than selecting the port manually in a menu. Same for command line... just have two command line apps, one will have GPio8 LOW for the mux switch, the other has it HIGH. Or maybe I will add an argument to the command line app for the switch pin state. Makes for a nice clean switching arrangement. Except for the real estate and under .50 cent part, the method seems more elegant versus clicking on ports for selection.
On second look I think could use DTR. However, even still I think I like the idea better of not having to look at the ports and swap at that level/method, but rather have buttons on my loader that specifically state P1 and MAX, which toggles a free GPio to flip the mux/demux switches and routes tx/rx/RESn. This way is faster than selecting the port manually in a menu. Same for command line... just have two command line apps, one will have GPio8 LOW for the mux switch, the other has it HIGH. Or maybe I will add an argument to the command line app for the switch pin state. Makes for a nice clean switching arrangement. Except for the real estate and under .50 cent part, the method seems more elegant versus clicking on ports for selection.
Two buttons and command switch seems fine, but that can be done with CP2105. The Com pair are always adjacent, and in a predictable order.
If I was adding a MUX, I would tend to make it more useful, like MAX-JTAG or MAX_UART select, which means after MAX load, you have two UARTS available, one to each core. Maybe just a jumper can do that ?
Not sure what you mean, using USB Blaster, it will be always plugged into it's 2x5 pin port, so the JTAG will never get switched, unless I am missing something here? Whether using dual usb or single usb with mux switch between P1 and MAX10, I don't see other options needed for switching?
USB Blaster > JTAG 10 Port always plugged in if there is an intent to load Quartus
USB UART --------/ --- P1 rx/tx/resn pins
|
------/ --- MAX rx/tx/res pins
(switch)
Not sure what you mean, using USB Blaster, it will be always plugged into it's 2x5 pin port, so the JTAG will never get switched, unless I am missing something here? Whether using dual usb or single usb with mux switch between P1 and MAX10, I don't see other options needed for switching?
I was thinking ahead a little, to being able to eliminate the USB Blaster.
In that case, you would wire P1 pins to JTAG, and have a jumper to enable the P1-JTAG via the P1-UART pathway.
There are three file formats supported by the Quartus II software:
• JAM Byte Code ( .jbc ) file
• JAM ™ Standard Test and Programming Language (STAPL) Format ( .jam ) file
• Serial Vector Format ( .svf ) file
...
There are JAM/STAPL players for microcontrollers in C, and I found an 8051 version, (~4300 lines) that results in a 24k binary, which seems excessive.
I can't advise as to whether it will work or not. The device can be used as a JTAG host via USB. So, it certainly looks to be the part. However, you will have to consider what drivers you are going to use to control your on-board JTAG host and programming of the FPGA. You won't be able to rely on any Altera software/drivers for that. It's designed to support a USB-Blaster and not a custom solution such as you're proposing.
Finally got my P1+P1V MAX board to route on 2 layers. There are 2 HR on P1, 2 on MAX10. I made a special HR pad layout that includes my own routing brought out to pads. No ground plane added yet, still a few more things to tweak and inspecting for errors. Both P1 and MAX10 are brought out to headers, jumpered to all the parts, 220K pulldowns on Hyperam, SRAM, so they can be unplugged if pins are needed. I will make a HyperRam breakout, or maybe even tiny P1+Hyper with a 4 pins header for programming, a few leds and io to some headers. Hopefully we can get some of these little HyperRam breakout modules in a few guys hands in the next month, Ray may be very close. Still need to make a camera board and RS485 sender/receiver boards for testing long range camera transmission, will start on that soon. I have glanced at the FTDI>Jtag links but that stuff is so far over my head it makes my brain numb. That will have to be addressed down the road.
Finally got my P1+P1V MAX board to route on 2 layers. There are 2 HR on P1, 2 on MAX10. I made a special HR pad layout that includes my own routing brought out to pads. No ground plane added yet, still a few more things to tweak and inspecting for errors.
Looking good.
I would make the MAX 10 decoupling more radial, and get rid of the long blue lines, to try for the shortest possible leads from Pwr-Gnd PAD. Not sure you need dual caps, as with Ceramic Caps the PCB trace determines the ultimate impedance.
I guess if they fit, you can artwork then in, then build a board, check and remove one set & check again.
I have glanced at the FTDI>Jtag links but that stuff is so far over my head it makes my brain numb. That will have to be addressed down the road.
Comes down to what you have at hand, but that last OpenOCD link has some nice examples of what a OpenOCD+FT232H echoes with a JTAG connection - you just need the command line, not much more brain work...
I followed their Max10M08 eval board and used .1 and 1UF on all VCC_IO pads. They also put a cap at each VCC_Core, which are the 8 caps at each corner diagonal. Not sure which long blue lines you mention, you mean inside the pad for the bottom mounted .1/1uf VCC_IO pairs? I can recheck those. The VCCIO pin is direct to the cap via a via, very short distance. The GND side of the cap runs direct to the center pad, although not in a straight path. Those can be manual routed in a straight line to the GND center pad pretty easy. I can't put caps outside the pad, it creates log jams, must be inside to get completed route. Not clear on the radial part.
Comments
Maybe someone can clarify the HR concept with LCD. Here is what I assume:
1. Use P1 or P1V to read a full screen of data ( ie 800x480x16 / 8 = 768000bytes from SD to HyperRam1 and 2 at address. 565? 555? 444?
2. Clock the Hyperram starting at address and cycle that range for as long as the screen is active. Not really clear on how this works
3. Use LCD Clock Doubler XNOR to avoid using a counter or extra clock to get fast enough speeds, also used so the clock is only running when data is running.
Data from SD must be read in one byte or word at a time, then written a byte at a time to HR1 and HR2, simultaneously low byte high byte? To save pins use the same 8 pins or writing both HR's, but writes would be /2 speed.
8m / 768k = 10.41 full screens can be stored, all the software needs to do is jump to a different address to cycle for the HR to drive the LCD.
I added the SPI Flash 16m part to both MAX10 and P1 to learn how to use those and see what may be done in the future.
EVE2 is connected to LCD with jumpers, but HR will be jumperable as well once I see what the color config is.
Everything is routing on 2 layers.
Need to study oz and others methods of SPI Flash boot, MAX10 Flash boot. For starters EEPROM is the plan.
P1 and P1V both have a Micro SD and SPI Flash
P1 has RTC.
HyperRams will be jumperable to use either P1 or Max10.
Altera told me regarding FTDI FT2232H that I need to crawl before can walk. I assume that means we are not going to help you. No big deal for now. I like that dual CPxxxx USB device so 1 USB cable/port can program either P1 or P1V, but need to understand how to select either device. Maybe get an eval for it later.
? If you parallel the pins, for write, you need to separate them for LCD drive.
That depends on mode chosen..
There are two main approaches I see to HR use.
a) The simplest, is to use linear clocking, where you address once, and use DE to give any required LCD framing.
The unused RAM is simply skipped-over, but there is lots of it...
One down side of this, is the HR is display only, and (I think) unused areas are not refreshed.
That means multi-screen jumps are not so easy....
One appeal of this mode, is it should work even with P1.
Writes have to be done in inactive frame time, but you have 64ms within which to (re)read and write.
b) The more complex drive, uses a little verilog to drive HR in shorter bursts.
This can use a CLUT to do 8:16 colour drive, and the short bursts mean Auto-refresh manages the whole device.
Writes can be more frequent with this approach.
This could use one HR, but the P1V does do more work.
The second HR could be used for XIP designs, or you could pack more into the Display HR, and accept a little speed hit.
Plenty of choices and it's all just software ...
If you wanted to use CLUT that would mean separate pins to map LCD to FPGA.
That's what happens when you stare at the screen too long. Thanks for pointing out that obviosly the LCD must have the pins separated. Any thoughts on color bits per RBG? The 16 bits of data need to be spread out over 24 bits of input, not sure how to spread that out symetrically.
The HR>LCD testing is more to try out your ideas for non EVE2 use that may benefit you guys, I personally don't think I will use it for LCD, the EVE2 is cheaper than two HR+XNOR and it is ALL about screen changes for me, video, camera, button ani, etc. Also, changing pages seems like it will have a lag time of SD read > HR which will not suit my needs. FYI FTDI is sending me methods next week to show how to stream a camera to EVE2. If you have some specific ideas you want to try, I will try it but otherwise I will skip it as the HR seems like a significant PASM undertaking and timing challenge for which I am not qualified. I may use the HR's for buffering graphics, video from cameras, etc so I will learn them for memory purposes for sure.
Usually Green gets the extra bit
https://en.wikipedia.org/wiki/High_color
P1 has:
2 HyperRam Jumperable to io
2 FT25H16T 16M Flash Jumperable to io
MicroSD
MAX6634 Temp IC
MAX3430 RS485
S35390 RTC
P1V has
2 HyperRam Jumperable to io
2 FT25H16T 16M Flash Jumperable to io
MicroSD
Optional connections:
FTDI 813 EVE2 Video processor
Roving RN171 Wifi
Should be enough stuff to have fun with the 7" LCD.
What if there was a P2 build that fitted in the 10M25 ?
The only schematic I find is in the zipped documents at the top of this thread. Cyclone 5E. 16 Bit/pins from P1, plus 5 other pins. I can't tie up the 24 pins, or they would have to have switches on them. But, maybe a P1 module just for programming the MAX, needs a lot of study for this. Looks like on P1 they have a mux for a switch to route FTDI to either P1 rx/tx/resn or FPGA. I am assuming the P1 loader we are seeing here is only for FPGA programming of the quartus file, not a Spin binary. Also they include the P1 PASM loader Spin file. So, does this imply I can forget the USB blaster or any variant and just build my own P1 blaster? This seems very simple. The issue is finding 21io free or switching. I did not use any Slow speed io, or VREF io pins as they stated higher capacitance. But for loading? May be fine, also maybe the loader has a speed control built in to slow it down.
There are many boot choices for RAM based FPGAs offer, looks like that one is a 16b Wide, host-clocked - that's a good choice on a 400+ pin part, but maybe not so good on a 144 pin device...
The MAX10 also looks to have only JTAG as a choice, which could make it quite a lot of work to re-work the P1 to manage JTAG
ie Simple place 16b & issue clock, needs to have JTAG state engines added, and probably SVF support for erase.
A google of
Altera SVF programming using FTDI JTAG
finds quite a few mentions, including some github ones, so you may be able to leverage those ?
I did some work with EFM8 micros as UART-JTAG, I'll look for later..
Connecting the JTAG pins to the P1 seems simple enough, to cover choices.
Edit
Virtual COM Port (VCP) device drivers provided by Silico Labs allow a CP2105-based product to appear as two COM ports in PC applications.
https://sourceforge.net/p/ixo-jtag/code/HEAD/tree/usb_jtag/trunk/
which has various hardware platforms for JTAG and OpenOCD, but are a little old, and I see things like this :
- device/f32x: (currently unfinished) attempt to get the firmware running on SiLabs F32x USB controller
Pity it is tagged unfinished, as the EFM8UB1 (newest F32x) is a low cost USB pathway.
This file
https://sourceforge.net/p/ixo-jtag/code/HEAD/tree/usb_jtag/trunk/device/f32x/ReadMe/CDC_ACM_ReadMe.txt
says some info about Code size and speed tests, so it looks like round-trip data was functional, on a COM port basis.
EFM8UB1 comes in 8k & 16k, so the code in either SDCC or Keil looks to have headroom for JTAG IO drivers.
The code is compiled with Keil or SDCC. The conditional compilation on the code automatically detects the compiler.
The work space files, 'Keil_USB_CDC_skeleton.wsp' and SDCC_USB_CDC_skeleton.wsp', are provided for SiLabs IDE.
SMALL memory model Code size
Keil full version and 4K eval (SiLabs) 3754 Bytes (F320 and F340)
SDCC 2.6.0 #4290 (20060718-4290) 4105 Bytes (F320 and F340)
This implementation simply echoes back the TX output of COM port to RX port.
Following transfer speed was observed on loop back, simultaneous bi-direction transfer (WinXP SP2).
SYSCLK Speed (Kbytes/sec)
F320DK 24MHz 150
F340DK 48MHz 280
( EFM8UB1 is 48MHz, similar to F340 )
Though I didn't check about transfer speed of single direction transfer, it'll be much faster, from the record of bus analyzer.
Still, the FT2232H looks like the path of least work ( at a higher price).
eg
http://openocd.org/doc/html/Debug-Adapter-Configuration.html
and I also find this
https://github.com/emard/wifi_jtag
Interesting, and seems to have ok speeds (but I expect not as fast as FT2232H)
Or, for C code that might port to P1, maybe this ? (claims 3.3k binary?)
http://www.ethernut.de/en/xsvfexec/
http://www.ebay.com/itm/ALTERA-ByteBlaster-II-ALTERA-USB-Blaster-CPLD-FPGA-ALTERA-Download-Cable-JTAG-/271138629988
http://www.amazon.com/s/?ie=UTF8&keywords=usb+blaster+altera&tag=googhydr-20&index=aps&hvadid=82482628507&hvpos=1t2&hvexid=&hvnetw=g&hvrand=1558414238504746935&hvpone=&hvptwo=&hvqmt=b&hvdev=c&ref=pd_sl_7yfa3wmg8c_b
I use NTSC so I wouldn't need some of the features, but I would be interested in the board, simply because it has the HR... BUT having a P1/P1V doesn't suit my long term goals at all.
or... I could gobble up a short run:)
Any help is greatly appreciated.
Rich
Makes sense to use an external module, to start with.
I see Quartus MAX10 docs say this
There are three file formats supported by the Quartus II software:
• JAM Byte Code ( .jbc ) file
• JAM ™ Standard Test and Programming Language (STAPL) Format ( .jam ) file
• Serial Vector Format ( .svf ) file
You could generate one of each of those, for P1V, and post their size and a snippet from each.
.SVF I have used for smaller CPLDs, and it seems simple to process, if somewhat verbose.
ie you would usually pre-process some of that in the PC, as a simple direct send involves many bytes of payload.
There are JAM/STAPL players for microcontrollers in C, and I found an 8051 version, (~4300 lines) that results in a 24k binary, which seems excessive.
A simple colour up-convert would be to overlap from msb down onto the unmapped colour pins. Eg: To map 6-bit to 8-bit:
I could not use the CP2105 for dual com usb. It only has 5 GPIO, 2 are already defaulted to tx and rx LED activity on one port, 2 are defaulted for LED activity on the other port. There is only 1 extra GPIO on Enhanced channel and it can only be controlled from enhanced channel, not both. I need two dedicated controls from GPIO on both to be able to have separate RESn controls, but there is only the 1 spare. So I put back the CP2110, added a mux/demux switch and now the Prop loader can tell GPIO to select P1 or P1V to program. I can also add the selector to my command line loaders, just rename one concole app the for P1, one for P1V, and then one of them holds the mux control line low, the other app holes it high. Very simple stuff to route tx, rx, resn.
I'm not quite seeing that ?
(open drain is how they Tag In)
AN223 Table 4. CP2105 Default Settings
TXD_SCI 21 Push-Pull 1 Win32 COM API or USBXpress
RXD_SCI 20 Open-Drain 1 Win32 COM API or USBXpress
RTS_SCI 19 Push-Pull 1 Win32 COM API or USBXpress
CTS_SCI 18 Open-Drain 1 Win32 COM API or USBXpress
GPIO_0_SCI 24 Open-Drain 1 Manually by Host
GPIO_1_SCI 23 Open-Drain 1 Manually by Host
GPIO_2_SCI 22 Push-Pull 1 Manually by Host
SUSPEND_SCI 1 Push-Pull 0 USB Device State
TXD_ECI 13 Open-Drain 1 Win32 COM API or USBXpress
RXD_ECI 12 Open-Drain 1 Win32 COM API or USBXpress
RTS_ECI 11 Open-Drain 1 Win32 COM API or USBXpress
CTS_ECI 10 Open-Drain 1 Win32 COM API or USBXpress
GPIO_0_ECI 15 Push-Pull 1 Manually by Host
GPIO_1_ECI 14 Open-Drain 1 Manually by Host
SUSPEND_ECI 17 Push-Pull 0 USB Device State
In default mode you have RTS_SCI and RTS_ECI for separate RESn control ?
If you flip using OTP, into Modem mode, then you gain DTR_SCI (Pin23) & DTR_ECI (Pin15) as 2 more outputs.
This OTP flip does need a Vpp cap, as per data (also see AN721)
Two buttons and command switch seems fine, but that can be done with CP2105. The Com pair are always adjacent, and in a predictable order.
If I was adding a MUX, I would tend to make it more useful, like MAX-JTAG or MAX_UART select, which means after MAX load, you have two UARTS available, one to each core. Maybe just a jumper can do that ?
USB Blaster > JTAG 10 Port always plugged in if there is an intent to load Quartus USB UART --------/ --- P1 rx/tx/resn pins | ------/ --- MAX rx/tx/res pins (switch)I was thinking ahead a little, to being able to eliminate the USB Blaster.
In that case, you would wire P1 pins to JTAG, and have a jumper to enable the P1-JTAG via the P1-UART pathway.
I also find this
https://github.com/ASukhanov/StaplPlayer
which could be a great use for a $5 Pi Zero
I can't advise as to whether it will work or not. The device can be used as a JTAG host via USB. So, it certainly looks to be the part. However, you will have to consider what drivers you are going to use to control your on-board JTAG host and programming of the FPGA. You won't be able to rely on any Altera software/drivers for that. It's designed to support a USB-Blaster and not a custom solution such as you're proposing.
Still, there are pathways like OpenOCD that can use FTDI Jtag modes.
http://openocd.org/doc/html/Debug-Adapter-Hardware.html
and the lowest cost HS USB (single channel) JTAG would be via FT232H.
Adafruit has a FT232H breakout for $14.95
https://www.adafruit.com/products/2264
and of course, RaspPi is an option..
https://github.com/synthetos/PiOCD/wiki/Using-a-Raspberry-Pi-as-a-JTAG-Dongle
but I've not seen speed specs on that, and it's a little unwieldly.
Addit:
This blog
https://balau82.wordpress.com/2013/08/04/jtag-connection-with-openocd-and-ftdi-cable/
shows OpenOCD and a FT232H module, and the JTAG interactions up to auto-find, where it extracts target ID and Instruction register length.
I would make the MAX 10 decoupling more radial, and get rid of the long blue lines, to try for the shortest possible leads from Pwr-Gnd PAD. Not sure you need dual caps, as with Ceramic Caps the PCB trace determines the ultimate impedance.
I guess if they fit, you can artwork then in, then build a board, check and remove one set & check again.
Comes down to what you have at hand, but that last OpenOCD link has some nice examples of what a OpenOCD+FT232H echoes with a JTAG connection - you just need the command line, not much more brain work...