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
Why not use smartphone based professors,with external flash and ram. Cost of manufacture is higher, complexity is higher, development costs are higher. It's heading that way but markets need to support that as well. It just takes time. Bill of Materials. BOM. needs to be low.
You can add sensors boards to RaspberryPi, but they are just as costly requiring onboard micro controllers for effective PWM/PPM conversions without sucking alL CPU resources to do it.
Because its available and usable for common users (like me and most of my readers) When do you think, that the hardware you´re talking about, is available @ a convenient size (not bigger than a 3DR PIXHAWK) , Arducopter compatible with an MP style user interface ?
2017 ? 2018 ? 2019 ?
I´m sure that most of us would buy that right away, as soon as.. But let´s face it, we´ll have to live with the given limits still for quite some time. With all the consequences. So it doesn´t make me wonder, that users are concerned about the code getting bigger and bigger.
Snapdragon flight already incorporates all that including 4k video and runs APM code.
It's available now for developers.
Linux Arducopter already flies too.
Great! Wasn`t aware of that one! Thank you.
You don´t need to tell me about existing alternatives. ;-) Great stuff, very interesting for the ones really involved.
But come on, thats HW for devs., no alternative for the majority of common users I´m talking about already getting into troubles with anything more tha an MP wiz offers..
No noob support. No chance to spread.
"Yet" being the defining term.
In order for there to be a "noob' version you first need some smart developers to make it... ;-)
Until then keep on using PXH derivatives for the next year or so until they're released.
But in saying that I agree there's a market niche in a sub $100 RTOS MCU and Linux CPU combo. iMX7 would do it for hardware with HD video and wifi thrown in.
Raspberry pi 2 i/o shield are already available and offer 1GB of ram. Not that much bigger than a pixhawk. Or use the raspberry zero with a custom shield. Tiny.
So instead of using a lot of resources fixing the Pixhawk it wouldn`t it make more sense to get the Linux version of Ardupilot running properly?
Shall we consider the Pixhawk1 has only 1MB of flash memory ?
We might accept the reality that expansion of new features or other improvement will not come to Pixhawk1, like old APM2.x. Then, we need Pixhawk2(?) for larger flash space and better accelerometers, etc.
I think it's possible to reliably flash a firmware larger than 1MB via USB (i.e. flashing via serial or SD card is not necessary - and maybe it's not even possible with the bootloader on all these boards) but the USB can't be used reliably after that for log downloads and set-up. So yes, assuming people have telemetry connected, it's really just getting at the logs which is a problem and you could just pull the SD card out if it's accessible.
Even if you flash using serial at 115k200 baud with 2MBytes it would take 3mins. If you compressed it using zip, you'd probably get 75% compression*. So that is 2 mins to flash over serial at 115200. If you can run the port at HS serial you can make it less. It's not perfect, but you can survive without using USB.
*I did this before with the Arm Integrator Platform boot loader many years ago.!
-
3
-
4
-
5
-
6
-
7
of 9 Next