This is a discussion for the 1MB flash limit issue so that we can consolidate any discussions and concerns about it in one place.
To give some background, all Pixhawk (and compatible) boards use STMicroelectronics's STM32F427 as their main CPU. This CPU is advertised as having 2MB of flash space (flash is where the ardupilot software is held) but we have discovered that early revisions of this CPU (RevA, RevY and Rev1) have a hardware problem and can actually only hold 1MB and if we use more than that they start exhibiting USB communication problems.
Now currently APM:Copter-3.4 is 0.9MB so it's under the limit but as we add new features it grows and if it grows above 1MB users will find they can't reliable connect the ground station to the board using a USB cable (wireless would still work) which could make it very difficult to configure the board, download logs, etc.
We think many boards (perhaps most boards) out there are the early revisions (A, Y or 1) which suffer from this problem. All the boards on my desk have this problem and you can check your board by following the instruction also shown in the video:
- Ensure your Pixhawk (or compatible) is loaded with a recent version of ardupilot (like APM:Copter-3.3.x)
- Connect with the Mission Planner
- Go to the Terminal screen and select "NSH" on the drop-down on the left, then push the little green connect button beside the drop-down
- type "ver all" and press Enter quickly into the terminal (the "Overtime in task 19" causes the MP some troubles)
- look for the "WARNING! Revision Y has a silicon errata".
Some very recent boards do not suffer from this problem. For example all Solo's are fine as are the XRacer (aka PixRacer) boards.
Before panic ensues I'd like to say that although APM:Copter-3.3.2 is already 90% of this limit, remember we've just done a release and we will put effort into keeping the code size under 1MB. So for example, I can guarantee that APM:Copter-3.4 will fit and hopefully Copter-3.5 too.
Still, when you're shopping for your next Pixhawk you may consider asking the manufacturer if they are using the latest Rev3 STM32F427 processor.
Replies
It would be great if older boards would be supported in the future. However, new boards will also have new sensors. So switching over to new hard- and firmware from time to time might be a good idea. There also seems to be a chance that updated Pixhawks and clones will become available so it would just be a simple replacement without the need for new cables, connectors etc.
A more general solution would be if certain modules could be switched on and off depending on the board. This would reduce functionality for older boards to some degree but provide up-to-date firmware for these.
I suggest not to get rid of USB. This is the only fast option to download the logs which are becoming bigger and bigger. So the suggested USB at Boot idea should be preferred. How much flash could be saved in this case?
I think that we have an established history of doing our best to support older hardware. But the community should recognize the fact that supporting older hardware, does create a significant extra workload for the developers. So the question becomes, how much of our limited resources should we devote to maintaining older hardware, and how much should we devote to developing new features which can only run on newer hardware? If we had 100 full-time developers, we wouldn't have as much trouble, but that's just not the reality.
Back in the waning days of APM-class hardware, I'd estimate nearly 90% of developer's time was spent trying to squeeze the code onto hardware that was obsolete. Counting bytes, converting floats to ints, etc. It really slowed development.
Personally, I'd rather not get back to that. I think that with 3.3, or 3.4, or 3.5, we should be satisfied to declare the code feature-complete for the Pixhawk-1 class of hardware, and move on. It's not the same situation as it was with APM-class hardware, where the firmware was barely capable of delivering what the hardware vendors promised. The latest Ardupilot firmware is the highest performance, most feature rich, and widely used firmware available, and it runs on hardware that is very affordable compared to the competition. I don't think there should be any shame declaring this generation is finished, and moving on to the next.
When we finally decided to discontinue APM-class development, there was much criticism from some in the community about their perception of loss of their "investment". Meanwhile, Pixhawk had been on the market for over a year, languishing, before any serious development work was done which took advantage of it's capabilities. In this fast-paced industry, that's just not competitive, and I think we fell behind a little bit.
There was talk that somebody should pick up the APM-class firmware development and continue it. We agreed to allow that. But to date, no serious effort has occurred. To me it's an indication that anybody with the skills and resources to do so, recognizes that it's an irrational thing to do.
Hi Rob,
yes all of the developers contributions are fantastic and should not be slowed
down this way. But let me add the viewpoint of someone more using the
'long term stable' approach.
This winter I'm upgrading from APM to Pixhawk type for my plane.
Roughly speaking a software update once a year and hardware migration
all three years is sufficient to me. Better knowing and working around issues
than to hurry into the latest and maybe broken thing. It takes a fair
amount of flight time to become comfortable with the reliability of
the complete setup. Not flying every day that takes me not only
a few weeks to come to that point.
In addition as for software usually the third version is the first
reliable one for hardware it takes a couple of months to sort out
all critical issues (powering, frequency interfering,...). Not blaming
but just the way I learned it the last 25 years. Within the first
6 months I'm not going to jump to a new thing of this complexity.
Now my mindset was to do a giant step away from APM to the next
generation. Having the new workhorse to stay without any thinking
for years. When I come along Randy's headline here I was simply saying
WHAT? to me. Not even having that piece I hear about memory limitations.
As Phillip is contributing here as well I like to note my similar
feelings with the fantastic AUAV. After reading through some 5000
blog entries and just ready to press the Buy button the 'discontinue'
note comes up. (I'm aware of X2.1, just to use this thread to show
different time frames which may be out there)
I was thinking twice to post this not to upset someone doing that
great contribution in his spare time. On the other hand I strongly
believe I'm not the only one out there feeling this way.
regards
Wolfgang R.
@Rob: I fully agree that it cramming code into old hardware should not eat away time from the developers! I think in the apm board case too much time had been spent on this.
On the other hand begin able to run the APM code on ubiquitous and relative affordable hardware was probably one of the main reasons why apm is so popular now.
This has nothing to do with the developers: I am a bit disappointed that the 'shelf life' of pixhawk is/will be/was so short. I guess it will last a few more versions but then end of. Isn't the miraculous halving of flash space something that should have been discovered by quality control in manufacturing?
I would also point out that in my experience, manufacturers often have a confusing inventory of different steppings of CPUs that end up willy-nilly in products, even with the best of intentions, and often in conflict with the answers they provide to queries regarding CPU versions. And that doesn't even take reseller inventories into account, and the individual resale market. This suggests that affected versions of the CPU will be in the pipeline for quite some time, and affecting new users into the indefinite future, no matter what questions they may ask to try avoid the problem. The upshot again is that every effort should be made to keep these units fully functional over wireless to the extent USB becomes unreliable above 1MB, without forcing these users to stay under 1MB.
--Lauren--
Lauren Weinstein (lauren@vortex.com): http://www.vortex.com/lauren
Founder:
- Network Neutrality Squad: http://www.nnsquad.org
- PRIVACY Forum: http://www.vortex.com/privacy-info
Co-Founder: People For Internet Responsibility: http://www.pfir.org/pfir-info
Member: ACM Committee on Computers and Public Policy
Lauren's Blog: http://lauren.vortex.com
Google+: http://google.com/+LaurenWeinstein
Twitter: http://twitter.com/laurenweinstein
Tel: +1 (818) 225-2800 / Skype: vortex.com
I have consulted to Google, but I am not currently doing so.
My opinions expressed here are mine alone.
Yeah, and then it will turn out the later gen CPUs have a *different* problem. This doesn't seem like a traditional obsolescence issue, but much more like the kind of fundamental manufacturer defect problem that every effort should be made to work around for users.
If it is indeed the case that functionality other than USB is unaffected by going over 1MB on these units and USB performance cannot be stabilized, then it would seem reasonable to propose that any functions that cannot now be conducted over the wireless link -- that can be modified to function over wireless -- should be so modified, for the use of affected users willing to take the speed hit of wireless vis-a-vis USB when going over 1MB.
L
-
5
-
6
-
7
-
8
-
9
of 9 Next