|
movax posted:Too much of the lower-level workings of modern systems (x86, etc) are being lost to NDAs and vaults in a handful of company basements. The problem with learning systems programming on x86 is that it's super-loving complicated. Unlike the C64 where one person really could learn the entire ins-and-outs of the machine, the scope of the x86 and PC platform is insanely large. It is very well documented, but also very difficult for any one person to fully understand. Beyond that, the barrier to entry is pretty high. It's definitely doable for an individual to write a PC OS that'll boot off a floppy disk and can be used with a PS/2 keyboard. But with many machines shipping with USB only, you either need to implement a USB stack in your OS (very large) or rely on a bunch of BIOS emulation code, which somewhat contradicts the idea of working with the "bare metal." In contrast, embedded ARM platforms aren't too bad. There's definitely more to them than a C64, but it's a reasonable platform to write a bare-metal OS that can be interacted with via RS-232, GPIOs, perhaps even VGA. The ARM ISA is also really nice and it's great for learning systems programming on. But there's three big problems with little ARM boards. First, a lot of the documentation on it isn't freely available. Yes, you can find a very old version of the ARM Architecture Reference Manual if you Google for it, and the ARM Information Center has a good deal of information too, but the sheer number of topics on that site that say "This document is only available in a PDF version to registered ARM customers." is downright infuriating. Second, there's not really such a thing as the ARM platform. Rather, ARM cores are integrated into a bunch of different Systems on a Chip (SoC) that implement fairly different platforms from a systems programming perspective. Many of these platforms have little-to-no public documentation and implementing support for them essentially requires an NDA. Yes, you can go read the code that comprises Linux kernel support for them, assuming it's been mainlined or at least easy to find, and there exists a development board you can actually purchase at reasonable cost (sub $100) and run code on. But that's not really an ideal way to learn. Third, the plethora of embedded ARM platforms, with the lack of any one standard, and the fact the embedded space is evolving very rapidly means that any one device/platform has fairly high chance of becoming unmaintained and obsolete in just a few years. This leads to there being a bunch of half-baked software implementations that "get the job done", at least for a little while, but don't serve as a solid basis for use in teaching over a period of many years. As an example, a few years ago I found the Gumstix Basix (PXA255) platform to be one of the best sub-$100 options for teaching embedded systems programming. Unforunately Linux support was somewhat half baked and never (to my knowledge) mainlined. Documentation was spotty and incomplete. And after just a couple of years, it was discontinued with no perfectly-backwards compatible upgrade path. So yes, I'm excited about the Raspberry Pi project. $25-35 is an awesome pricepoint for being able to get the boards into the hands of students, even kids, and let them fool around with it without huge replacement cost concerns when they inevitably ESD, destroy, or otherwise mangle them. There's enough developer interest in the project that, if it doesn't become a "standard platform", it at least gets mainline Linux support and a software ecosystem that can support it for a solid five years or more. And although it's based on a Broadcom SoC (who are typically the most stingy with documentation) it appears the project has enough clout to get at least some documentation into the hands of folks who are interested in doing bare metal hacking. If it works out, I see it as being a great boon to embedded/computer systems education on a number of levels. While it would be great for it to serve as the modern-era's equivalent of the C64 for folks who want to learn how to bare-metal hack, it could seriously improve the state of present embedded systems teaching by serving as the standard cheap platform that folks can actually write solid time-enduring teaching material for. ExcessBLarg! fucked around with this message at 02:39 on Feb 26, 2012 |
#
¿
Feb 26, 2012 02:32
|
|
|
|
| # ¿ Apr 23, 2024 12:42 |
|
|
muuuzo posted:Can you run JavaSE (from Sun/) on Raspberry Pi? Also, some ARM Linux distributions (e.g., Debian) include OpenJDK which is close enough to Oracle Java in my book that I don't bother with official packages, even for things like compiling Android.
|
|
#
¿
Apr 5, 2012 16:57
|
|
|
peepsalot posted:I was searching for a fast SD card to be used with the pi, and I found these SD card benchmarks from Tom's Hardware: http://www.tomshardware.com/charts/2011-sd-cards/benchmarks,125.html Thing is, for "general linuxing", it's probably best to have a card that emphasizes small (~4 kB) random read performance. This is because embedded devices are typically memory starved, and random read performance is important for avoiding UI lag when you're opening up programs and poo poo. Unfortunately SD controllers are often designed to trade random read performance, which doesn't matter much on cameras, for improved sequential write. So it's not uncommon to find Class 10 SD cards that perform noticeably worse in this kind of application than some Class 6 ones. For reference, I have a few Transcend cards that I run ROMs off of on my phone. The random I/O performance of the 8 GB Class 6 card is roughly middle of the pack on those benchmarks but is perfectly adequate. I don't observe UI lag much beyond what I get with on-board NAND, and at $9 it's a good "dirt cheap" option if you don't need much space. In contrast, the 16 GB Class 10 card is horrible. Very bad lag, but I needed more space. If I had known about that Patriot, I would've gotten that. peepsalot posted:Also, what the hell is going on with "Samsung Plus (16GB, Class 10) MB-SPAGA" in some of the h2benchw results? ExcessBLarg! fucked around with this message at 20:56 on May 21, 2012 |
|
#
¿
May 21, 2012 20:54
|
|
|
WoG posted:You'll see SD cards rated as 'Class 2/4/6/10', which corresponds to how fast they read/write.... Especially for storing an OS, and for the tiny price difference, you'll absolutely want a Class 10. SD card speed ratings apply to sustained writes only, which is important when you want use them in a camera or camcorder since, if the card can't do sustained writes fast enough, you can't record video to it. However, when making SD controllers usually a trade-off is made between sequential write performance, and random read/write performance. And it's random I/O performance that's important when running an OS from an SD card. Anecdotally, I've had far better performance from some class 6 cards as opposed to class 10. Check out Tom's Hardware 2011 SD Card Benchmarks. There's a lot of benchmarks there. If there's one that probably the most applicable, it's the IOMeter Workstation Benchmark Pattern. If there's one card I'd go with, it's the Patriot PEF32GSHC10233 32 GB. If you're looking for smaller/cheaper cards, Patriot 16 GB and Transcend TS8GSDHC6 8 GB are alright options. ExcessBLarg! fucked around with this message at 20:56 on Aug 4, 2012 |
|
#
¿
Aug 4, 2012 20:30
|
|
|
Naffer posted:I imagine this is going to torch my SDcard sooner rather than later, is there a particular brand card that I should get that will handle this? Anyways, the low hanging fruit is to mount noatime and use a tmpfs for /var/log. Beyond that I'd check to see where the other writes are going and whether I care about them, or if the write rates are low enough as to be acceptable. You probably also want to use the discard mount option also as it will help keep the SD card as performant as possible once a write-cycle is near completion.
|
|
#
¿
Jun 2, 2014 06:48
|
|