 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 : Configuration ID depot
| Author | Message | ||||
| zeitfest Guru  Joined: 31/07/2019 Location: AustraliaPosts: 482 |
The increasing configuration flexibility of micros is creating a bit of a chicken-and-egg problem. Developing software requires something to test on, there are often supply problems where often there are alternatives available but not the specific model needed. and designing a pcb to fit existing pin connections means fishing through a lot of possible combinations and designs. It might be useful to come up with a naming system and/or depot of configs so that the details can be found easily via searches (?). Maybe an id of initials/company + number + pcb ref with a page that then lists the pins config. Eg I found a basic pi2350 config which was useful for a quick hack assembly, It just used wires without a pcb. As it happens it worked across pico 2, pi Moroni Tiny, pi Moroni LGA-2350. [Don't know about MMBasic.] Without an id it makes it hard to reference it or the details. GP4 (spi0)RX GP5 (spi0)CS GP6 (spi0)SCK GP7 (spi0)TX GP12 (i2c0)SDA GP13 (i2c0)SCL |
||||
stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2109 |
 |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6766 |
The golden rule is *always* use GPnn numbers for everything in MMBasic if you can (there are cases where you can't). What a particular pin *does* is (usually) decided in software now. That makes it *much* easier to lay out PCBs. For maximum software compatibility you have to start being clever, but that's the price to be paid for having flexible hardware. You *could* fix hardware pins to specific jobs, but PCB design gets difficult and you may even run out of pins because there are more possible functions than available pins now! 16 pins gone on 2xSPI, 2xI2C and 2xCOM. MMBasic now contains the OPTION system that will auto-configure it for any board that has been registered. That seems to sort out the firmware. After that it's the hardware. At the moment you won't find one board that can do VGA and DVI. I've done one that you can build as alternative versions and Alpha is half way to being able to be easily modified to change it over from one to the other. Of course, it doesn't support PS2. :) NOTE: Pin *names* in the Pico documentation are from the RP Datasheets. The names used in MMBasic give a high degree of compatibility with previous versions. There was a lot of discussion about this in the early Pico days. e.g. the Micromite has I2C and SPI - only one of each. The Pico Datasheet has I2C0, I2C1, SPI0 and SPI1. If those had been used then Micromite programs would all have had to be changed. Hence I2C, I2C2, SPI and SPI2. Edited 2024-10-03 06:28 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 482 |
The situation I am addressing, is developing software for a micro with a lot of configuration possibilities but is very new. You want the software to be runnable on a fair number of pcbs and modules, which will be developed by others. When the info about the connections used by those pcbs/modules becomes available it is usually not available in a standardized way, meaning a slog through a slow feed of sometimes hundreds of pages and posts, often without readable schematics or even searchable ascii text. So what I am suggesting is identify some generic config states, labeled with id's of some kind, that can be found by search engines easily. Eg I wanted to develop software for a rp2350. I used a very basic wiring, with spi accessing a sd card and also an i2c two wire bus, so, a defined configuration. So I identify that configuration with a unique standardized label and post it. eg a label "rp2350[sd/i2c]0spi4.5.6.7,0i2c@12.13(xyz001)" which identifies the micro, the functionality used, the pins used, and initials and number xyz001. This would be used on a description post or page somewhere to be collected by search engine. To search for compatible boards etc the label can be used. And then when it comes to comparing or discussing the particular config eg to say whether a pcb is compatible or not, the config label can be used instead of trekking through the details. Just a thought and it needs development but it would be so useful. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6766 |
Sheesh.... you need AI to make it readable. ;) I'm not sure that it's worth the effort TBH. It tells you which pins are configured to which module but not what they do. e.g. if both SPIs are used which is a display and which is a VS1053? or maybe it's a DAC and not a VS1053? Or maybe two SPI displays but one has a different CS pin that can't be included in the configuration because it's normally used for an onboard heartbeat LED? You still have quite an effort in sorting out the hardware side. There is no substitute for documentation, be it for hardware or software. I decided ages ago that if the latest clever board hasn't got a schematic available then it's not worth considering at all. I almost always document my boards for the same reason - at least I try to make them usable. I expect the same from software. If there is no documentation (it can be program comments) that tell me how to get it to work at a sensible screen resolution, for example, then why bother with it? The writer obviously wasn't bothered if it ever got used by anyone else. The Olimex board is an example. You are told which *signals* are on which pins of which connector but unless you look at the circuit diagram that info is useless. You can't allocate the pins based on signal name alone. Their user manual should tell you which GPIO is connected to which pin of which connector. That's a documentation failure and it can't be resolved by any sort of configuration code. (TBH the info may well be supplied with the board! I haven't got one but I have got the circuit diagram. Please take this as just an example - other boards have screwed up like this in the past.) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4221 |
Hi zeitfest, Since I looked into the RP2040 controller issue, I completely understand your problem. There are (see thread about standardization) as many configurations as there are people on this forum. Me included. And with RP2350 added to the portfolio, that will only get worse. If you want to run a program someone else made, you have to search through the source code where initializations happen. Sometimes in the first few lines, sometimes in a SUB, and sometimes initilization changes depending external causes. For OPTIONs there was a method developped by Peter, so save your configuration. Tom proposed some standard way to store configurations (on A drive?, can't remember). Fact is that 3-4 years ago there where only few platforms (i.e PicoMite VGA Design 1 and VGA design 2 are the same except for audio). But now it is becomming a real problem. And some board even have jumpers (Murmulator / Peters new reference design for HDMI/USB) to increase the confusion (Peter: this is not critisizing the choice, but mentioning the effect). So... if you come up with something we can adhere to, feel free to issue. A text string as you propose could very well be a solution. It only needs a parser. @Mick: Maybe you are biased that you are easy with interpreting schematics. Some are not that gifted. Regards, Volhout Edited 2024-10-03 23:55 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6766 |
I realize the bit about schematics, the point is that there shouldn't be any need for the user of a board to need to use one. It's all very well saying that a pair of pins are allocated to SDA0 and SCL0 but those names are only valid for the language the board was designed for. Saying that they are GP0 and GP1 allows you to configure them in any language you like as those names relate to the processor, not the language. This is very important on the RP2350 as, across 48 IO pins, you have 12 pins that can be SDA0 and twelve that can be SCL0 - and you don't have to use adjacent pairs. :) PicoGAME SPGA would be an interesting config string when you get to the joystick/controller/I2C/COM port that can use any combination of GP0,GP1,GP2,GP3,GP45 and GP46. The latter two are also COM1 for the ESP8266 and ADC pins on the back and alternatives for pins 5 and 9 on the controller port, which are usually GP4 and GP5. Or something like that. :) It might do SPI too, but I haven't checked that. :) And that's without hacking the board. You see why documentation is important? (Even I'm confused. Goes off for a coffee and a couple of dried frog pills.) The thing is, the Pico is designed to be an embedded controller. As such it's IO never changes once it's installed. It's us that are "using it wrong". The same goes for the Arduino and microcontrollers in general. SBCs like the Pi are far less dependent on their GPIO for interaction with the user and are far less configurable in that respect. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 482 |
the reasoning in the label "rp2350[sd/i2c]0spi4.5.6.7,0i2c@12.13(xyz001)" is rp2350 - micro name sd/i2c - what function the connections are intended/used for 0spi - spi channel 0 4567 - pins used for spi0 ( in a usual order eg CS,MOSI,MISO,SCK etc) 0i2c - i2c 0 12,13 - pins 12, 13 used for 0i2c ( in a usual order eg SDA,SCL ) vyz001- originator initials and a sequence number. So a pcb might then be described as "xyz001 - compliant" or such, searching for xyz001 or the full string would then turn up the full label string and the info would be there. It certainly is clunky  , it is only a first thought. Maybe a json syntax is better but that would then be less practical  |
||||
| zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 482 |
Maybe json is better, (I can already see there should be peripheral power included) (??) eg including alternate labels so for a sinple pico2 with attached sdcard and I2c socket, something like [ ecdid is "electronic configuration definition id" ] { "ecdid": "xyz00143a", "cpu module": "pico2", "powered by": "usb", "micro": "RP2350A", "spi_buses": [ { "spiid": "spi0", "RX": "GP04", "SCK": "GP06", "TX": "GP07", "MISO": "GP04", "MOSI": "GP07" } ], "i2c_buses": [ { "i2cid": "i2c0" } ], "peripherals": [ { "sdmodule": "sdmicro", "bus": "spi0", "D8": "CS", "D7": "MOSI", "D6": "MISO", "D5": "SCK" } ], "connections": { "GP04": "spi0 RX", "GP04": "spi0 MISO", "GP05": "spi0 CS", "GP06": "spi0 SCK", "GP07": "spi0 TX", "GP07": "spi0 MOSI", "GP12": "i2c0 SDA", "GP13": "i2c0 SCL" } } Probably too much effort for little benefit  |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6766 |
Now it definitely *is* getting too complex. I've heard of JSON but never used it in my life! I've manage to ignore it so far. :) It would take longer to create the JSON for some of my boards than it does for me to design them. ;) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
 Print this page |
