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
@Laserdev.
Not sure what you mean with LAN or WAN or if the question was directed at my last post.
I was thinking more along the lines of using high bandwidth mulitband SDR for wireless comms using the 802.11s mesh standard, plus some 4G mesh for longer range.
Wired network either Gbit LAN or USB3/C.
Regards
JB
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
Hi, does anybody know the size of ardupilot "plane" code? I am no MC engineer, but as I was also recently moving from outdated APM2.5 to Pixhawk(1) I am very surprised about that 1MB boundary ... wasn't the MEGA 2560 carrying only 256Kb of flash at max.? How could we reach 1MB that fast on "copter"?
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.
-
2
-
3
-
4
-
5
-
6
of 9 Next