Hacker Newsnew | comments | show | ask | jobs | submit | zwieback's comments login

I'm surprised they went with F205, though. There are 32Lxxx chips with similar capabilities and lower power.

The whole thing looks like a quick turn of a reference design and the real low-cost design will follow later on.

I would agree. It looks like a quick&safe design.... If it takes off, a cost-optimised version will appear.

"As Bitcoin takes root around the world, it will provide an effective floor on how terrible a country's financial system can get."

That in itself would be a great contribution for Bitcoin.


Very nice summary on ARM but I don't really understand the pitch for node in this context, unless "small" is the overriding design criterion.


I was surprised how little I missed manual memory management when I switched from C++ to C# for everyday work.

RAII is something I do miss, though, even after years of C# I still feel lifetime management of objects is awkward.


For unmanaged resources using provides almost the same thing, the only downside I can see is it means yet more nesting.


You can forget to write a using statement. In C++ you can omit your destructor entirely if all the members are already RAII classes, whereas in C# you still need to write a .Dispose() method.

Memory management is by and far the vast majority of resource management in C++ for me, which C# takes care of with garbage collection - so I don't miss RAII too much in C#. But if you tried to give me a C++ with using blocks but no RAII (read: you gave me C) I'd scream.

RAII is no panacea[1] - I'd say C#'s manual resource burden without RAII is still less than C++'s with RAII. Which is why I don't miss it too much. But it'd still be a nice addition. And I missed it dearly during my initial adoption of C#.

[1] e.g. in C++, you still have to worry about reference cycles, implementing the RAII constructs in the first place if existing ones aren't suitable, ensuring parents are kept in scope while referencing children, etc..


> But if you tried to give me a C++ with using blocks but no RAII (read: you gave me C)

If you don't care about MSVC, IMHO new C code should be using the gcc cleanup extension: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initial...


> If you don't care about MSVC

Even ignoring personal taste: I care about MSVC. I also care about clang. GCC is the one compiler I'm able to not care about.

> IMHO new C code should be using the gcc cleanup extension

Even if I didn't care about MSVC, I'd disagree.

I'm OK with extensions that are "harmless" in that the program will still run without them working if I #if them out on other compilers - error pragmas, deprecation annotations, static analysis hints, pre-C++11 override keywords, etc.

I'm not OK with self inflicting vendor lock-in for something as important as cleanup rely on a specific compiler's extensions - especially not when we have a perfectly standard, portable, significantly better tested (and thus less likely to have bugs) reasonable alternative in the form of C++ destructors.

If I'm not using C++ destructors, it's either because:

1) I'm doing small changes to an existing C project (in which case I'd be stylistically inconsistent with it's preferred cleanup patterns for minimal gain, since it almost certainly doesn't use the gcc cleanup extension)


2) because I can't rely on having decent C++ compilers on my target platforms (which means I can't rely on having GCC either, and thus can't rely on the gcc cleanup extension by definition.)


For what its worth, it is only MSVC without support. gcc compiler extensions are otherwise still rather portable. To clang and icc at least.


> For what its worth, it is only MSVC without support.

How recently? I've been enough versions back that clang documented pragmas haven't been available. The cleanup attribute... I can only find docs for GCC. Although I see LLVM bugs for it, so you're right about clang supporting it - at least on HEAD.

> gcc compiler extensions are otherwise still rather portable.

Portable or not, I'd say only about half the extensions I've sought out on clang have actually been available. If that.

> To clang and icc at least.

I should note in scenario #2 above I don't have these available either, since these are decent C++ compilers.


The other downside is you aren't as cleanly encapsulating the resource management logic.


I think the omission of deterministic destructors is one of the biggest mistakes the C# designers made. The Dispose pattern feels like a band aid.


For me C has been a constant companion for almost 30 years now, C++ for 25 so I have some attachment to those languages.

Everything else seems to come and go, especially scripting languages. Right now I like Python but I'm not holding my breath.


It's interesting that ARM32 has conditional execution and I like them a lot for writing readable assembly code. Short jumps that result from a simple if can be encoded in three successive instructions, no branches.

However, it's now falling out of favor (mostly gone from ARM 64) and apparently it's due to the relative cost of putting conditional execution on the die vs. relying on smarter compilers.


I think ARM64 dropped predicates to remove excessive flags-register read ports. Nearly every instruction could read flags register and this limited core frequency (critical path), opportunities to out-of-order execution (and register renaming). Not sure though, maybe someone who knows more about OoO on ARM64 could fill me in?


It's also a huge waste of instruction encoding space! Especially given that 99% of non-branch instructions just put 1110 (AL) or can't be conditional at all (1111).

Incidentally, available register read ports are the reason why cmov takes 2 µop on Intel architectures, but only 1 on AMD, since Intel's µops can only read from two sources but cmov has 3 sources.

Then A32 could have up 4 sources with a conditional op + register shifted register source.


Nice! How do you do this on ARM exactly?


The first 4 bit of each (32 bit long..) instruction can be used to check for conditions: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....


Every instruction on ARM (vanilla: no 64, no Thumb) has a condition code field.


The JTAG mess resonates with me. I probably have 10 different debugger dongles now and the higher end ones from GreenHills or WindRiver are pricey.

As to open FPGA tools, I think the main problems are:

- there's a ton of competitive advantage in the algorithms to generate the bit stream so Altera and Xilinx have no good reason to give that up until a viable competitor emerges

- FPGAs are usually in small to mid size designs so it's hard to scale up to the point where just selling the chips makes enough money


I am sorry you suffer from the dongle collection woes too. The only reason I can see to buy expensive dongles are the ones that have a big blob of RAM on them for quickly reading debug output from the chip without slowing it down, and ones that can adapt to highly exotic voltages and pin outs automatically. But usually the software for these only work in windows, have secret drivers, and are NOT worth 2 thousand dollars.

Xilinx and Altera would not have to give up their custom algorithm. It is like building GCC instead of using Intel's compiler. We just want to know what the chip's instructions are, we will find a way to make it optimal ourselves.


In the microcontroller world, expensive debug dongles are essentially hardware keys for the software included. Lauterbach's[1] Trace32 for instance don't even have software keys, the license for their very extensive debugging software is stored in the dongle itself.

Another piece of software that isn't often mentioned in these discussions is the driver for the embedded flash memory inside parts. USB has quite poor latency (1ms) and flash peripherals require quite a few read-modify-write operations, which soon adds up. More expensive JTAG dongles can run these operations locally on the dongle, with USB just for bulk data transfers, or even download and run code on the target itself for even lower latency, greatly increasing download speed. Since this software needs to be tested for each target, requiring a physical chip to be bought, this gets very expensive to develop. Even a "cheap" dongle like the Segger J-Link has an incredibly long list of targets[2], and I suspect a substantial amount of the purchase price is in engineering and testing flash drivers for those.

ARM seem to be trying to solve some of these problems in the ARM world with CMSIS-DAP[3], an open standard for JTAG/SWD dongles USB protocol. It uses USB HID, so no drivers should be needed on any platform, and they have even created an Apache licensed implementation[4], which Freescale are now using in their FRDM boards.

[1]http://www.lauterbach.com/ [2]https://www.segger.com/jlink_supported_devices.html [3]http://www.keil.com/support/man/docs/dapdebug/dapdebug_intro... [4]https://github.com/ARMmbed/CMSIS-DAP


Very well written.

I had no idea some companies went so far as directly making their debugger the software key. That is intense but makes a lot of sense.

In the case of the Xilinx Platform Cable I wrote firmware to, they have a CPLD that does the JTAG writing of data, and a Cypress FX2LP handling the USB information. They use a quad buffered USB endpoint to let the PC load as much crap as possible into USB and in my experience the buffer fills up fast and the jtag work takes the time. Of course this is only because multiple 'pages' were preloaded, otherwise the delay to request more pages would be insane.

Are you talking about the flash driver for loading external SPI flash? If so you likely know this but you have to load the FPGA with a program to load the flash with the program you want the FPGA to load on reboot. Each of these programs have to be compiled and tested per chip. While looking through OpenOCD I found they had drivers for the actual flash, and I am not sure if this is required for the fpga flash boot strapper I just described.

I will look over these links. I recently started messing with ARM chips and they are programmed very differently than FPGAs so I have some stuff to learn on that.


>Are you talking about the flash driver for loading external SPI flash?

I was slipping into talking about ARM microcontrollers there, which have internal flash. Reads from it are memory mapped, but writes generally require feeding peripheral registers with commands, hence the latency sensitive read-modify-write. Some ARM microcontrollers do have more direct methods though, some of Freescale's Kinetis range have a feature called EzPort, where you hold a pin low on boot and it pretends to be SPI flash instead, and tiny 8 bit micros like the AVR all have something similar as full JTAG would be too big for them.

>If so you likely know this but you have to load the FPGA with a program to load the flash with the program you want the FPGA to load on reboot. Each of these programs have to be compiled and tested per chip.

Yeah, this is what I meant by having code run on the "target", this being the microcontroller you are programming. You are right in thinking this means the JTAG dongle no longer needs to know how to program flash itself, but it still needs to code to load in and instructions on how to do it (setting up clocks etc), which are also very platform specific. You could do the same for external flash, but its often easier just to connect to it directly and bypass the microcontroller.

Feel free to PM me if you have any more questions.


Tcl script errors on Altera tools - brings back lots of bad memories... It seems like as soon as you try to break out of the standard way of doing things the scripts break.


Same here, my HN is 6 yrs old, still read it almost daily. Slashdot, reddit, c2.com, everything2 all have come and gone.

Still waiting for a comeback of usenet groups, though.


1-4-5 songs are great for jams for that reason. You can play along to a lot of songs even if you don't know them.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact