Not a lot more than that, I would recommend the latest versions of each library listed in platformio.ini for each part (some of them are built-in libraries as well)
Thanks Mike. I bit the bullet and have been learning PlatformIO. I forked your project here: https://github.com/FrightRisk/BaseStation and cloned it to my local drive to work on. I'm still a bit unclear on all the structure of PlatformIO, is there something else I need to do to make the project work? There is no "main.cpp", so do I just use "open folder" and select "DCCPP_UNO" and start working? I guess I thought if you were using PlatformIO to do the development on this I would just do something like "file, open, <project name>". Since I'm still learning this IDE, I'm unsure of best practices to work on it, push it back up to Github, and have it be downloadable for others. I am also concerned about it being agnostic because when I created a test project, it created a pio folder and references the board I chose to develop for (a Mega). I am guessing that may not be necessary and I can add that folder to .gitignore? Ideally, I'd like someone to be able to download the project and simply open it, select their board and config.h options and click a button to upload it to their board (and maybe have to install a library or two). I appreciate all your help.
The .pio folder should definitely be added to the .gitignore file. The board designation is done inside the platformio.ini file, the end user will need to alter this file to specify it themselves. If you are using VS Code you will want to add the DCCPP_UNO folder to the active workspace by right clicking in the left column (where project folders show up) and then do the same for the ESP project. PIO will then "enable" it's functionality for that project directory and build that project when you click it's build/flash/etc buttons as long as you have a file opened from the project you want to build. You could also convert it back to two Arduino IDE projects with some ease, I converted it to PlatformIO at the time as it was a lot more flexible than the Arduino IDE but the full features of PIO are not being used today.
Can you elaborate? I imagine it still is worthwhile for coding just for autocomplete and a few other things, but what reduced its usefulness? Also, there is just something I was in sensor.cpp. There is an unused variable "Sensor *t", should it be removed or should it be "*tt" and be used for tt=Create(), tt=remove(), tt=show() Code: void Sensor::parse(const char *c) { int n,s,m; Sensor *t; switch(sscanf(c,"%d %d %d",&n,&s,&m)){ case 3: // argument is string with id number of sensor followed by a pin number and pullUp indicator (0=LOW/1=HIGH) create(n,s,m,1); break; case 1: // argument is a string with id number only remove(n); break; case -1: // no arguments show(); break; case 2: // invalid number of arguments CommManager::printf("<X>"); break; } }
There are a number of extra features that PIO provides that are not currently used by the Uno/ESP projects. The biggest feature that is being used is the library dependencies are "fixed" via the PIO library manager whereas the Arduino IDE side it is a bit less strict on the versions. That line in Sensor.cpp can likely be removed.
One more question, how might I grammatically fudge input to this function and print out the values of the things referenced here for debugging. What data would I put into "s" to make a valid packet? Something like : char s[] = {'1','2','3','4','5'}; writeTextPacket(s); Code: void RegisterList::writeTextPacket(const char *s) volatile{ int nReg; byte b[6]; int nBytes; nBytes=sscanf(s,"%d %x %x %x %x %x",&nReg,b,b+1,b+2,b+3,b+4)-1; if(nBytes<2 || nBytes>5){ // invalid valid packet CommManager::printf("<mInvalid Packet>"); return; } printf("%d\n", nBytes); printf("%d, %x, %x, %x, %x, %x", &nReg, b, b+1, b+2, B+4); loadPacket(nReg,b,nBytes,0,1); } // RegisterList::writeTextPacket() I was going to try to get rid of warnings with changing %x to %p and adding pointer to a pointer with void**: sscanf(s,"%d,%p,%p,%p,%p,%p", %nReg, (void**) b, (void**) b+1...)
%x is to read a hex number, %p is a pointer. They are not the same as far as sscanf. I don't know if there is any easy fix.
In the last verion of the Uno/Mega version, there was this line in config.h: BTS7960B (MAX 27V/43A PER CHANNEL) in the current ESP32 version it shows a BTS7960 5A and a 10A board. Can anyone help me understand how many of these BTS7960B boards there are and why a 43A version is supported or was started, but now there is only a 5A and 10A version? Are these particular boards from particular manufacturers or any BTS7960B board?
The BTS7960B supports a maximum of 43A. On the Uno/Mega code it defaults to ~5A limit via this code but can be swapped for 10A by switching the code to have 10A instead of 5A at the end. Also you can not do a direct comparison of features from the Uno/Mega code to the ESP32. The BTS7960 h-bridge is only manufactured by one company *BUT* it has been built into many variations of devices and in theory they all should work.
Thanks Mike, and I know the 2 versions are not very similar coding wise. I've been going through the ESP32 functions and there are a lot of custom ones to handle motor boards in particular. It is amazing work since if doesn't seem you have re-used much of the DCC++ code, even the code you added to the Uno/Mega version! I think when people really see what this version can do, especially with the custom board, it should really take off. In the meantime, I'm going to plug away to update at least a few things, like more motorboards, to the Uno/Mega version. I found what I was looking for in the ESP32CommandStation/include/Config_MotorBoard.h file where there are notes about the boards. I really wish configuration was as simple as uploading an xml or json file to the Mega to change configurations without having to build all the time. I know it isn't something one would do often, but for non-programmers, a better way to change settings would be great. I saw something Json in your ESP32 code. Do you have plans to set this all up from the screen and selecting things and then saving to EEPROM? Not sure how you would handle things like entering numbers, but I guess you could do that from the throttle web interface.
On the development branch it does exactly this, you can start with a default configuration (SoftAP, no extra features enabled) and from the web interface configure it to connect to a WiFi network, set various LCC settings, etc. After updating the config via the web interface the CS will automatically restart and start using the new configuration settings. There are currently no plans to support turning on optional modules via the web interface though, that will still require a recompilation as some of the modules overlap in functionality and pin usage by default.
Again looking at the code (but comparing it to the datasheets) for the BTS7660B, I see a factor for volts per Amp in the code of .0105. And not .125? So a pin reading of 11 on an Uno/Mega is 5A (11*.0049/.0105). Is that correct? I'm a little confused.
I couldn't tell you off hand. It has been far too long since I looked at the actual code on the AVR side of things. One benefit on the esp32 is a higher resolution ADC but it would still be inaccurate at best for most cases. It is most critical to get it right on the prog track since it is used for reading CVs. I wouldn't recommend using it for that though. Sent from my ONEPLUS A5010 using Tapatalk
