Clarifications on OnStep's code

[kbahey]

As I dive more into the code for OnStep, I come across areas that I have questions on ...

Including:

• What is T4C for? This is the Texas Instruments Tiva C board, but we don't have a build for it, unless these defines are used for something else.

• What is Energia for?

If the above is obsolete code, then it would be best to remove it from Alpha and future versions to make the code more readable and more maintainable.

• There are two distinct EEPROM function sets, using two call formats, one Object Oriented in style (EEPROM_LP.ino), and the other is regular procedural calls (EEPROM.ino). It would be best if these are unified in one style, and one .ino file, again for clarity and easier maintenance.

More to come ...

I am willing to work on the above, if you would accept pull requests for them.

[hjd1964]

Yes, TM4C is referring to the TI Launchpad C series. Like the TM4C123GXL and others. Energia is an Arduino IDE fork for that processor series.

I haven't checked OnStep over there on Energia in a while so I just did that. Other than a couple of typo's (I just fixed) it still compiles fine.

I've been waiting for the EEPROM issue to resolve itself and plan to continue to do so for a while longer. I figure Energia will be updated at some point and that will take care of that.

[kbahey]

So, this is code for a non functioning hypothetical platform?

If so, this code can be retired for the sake of simpler and more maintainable code for the platform that indeed do work.

Here is where this is all coming form:

I am thinking of building a breadboard version using low cost components. The only discrete components will be the two capacitors for the two stepper drivers (TMC2130 or TMC2208, TBD). The power conversion will be a ready made board with screw terminals.

So, I researched low cost ARM based boards, in case the project does not pan out due to my skills, but also for this to be a learning experience on MCUs in general.

This board came up:

http://wiki.stm32duino.com/index.php?title=Vcc-gnd.com_STM32F103VET6_Mini

https://www.ebay.ca/itm/STM32F103VET6-ARM-STM32-Minimum-System-Development-Board-Arduino/291549961695

Functionally equivalent to the Teensy 3.2, same MHz, so should be able to handle a TMC2xxx. Has an SD card too, if one wants to add a library of objects based on Saguaro Astronomy Club excellent lists.

It is half the cost of a 3.2 (in Canada, with no added shipping).

Another variant of the same chip:

http://wiki.stm32duino.com/index.php?title=Vcc-gnd.com_STM32F103VET6

The only added work is how to upload sketches to it.

http://wiki.stm32duino.com/index.php?title=Flashing_the_bootloader

I configured the Arduino IDE to add STM32duino, and was able to compile simple example sketches on it.

Then I started compiling OnStep on it, and there are too many if defined(xxx) all over the place. If I force define __ARM_Teensy3__ (closer to STM32 than Mega), then there is one function that makes OnStep compilation chokes (IntervalTimer itimer1), then another, then another.

If I force define ARM_TI_TM4C, then I get a compile error because the file Energia.h not found. I comment it out, and then other errors creep in.

Timer.ino is the file with the most hardware specific defines in it, and the hardest to understand.

My particular quest may end up being a wild goose chase, but the bigger picture is that as more hardware is added in the future (which is inevitable as better boards come to the mass market), then we should explore the idea of abstracting stuff more and more.

That way, there are less hardware specific defines scattered through the general 'application' code. Those defines are then in specific files for the specific board with the appropriate code for that board. This would be ideally in a subdirectory for each platform, e.g. OnStep/hal/teensy32, teensy35, stm32f103, mega2560, ...etc.

Thank you for your patience in all this.

[hjd1964]

I haven't tested in a while but the Tivia C worked and probably still works just fine. I have two for testing, a TM4C123 and a TM4C129. There are a few users out there too still, I assume. Another user testing said the TM4C129 was blazing fast, 2us step rate or something, but that wasn't my testing. The Launchpad's also have an advanced TI stepper driver on a booster pack. I think the TM4C129 can take two booster packs... see where I'm going with this. I'm not getting into coding/supporting it but the possibility exists. I hate the Energia IDE, it's primitive and buggy.

As OnStep evolves and grows I've been objectizing and simplifying code.

Just take a good look at the older Stable branch, like it's command processing code for example, to see this. And it continues... today I just objectized the TMC2130.ino code, now much more readable.

I've thought about Timer.ino and have considered breaking it apart but that's actually a tricky thing and if not done right could lead to more work (for me) in the long run (similar code spread all over the place.)

STM32duino I think you'd be better off learning to solder.

[kbahey]

So you are saying that the Tiva C TM4C129 requires Energia and will not work with the regular Arduino IDE? The board is not that expensive, but shipping is. The motor drivers on TI's web site are all DRV88xx based, with a maximum of 32 microsteps. So Trinamics are still better with the interpolation.

Learning to solder is not a priority. I will be in over my head and waste more time. Just because I have a scalpel and some courage, does not mean that I can take my appendix out by myself. Just look at the recent questions and confusion and hours wasted from Stephane Debalme and others. I don't want to go down that route. At least not for now.

Anyways, back the to the main point ...

Think about how Open Source can work:

You do not need to do the work yourself on any of my (or others') suggestions. I have been a contributor for 15 years (Drupal, a web content management system, used by NASA, RASC, Lady Gaga, among others. Go here and search for my name http://rasc.ca/MAINTAINERS.txt).

You can be the head of the project, and people 'scratching their own itch' will add features, tidy up code by refactoring it, adding a HAL, or port new boards, ...etc. You get input from a couple of experienced developers who are willing to improve the project and contribute to it, and then you commit (maybe with the help of a couple of others). Others will jump in to improve the general documentation, provide detailed steps for assembly and configuration, promote the project among the astro community, and even some will start building commercial boards or controllers based on it. Just give it time, and most of that will happen.

Again, these are suggestions and not necessarily the only options available, nor what you want eventually. I am merely relating my experience in the open source world, and how they make a project grow and get more adoption, and more contributions.

[hjd1964]

Please understand that Stephane's issues were due to wiring errors not soldering (he was using a breadboard - you plug stuff in, no soldering.) Building a MiniPCB or MaxPCB would have avoided that. I still don't understand the issue you seem to have found with using a RAMPS... especially the all-in-one w/Mega2560 on-board I pointed out.

I always welcome contributions where I see benefit. The initial TIVA support wasn't my code. The Teensy support wasn't my code (Paul Stoffregen did the initial work on that.) General code review has been done by others ("Dan" especially.) Many smaller contributions too. And yes I might be a bit heavy handed now and then about what I see as beneficial (and allow) or not, but I'm also the one with the most work in this by far. For example the ESP32 support I'm asked about, you probably have a rough idea of what supporting that would take. Merging the WiFi web-server into OnStep, the real-time issues, background processing issues, lack of pins, figuring out an EEPROM substitute, getting the hardware timers right, getting the interrupt priority levels right, etc. Having the OnStepESPServer and OnStepEthernetServer on separate devices gives a modularity to OnStep and those looking for a cheap all on one device don't see the advantage of that... but I sure do. Add to that supporting too many platforms has downsides in my opinion; more user support, bugs more likely, code harder to maintain.

I had a nice user a while back who was manufacturing an OnStep shield for the Mega2560 but that aged into obsolescence and work/life kept him busy enough to not work on a replacement. So I designed the MiniPCB, etc. His board had all surface mount components, mine are easy to solder by comparison.

[kbahey]

Yes, I know of Steve Sagerian's board, and contacted him on Cloudy Nights before you created the PCB Max. He was busy then.

Now for the interesting part ...

So after installing STM32duino, getting a digitalWriteFast library, and figuring out how to do timers for STM32, and a few odds and ends, I got it all to compile! This is for the STM32F103, V and Z variants, which are 72MHz, 512K flash, and 64K RAM.

These boards are ~ $12 or so, so cheaper than Teensy 3.2.

There is STM32F407 which is 168MHz and more flash and RAM, but its support is not that good yet in STMduino. So, I will defer that for the future.

I will order a board, test it, contact you for questions (mainly on wiring and motor specs), and make a pull request.

Or if you want to look at the code sooner, I can make a pull request now.

Enjoy the holidays!