codehero

Linus' law may scale, but even assuming these eyeballs produce bug fixes, applying those fixes to the source tree does not scale as well.

I have taken time to put my eyeballs on bugs in spidev's ioctl() and TI's spi driver but my bug fixes are not in the tree.

Signing off, adhering to the source standard and attaining enough respect from the established devs to get your fix accepted are the limiting factors.

I already invested significant amounts of time finding these bugs and fixing these issues; I don't have any more to spend to make Mark Brown or other kernel devs happy.

I don't even care about getting the credit for my fixes, but it seems the kernel devs don't want to take my code to next step and get it integrated.

USB is still problematic on Linux. In particular the musb is completely unstable when "babble" is detected. You have to use the right kind of USB hub (or modify the cable) to keep power from backfeeding into the BBB. It seems your experience is different from mine.

There are two troubling lines in his code (from https://github.com/espruino/EspruinoOrion/blob/gh-pages/seri...)

  var header = sampleRate; // 1 sec to charge/discharge the cap
  var bufferSize = samplesPerByte*data.length/*samples*/ + header*2;

This implies 2 seconds of overhead per message sent from smartphone to microcontroller, 1 for the light to turn and 1 second of clearing time before the next transmission. This explains why the lights toggle so slowly.

To top it off, he uses 2 stop bits. The signalling rate may be 9600 baud but do not expect to be transmitting 9600 DATA bits a second! I think such claims need to be backed up with a demonstration full loopback capability without either side dropping a byte, with no pauses between serial bits.

Unfortunately it won't port to IAR, which is a shame. I don't understand why pointers to labels never made it to the C spec; it's one of the (equivaling) features that actually makes assembler look elegant.

I wrote a JSON parser that avoids using dynamic memory but works a bit differently. It's a callback interface like SAX, but instead of pushing already "typed" data to the user, the user calls a function to interpret the data. In this fashion, if the user wants a float instead of an integer, they call the function for float. Likewise, if the user has some space allocated for string values, the library can convert the already inmemory JSON format string to UTF-8 in the user's buffer.

The C interface is purposely ugly but the C++ is much easier to work with.

https://codehero.github.io/benejson/

I have to agree. I developed a proprietary embedded web server using a streaming HTTP parser. Complying with the HTTP parsing rules is a headache to say the least. Variable amounts of whitespace; 2 variants of line terminators (\r\n or \n) with the provision that the latter SHOULD be accepted by the server and line continuations make complying with the whole specification a real pain if you only have 100 bytes to parse pieces of your request.

Maybe for a server with massive resources (I am talking about megabytes of RAM compared to kilobytes I work with) being liberal in what you accept works, but not when you are on a budget.

I typed in `oink` but the command was not found...

Cheap pin headers are just punched and shoved into nylon housing. They have very little contact with a male connector.

These pin headers are machined and have far better contact with anything plugged in.

Searching for "thrust bearing" came back with mostly teddy bears...

Pattern matching looks cool but I have some concerns. What is the best forum for Rust discussion? I get the feeling HN would rake me over the coals for bringing up switch, falling through case labels and of course, goto.

We differ on our opinions of C. It may be dated for you but I can I know how to manipulate the syntax to get the desired result. Rust has been on my list of things to check out, but not use for clients. Right now all roads (from Javascript, C++, Objective-C and Java) lead to C. So when I write a library in C, I know I can use it my iOS, Android, node.js and C++ projects. I cannot say the same for Rust. I do not want to be on the Rust journey quite yet because I am still smarting from node.js. And in 2012 when I was using node.js to solve problems was when I was close to becoming a problem engineer, as you believe I am.

I see two great things about this tool, and not exactly for what it was designed:

1) Fix bandwidth problems caused by API designer laziness.

2) Detect API designer laziness and programmer laziness.

The API designer laziness merits description. Essentially, if you as an API host server are sending back tons of redundant data, you are doing a disservice to your user by not passing references to this data in the first place. The results in your API should either include an entities section or links to retrieve more data. (Note the scale of repeated data I am talking about here are subtrees, not just key/value)

The programmer laziness is when an he just sends back JSON.stringify(someVeryLargeObject), instead of making sure only a minimal object is sent back.

So we can detect this laziness by running this tool and looking for 4x compression gains!

You're as judgmental as errordeveloper; let me do the namedropping this time. I have timestamped when I started playing with certain technologies:

SVG: 2001 AJAX/Javascript: 2002 Windows CE: 2005 DirectFB: 2005 FLTK: 2006 SCons: 2007

I have been learning new things my entire career. I have wasted tons of time trying to support the "better" technology. mbedder presents a very weak case in my mind.

My question to you is how has your experience with mbedder been so far? You seem to understand its superiority. Does the code size and RAM consumption live up to your expectations?

Name dropping does not mean a thing and I doubt they developed ALL the tools and IDEs for Siemens' industrial systems. If they did, then they would be wise not to mention the numerous SCADA faults found in Siemens control systems. There is absolutely no way you would roll out a system like that and have every industrial product line using it. So I am little puzzled by your claim.

The thing about these systems is they attempt to prevent you from shooting your own foot by not letting you aim. Some operations (such as erasing and writing flash) require you to do dangerous things like relocating code to SRAM and running from there while your flash operation completes. The details of each platform vary: ARM code is generated in a position dependent fashion; MSP430 is not.

I am certainly not calling C the end-all be all, but it's a tough system to beat. You could convince managers that mbedder may be the way to go, but it would be an absolute boondoggle to get existing engineers to use it. (They couldn't even convince the Park-o-matic folks to rewrite their code to use it). To a "C simpleton" like me, I would not call mbedder obviously better.

I really appreciate your succinct criticism of my points, you didn't need to qualify with anything but "you have been doing C for too long." I consider that a compliment.

Ask my clients how much of a problem I am and then ask them how many problems I solve. And no, I don't solve them all with C.

When I work on an embedded system, I want as few layers between my code and the assembler as possible. Even your C compiler can produce undesirable code if you don't put the proper const, volatile qualifiers on your pointers.

The last thing I want is a layer of software and an IDE developed by a team that I can only assume has 0 embedded experience (judging by team page they are all architects or academics).

Secondly, if I handed off a work for hire implemented in this language I would not get a next assignment. There is no room for fad modelling in the established engineering trade and unfortunately I don't have the pull to start the disruption if I truly believed in it.

How does the power efficiency of DSLR compare to Ubuntu? Would I get longer battery life?

Are there any examples to read high detente count encoders?

How would you make feedback work for blind people?

Is there a similar way to play with the phase component?

Makerbot is trying to be the Apple of consumer 3D printers. However, the Genius bar will still help you with your 3GS; Makerbot Support wouldn't touch my Thing-o-matic issue (and I bought that in 2012). The issue regarded the heated bed connector, which burned out due to a design flaw.

The moral is they will eagerly drop support for your $3000 purchase in just a few years.

dyad_writef is certainly not 'async' when using the 'r' input specifier (which seems to redirect input from a FILE* to the output stream). And the way dyad_writef achieves 'async' is to buffer the entire contents of the output in RAM.

So for 'r', why bother using the FILE* formatted IO if all you're going to do is pull single characters at a time? You can just use file descriptors.

Can anyone comment on the read/write performance of SPI flash? Seems like it would be similar in performance to SD card, but without the wear leveling?

A humble suggestion would be to ask them to start counting from zero, not one.

Reminds me of Multics; it had online updates.

Off the top of my head I look at it as a graph 2 coloring problem. The graph starts out with 1 node per item and zero edges. If we think two items will be in the same set (either in the knapsack or out) we merge the nodes and their weight and value combine into the new node. We draw edges between two nodes if their combined weights exceed the knapsack capacity. When we recurse out of our merge choice, we also draw an edge between the two nodes that composed the merge. Our recursion depth ends at a clique.

One thing you do not see fragmenting are command-line tools, because people tend to agree on their function(1). However, QT is huge; its scope goes far beyond GUI functionality, into string classes, SQL databases, networking, etc. And moc, its C++ code generator. More scope equals more possible disagreements, which necessarily entails fragmentation.

I tried installing the Qt version of wireshark using exherbo (one of the most minimal Linux distros) and it wanted MySQL as a dependency! For me, if you cannot build a well focused tool with a GUI toolkit it's not worth using.

1 (sure different Unices have different options, but that is more historical)

All these years later and under Linux I still can't unambiguously read a UART line break condition....

That is really cool.

Combine this with struct definitions in function bodies and I see a great teamup with variadic functions.

Take a theoretical struct_printf, which prints out non promoted data with struct packing (not variadic stack packing, which requires type promotion)

  /* Only uses va_start and va_arg to*/
  void struct_printf(const char* format, ...){
  ...
  }

  void print_foo(){
    struct foo_t{
      float f;
      uint16_t u2;
      uint8_t x;
    } input;

    struct_printf("No type promotion here: %f %hu %hhx\n",
     (struct foo_t){ .f = 0.1, .u2 = 1000, .x = 0xF2});
  }

Now we can actually pass what we mean to pass without the compiler changing it.

NOTE: After I wrote this I'm not actually sure what va_args does with a struct or how to get a pointer to the first member...

In Myth 4 SSDs, Thompson claims that:

"there's a limited number of times you can READ and ERASE a block" (emphasis mine)

My understanding is that ERASE cycles are what's limited; reading and writing are not destructive to the flash.