Open UniquePete opened 4 years ago
"Heltec LoRa" is too specific to use for a parts family name. There are (at least) "Wireless" and "radio" existing family names that might suit this. See what properties, elements, tags, etc are being used in those. Label needs to be much shorter. See what other parts are using. Something like "radio" or "lora" (or LoRa), or "WiFi". Given the tags you used, generic radio is in the right area. That seems to have/be multiple radios.
The other new part pull requests have much the same comments. The properties and other elements have meanings. Filling them in appropriately to work with other similar parts will make everything more usable. Instead of having them off by themselves, where the user has to know exactly what the part is they want to use, to be able to find them.
Per my other comments, this is all very new to me. I was not aware of the details you are describing in the structure. I would like to think that there was some consistency in the parts that I've done, but if there's a problem with one that problem will most likely appear throughout. "Heltec LoRa" was just the 'family' name that Heltec gave the products in question. I used that description only because I didn't know any better. I'm not wedded to any of the internal stuff in these files at all—I imagine that much of it was created automatically through the Parts Editor (although I do know now how to edit the individual files, if not exactly what it is that I should be inserting where).
If you can tell me specifically what descriptors I should be using, I'd be happy to make the necessary changes, or I'm happy for anyone else the make them. I get what you're saying, but at this point I simply don't have a big enough picture to understand what descriptor might be more or less specific.
OK, following our discussion on the Pro Mini, is the following an appropriate amendment to the intitial elements of the .fzp file in this case?
<title>Heltec WiFi LoRa 32 V1</title>
<date>Fri Mar 6 2020</date>
<tags>
<tag>Heltec</tag>
<tag>ESP32</tag>
<tag>SX1276</tag>
<tag>WiFi</tag>
<tag>LoRa</tag>
<tag>BLE</tag>
</tags>
<properties>
<property name="family">Microcontroller Board (ESP32)</property>
<property name="type">Heltec LoRa</property>
<property name="part number">HTIT-WB32LA</property>
<property name="pins">36</property>
<property name="revision">V1</property>
</properties>
<taxonomy>part.devmod.36.pins</taxonomy>
<description><p>
The Heltec WiFi LoRa 32 is an IoT development board designed & produced by Heltec Automation. It’s a highly integrated product based on the Espressif ESP32 and Semtech SX127x modules. The board includes WiFi, Bluetooth and LoRa functions, as well as a 0.96″ OLED display and a Li-Po battery management system.
</p>
<strong>Links: </strong></p>
<ul>
<li>
<a href="https://heltec.org/project/wifi-lora-32/" target="_blank"> Heltec WiFi LoRa 32 product page</a>
</li>
<li>
<a href="https://github.com/HelTecAutomation" target="_blank">Github </a></li>
</li>
</ul>
</description>
Given that description, this part is quite unique to Heltec. Nobody else is making a board that can be (nearly) direct swapped in an existing circuit. With that assumption, specifying the actual part number and product links makes sense. I assume the "V1" is the Heltec board revision number. Again, just from reading the description, IoT and LCD (or OLED) are possible additional tags.
There is also a <url></url>
element, but I have never used it, and not researched how it is intended to be used.
There are currently no parts with family "Microcontroller Board (ESP32)". There is a family for "Microcontroller Board", which could be used, and specify ESP32 in properties someplace. I did not find any parts with esp32 in the family. I did find families for "ESP8266", Espruino", "Gizwits WiFi Witty ESP-12F". The last looking too specific. The existing microcontroller board families are:
<property name="family">microcontroller board (arduino compatible)</property>
<property name="family">Microcontroller Board (Arduino)</property>
<property name="family">microcontroller board (arduino)</property>
<property name='family'>microcontroller board (arduino)</property>
<property name="family">Microcontroller Board (Basic Stamp)</property>
<property name='family'>microcontroller board (blueIOT)</property>
<property name="family">microcontroller board (blue pill)</property>
<property name="family">Microcontroller Board (GogoBoard)</property>
<property name="family">microcontroller board (intel)</property>
<property name='family'>Microcontroller Board (Jeelabs)</property>
<property name="family">microcontroller board (lilypad)</property>
<property name="family">Microcontroller Board (linino)</property>
<property name="family">Microcontroller Board (MBED)</property>
<property name="family">microcontroller board (mbed)</property>
<property name="family">Microcontroller Board (Netduino)</property>
<property name="family">Microcontroller Board (PICAXE)</property>
<property name="family">Microcontroller Board</property>
<property name="family">microcontroller board </property>
<property name="family">microcontroller board</property>
<property name="family">microcontroller board (seed studio)</property>
<property name="family">microcontroller board (seeed)</property>
<property name='family'>microcontroller board (sodaq)</property>
<property name="family">Microcontroller Board (Teensy)</property>
<property name="family">microcontroller board (teensy)</property>
<property name="family">microcontroller board (texas instruments)</property>
<property name='family'>microcontroller board (Udoo)</property>
<property name="family">Microcontroller Board (Wiring)</property>
That said, I did not check how many different parts are in each family.
So, I do not see any problems with information shown, but I have also not researched what the other microcontroller board families look like. Just looking at the existing list, I suspect that some of the more specific families should really be part of the "Microcontroller Board (Arduino)" family, with tags and properties used for differentiation.
Yes, the V1 is a specific Heltec number (well, there was no V1 really, it was just the first one—there is a V2 now though, so people are referring to the original as V1), and I have also submitted a V2 part, which has a slightly different [logical] pin layout, so the image files are slightly different.
The ESP32 is the follow-on product to the ESP8266 (both from Espressif). but while it is functionally similar to the ESP8266 at one level, it is a 'next generation' product and I think it would certainly warrant being considered in its own right, rather than under an ESP8266 banner. So maybe ESP32 alone would be sufficient, but that woul;d really be like describing the "Microcontroller Board (Arduino)" as simply "ATmega328" or whatever processor is involved. I really haven't been playing this game long enough to make any call on that one. If the 'family' is about specific processors (ATmega328, ESP8266, ASR6501), you might fall one way, if it's about overall functionality, you might fall another.
To give this discussion a little more context, I have submitted parts for V1 and V2 versions of this ESP32 board, Wireless Stick and Wireless Stick Lite boards, which are also ESP32 based, and the CubeCell, which is based on the ASR650x processors. All of these are Heltec products, and all described, by them, as part of their "LoRa Series". So do these processor modules rate their own family, should they be split according to their processors, or grouped according to the fact that they are all 'Arduino IDE programmable'?
Start with the summary:
Not being very helpful here. Not enough information to (with confidence) narrow the choices. I find nothing wrong with what you propose, but no solid reason to say it is the obvious right choice either.
I am familiar with the different ESP boards/chips. I was just reporting what I found in the existing parts that might be a reference point to get started from. And yes, ESP32 is quite different from ESP8266 for most contexts. Since it is programmable using the Arduino IDE, including "arduino" in the tags makes sense. Putting it in the (Arduino), or (arduino compatible) families is not as obvious of choice. I just did an additional search. There are no references to "esp32", "esp 32", "esp-32", "esp_32" in any of the existing parts. There a few esp8266 references. It looks like nobody has been creating parts for these before. Which leaves it fairly open on how to proceed. Other options start with the wireless and radio families, and use properties and tags to fill in more details. Choices depending on knowing about the capabilities and target market/usage of this part (which I don't have), as well as research in the existing parts to find things that are context/conceptually related, then matching up the metadata for similarities and differences. While evaluating how appropriate the metadata for the existing parts is. More time than I can dedicate to it for now. With the search finding almost nothing to use as a base, the search needs to be widened, and the cross checks get more manual and time intensive. If there are some existing parts that this should be grouped with, or setup "parallel" to, the search words I used did not find them. So either there really is nothing, or I am using the wrong words. Though if something was there, the global search for esp should have found more. There are only 24 part files found with "esp" in them anywhere. Some of which are probable bogus for this context.
Which says there is little or nothing to compare to, and general concepts need to be the guide. There are only 3 parts in the "microcontroller board (arduino compatible)" family
electron_board.fzp
PHOTON_fix.fzp
SPARKCORE_v1_fix.fzp
4 parts in the "radio" family
NRF24L01_fix.fzp
Si470x-Eval-v11.fzp
SI4735 Shield-v13.fzp
sparkfun-rf-rfm22-smd.fzp
7 in "wireless"
ArduinoBluetoothMatev13.fzp
gs1011_breakout-v11.fzp
HC-05-male_fix.fzp
RN41-v14.fzp
WiFly_Shield-v17.fzp
XBee-Regulated-v12.fzp
xbeeshield-v13.fzp
4 with "esp" in the family name
ESP8266_7.fzp: <property name="family">ESP8266</property>
ESP8266_module.fzp: <property name="family">ESP8266</property>
EspruinoPico_8fb644a5b6642112445ed6d90bc494d8_6.fzp: <property name="family">Espruino</property>
Gizwits_WiFi_Witty_ESP_12F.fzp: <property name="family">Gizwits WiFi Witty ESP-12F</property>
Just not a lot to match to, and most of that, from the part file names, is not even close to the esp32 board. The "ESP8266" family comes closest, but with only 2 existing sample, need to think carefully if they were done correctly, meaning creating an ESP32 family, or if there is a better way to categorize these type of modules. The ESP32 is (I believe, no experience) more powerful, more programmable than the ESP8266. So moving over to the microcontroller set of families might be appropriate. Something like "microcontroller board (wireless)" to potentially group some similar functionality together. Later, since nothing exists right now. Or the specific "microcontroller board (ESP32)", like some other family names from that group. Which I tend to feel (no solid reason) are too specific. They should be part of the base "microcontroller board (arduino)" family, or everything in that family should be put in more specific families instead.
Whatever the outcome of the discussion will be, I don't see it as a blocker for including the parts to the develop branch.
Things might also clear up by obsoleting boards that are EOL, and by not showing obsoleted parts in the Inspector by default.
MCB are not interchangable most of the time, as they differ in physical layor or microcontroller, or both. If a manufacturer managed to establish a standard or a certain palette of very similar parts, that should be honored by collecting them in one family. Everything else can be done by the free text search. eg. entering ESP32 in the search field should list all matching boards. I don't see a sense in putting ESP32 and ESP8266 in one family. Oh, by the way, shouldn't it point out that is ESP32-E or ESP32-F or later?
I was not (intending to) suggest putting the ESP32 in the ESP8266 family. I was just looking for what had been done elsewhere, for something similar, to get an idea what might me appropriate for this case. Trying to get an idea what the 'meta' rule should be.
If a manufacturer managed to establish a standard or a certain palette of very similar parts, that should be honored by collecting them in one family. Maybe. However, in the 'clone' context, those are often deliberately using the same form factor as other boards. With (sometimes) minor differences in pin counts and positioning. Effectively they are just a different revision. They belong in family the are cloning, not a new family for the manufacturer.
Depends on the context/project to whether the MCB are interchangeable or not. If the project needs to (only) talk to SPI or I2C devices, the form factor may not be much of a consideration. In other cases, overall size, power consumption might be important, but not so much the layout of the actual pins. With the "higher level" modules, it gets tricky to decide what should be grouped together as a family. Even that family of led matrixes did have incompatible parts in the family, depending what is needed for the project. Physically different sizes, different pin row spacing, common cathode version common anode. The variations for the different pcb pad sizes is directly swapable, but the the rest is not. But they are still all "matrix display" family. Some fairly major part of the design needs to change when switching between family members. The same is true for the boards. If all you need is a little processing power, and a bit of I/O, many of the boards will work. Some will be overpowered, oversized for the job, but they would work. The interface to the rest of the project might be only 3 wires. 5 with power and ground.
Yes the version of the ESP32 should be included in the information someplace. Tag or property. Perhaps an ESP32 (or m b (ESP32)) family, with a chip, or core, or processor property that shows the revision. Or at least in the description. There are boards in the Arduino family with different processors. They are 'arduino' family because they are setup to be easily programmable by the IDE, and a lot of code that runs on one will run on the others with no changes.
Getting rid of EOL parts sounds like a good idea, but do not do it too soon. Given some of the users (hobbyist), they could well be wanting to do projects with old parts left around. Things that are EOL do not go away. IE5.5 is still showing up in the statistics for web browser usage at https://caniuse.com/usage-table Not much, but it is still there as its own entry.
What happened here (with the checks)?
Hi, this is interesting conversation. I am happy to help however I can to resolve and happy to contribute the part to the core to give back to the community. I am still getting up to speed on this stuff so I will follow your lead. Thanks!
Heltec WiFi LoRa 32 V1 development board (update & rename of superseded version)