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
Raspberry pi zero has 512MB of ram and 900MHz of CPU just for 5$. Why is not possible to use it s processing module for next Pixhawk and get rid of all these problems?!
From what I understand the problem is not so much that there isn't any alternative hardware available (which could be as simple as adding some flash over SPI, which could be a potential mod for the 1MB boards BTW), rather that most of the current units are likely to run into flash memory problems sooner rather than later.
As Rob suggests at some point the RTOS hardware layer will need to peel off from the higher function layers...I'm not 100% sure multi-processor or MCU/CPU was incorporated with the onion strategy though.
They had a discussion on the Emlid Reach forum about the Pi Zero. The Emlid team said it would be possible to use with their Navio2 shield, but currently you would need an adapter cable to match the Zeros pins to the Navio.
The zero is pretty much just a small Pi1
Bill
I agree on the BOM and cost points. The new tri-core 2x A7 1GHz CPU plus M4 MCU iMX7 with POP memory would be ideal to drive the cost down but functionality up. Plus would shrink both Nuttx and Linux to run on the same IC package, and can even share access to the sensors. You could have the APM stack running in both RTOS and Linux at the same time then.
The BOM of the whole aircraft needs to be considered, so integrating now "common and essential" features like imaging or video or even some built in OpenCV would be a step in the right direction IMHO to reduce costs even more. Look how many devices mobiles replaced...;-)
Well, I think there's only so much that can be done within the flight controller itself.
Personally, I prefer the concept of separation of the flight controller and upper level processing anyway. I mean, many of these Linux computers would require the addition of a special chip to generate PWM anyway, because the computer processors can't do that. And the STM32 chips are typical targets for that function anyway. They are so good at what they do. Cheap. Stable. Reliable. Why not just leave the flight functions running on them?
Fact is, we probably still have a lot we can do before running into 1Mb. And 2Mb will be plenty when you figure these processors will never be suitable for upper level functioning anyway (ie: vision processing, etc).
So I'd rather not jump headlong into something like a Pi Zero.
I think most of the extra flash space went into the EKF.
Also, once the 256kb shackles were taken off, we went nuts adding new features, or improving old ones, that couldn't be done on APM-class. There was a lot of pent up demand for memory that was exploited as soon as we could.
The limit here is 2MBytes and we are nowhere near that. The problem is yet be resolved but could be with some clever OS implementation. If not you can run an external USB adapter to the serial port. Transfer will be slower for logs, or use SD CARD extender and it fixed.
Because they tried to squeeze more and more code into the original Arduino chips. Which was obsolete for years anyway. Trying to program everything as efficient as possible makes development very slow, as Randy already stated.
Also I`m a bit surprised that the discussion is THAT they are already are at almost 1MB. I wonder why we are still using hardware with flash memory in the MByte range. Why not move on and use a modern smartphone processor with external ram and flash memory and a real time Linux operating system? Wouldn`t that make upgrades easier as well and allow user to choose from hardware at different price points depending on the processor, ram and flash chips?
And it`s not that the Pixhawks (and APM`s for that matter) are worthless after that. They are still fully functional and offer everything and more than promised. And you can still use APM hardware to fly around your plane any day.
Bill and Rob have pretty much said it but from what I've seen, the exact same ardupilot firmware is at least twice the size when compiled for the Pixhawk vs the APM2.x boards.
To help the developers keep an eye on the size, this appears at the end of every build. The numbers below are for plane and show it's basically the same size as copter... a little over 90%. Acutally copter is about 92% last time I checked.
text data bss dec hex filename
911952 2836 62400 977188 ee924
-
2
-
3
-
4
-
5
-
6
of 9 Next