Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
|
Forum Index : Microcontroller and PC projects : PM: VGA USB version - no VGA....
Page 2 of 4 | |||||
Author | Message | ||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
aha - you have inadvertently answered my earlier question! all picomite VGA firmwares make use of the standard VGA pinouts (GP16-17, GP18-21). many thanks for finally confirming this Grogster - i would suggest reworking the PCBs you have as i suggested earlier, so that out-of-the-box they will run the picomite VGA+USB firmware without needing any VGA or USB keyboard configuration. cheers, rob :-) |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6787 |
We always attempt to include any important OPTION settings on the silkscreen where they won't get lost. Sometimes they won't fit though - on some of my smaller designs anyway. :) Once the OPTIONs are set there is no difference between the original pin layout and any other. Audio already moves around, as does an SD card or LCD display. They all have to be configured for the board. I don't expect beginners to build a PCB and not read the manual. The MMBasic platforms are not like good old boot to BASIC computers in every respect - they require more thought than that as, in many ways, they are far more advanced. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9115 |
Please stop making silly suggestions - you know not of what you speak. That would also kill the audio output. If Grogster wants to design a different board for the VGAUSB firmware that's fine but hacking a working design is crazy Edited 2024-03-02 20:07 by matherp |
||||
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3801 |
I can't see the point of that. I can readily set OPTION values as needed (I don't need them to be on the silk screen but hey that is great). Soldering is MUCH harder for me and uses time I don't really want to spend. It's like you're trying to fix (or add) problems that don't exist. There are multiple designs for a variety of reasons. It's good that the software can cope via some OPTIONs - I half-expected we'd have to recompile for each board (like the past, for me). John Edited 2024-03-02 20:18 by JohnS |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6787 |
Sorry Rob, but this was done to death when the PicoMite was first being designed. What do you do with a platform where all the GPIO pins are re-definable? You allow them to be re-defined - that way you get maximum flexibility out of the system as a whole. Being able to use different pins for the VGA is only bringing it into line with that philosophy. Gluing functions to fixed pins is a "Bad Idea" - even PIC chips are largely re-mappable now. No-one should be having a problem with this concept now. You can produce a system that's only for beginners with all options pre-configured. It's perfectly possible. It makes the system non-upgradable and locks it into one version of the firmware for life. The function of every pin is fixed so that the little dears never have to worry about anything apart from programming in BASIC. It's a good way to get a load of boards consigned to the skip after a couple of weeks. :) . Edited 2024-03-02 20:19 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
"you know not of what you speak": well, actually i do. two VGA pins (HSYNC and VSYNC) need to be moved in order to allow the VGA output to work out-of-the-box without need for configuration. but this conflicts with audio, which needs to be moved somewhere (anywhere) else. this will (hopefully) ensure the PCBs will come up immediately (VGA+USB keyboard) without configuration. the user will still need to configure RTC, SD, audio, but at least they can see what they are typing! I would, indeed, suggest Grogster design his own board, so that it will run with the firmware as-shipped without need for configuration or cutting and rerouting traces. cheers, rob :-) Footnote added 2024-03-02 20:38 by robert.rozee just to clarify, i am talking from the perspective of the hundreds of boot-to-basic picomite boxes using Geoff's original design published in Silicon Chip Magazine. these should run the VAG+USB firmware by simply plugging a USB keyboard into the micro-USB socket on the back of the box. if wished, a USB to serial bridge can then be plugged into the PS/2 socket on the back for connection to a PC. cheers, rob :-) |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9115 |
Since this board is the reference design for the CMM1.5 I fully reserve the right to change the VGAUSB firmware to suit the board and come up fully configured so watch this space |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6787 |
If you loaded a MSDOS machine with Windows 3.1 did it work with absolutely no changes to CONFIG.SYS and AUTOEXEC.BAT? Why shouldn't the user have to put in some effort when loading a system a new version of its firmware? This isn't rocket science and you should be working to the manual that corresponds to your new firmware. You should expect things to be different. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
strictly speaking the reference design came from No0ne and myself, see: https://www.thebackshed.com/forum/ViewTopic.php?TID=16545 and https://github.com/No0ne/hid2cdc which split the firmware tasks over two picos: one providing VGA etc, the other providing USB peripheral support. you simply took the concept from the above github repository and combined it with the existing picomite VGA firmware. as such, your work is derivative. the 'reference design' is the existing picomite VGA as used on Geoff's original published boot-to-basic design and a USB keyboard attached via TinyUSB running in host mode. it was good of you to place a pre-configured serial console onto GP8/GP9 so that an existing PS/2 keyboard connector (as on Geoff's design) could be repurposed for connection to a USB to serial bridge. Peter - i hope you don't plan on deliberately breaking things, just to prove a point. cheers, rob. |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9115 |
As it happens I produced the first VGA board taking a Pico and defined the "standard" pinout. Geoff took this and simplified it for publication but don't let facts get in the way of your biases. Edited 2024-03-02 23:22 by matherp |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
that kinda makes it even worse Peter - you created a 'standard' a couple of years ago, then, after everyone adopted it, are now suggesting you will make an arbitrary change to break PCBs that followed it. Mixtel90 has suggested that this is to simplify PCB routing, but that really doesn't fly in the days when the cost of double-sided PCBs is peanuts. and, of course, if you go for preconfiguring the VGA sync on GP23 and GP24 then you exclude using the official Raspberry Pi Pico module (that is, without either needing to configure 'blind', or, attaching to a PC via a USB to serial bridge, running a terminal emulator, and typing in an over-riding configuration. all very un-boot-to-basic'ish). cheers, rob. Edited 2024-03-02 23:39 by robert.rozee |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9115 |
The VGAUSB firmware uses GP16 and GP17. You are arguing about the fact that Grogster missed typing "OPTION VGA PINS GP23,GP18" as written on the board. Let's leave it at that and don't suggest anyone starts hacking a designed PCB in order to avoid typing 25 characters ONCE |
||||
lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3150 |
I got the same model PCBs from JLCPCB and all were successfully flashed with the (then) latest VGAUSB firmware. 4 worked for everything I tested, including VGA (after setup using the OPTIONs printed on the PCB). The fifth had the blinking heartbeat LED, but no console. When I connected pins GP8 and GP9 via a USB-TTL module, I had console in TeraTerm. Per suggestions by Peter and BigMik, I found that R31 was 2k8 instead of 5k1. This may or may not be the problem, and I may or may not find out whether it is following BigMik's suggestion about replacing R31, since I may just put the PCB in a drawer unless I find a need for it. A lot has happened with the Pico in the past 6 months or so. It's hard to keep up with Peter's productivity. It's a problem I'm happy to have. ~ Edited 2024-03-03 00:23 by lizby PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6787 |
I suggest that you keep well clear of PicoGAME 4, Rob ;) The VGA is on completely the "wrong" pins. Two of the ADC pins control the SD card. The other ADC pin is an Atari joystick Fire button. and audio is over an SPI codec using 7 assorted GPIO pins. It also runs "standard" USB VGA version MMBasic. Consequently there are OPTIONs that you *have* to play with to make it work (as well as a solder blob and five hardware jumpers). :) You'll probably explode if you use it. ;) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9306 |
Guys, guys, guys - lets not turn this into a flame war. It was MY mistake, and I see now where I went wrong. That's all I needed to know. Frankly, I'm surprised I did not think to just turn the board over and check if there were specific options, but I just ASSUMED that the standard VGA firmware would work, cos I was unaware that there WAS a new option for changing the VGA pins - I assumed that was pretty-much a standard configuration of pins. ...but you know what they say about assumptions.... I will make sure I use the latest FW(will reflash all four boards), and once I put in the option I need but did not realize it, I am sure it will spring to life. Smoke makes things work. When the smoke gets out, it stops! |
||||
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9306 |
I've flashed the correct FW into the board, but I can't connect to the terminal. I assume I use the USB-C port. Assumptions again! This time, I did check the bottom of the board, in case it mentioned something about how I have to setup the terminal. I'm going now to re-read the thread about this board to see if I can pick up something there. Smoke makes things work. When the smoke gets out, it stops! |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6787 |
You connect to the terminal using the USB-TTL converter after flashing the firmware. You'll have to set your terminal to 115200 initially (it's not via USB into the Pico so the setting has to be done manually), but you can change that setting with an OPTION later if you wish. . Edited 2024-03-03 08:53 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1611 |
I found this from Peter's exchange with Bleep: MAKE SURE THE TERMINAL PROGRAM IS SET TO 115200. It tells the CH340 what baudrate to use on the TTL side over the USB descriptor. This is not the same as a CDC port where the baudrate setting doesn't matter Bill Keep safe. Live long and prosper. |
||||
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9306 |
I am connected using the USB-C cable right now, but setting 115k2 baud does NOT result in any talking. This is how I am setup right now - no talkie.... Edited 2024-03-03 09:10 by Grogster Smoke makes things work. When the smoke gets out, it stops! |
||||
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9306 |
Is it permissible to short out pins 2 & 3 on the CH340, to perform what they used to call a loopback test? I just want to make sure that doing that, would not upset the 2040 chip in some way. But doing a loopback test would allow me to find out if the 340 chip is actually working or not. Smoke makes things work. When the smoke gets out, it stops! |
||||
Page 2 of 4 |
Print this page |