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.
Initially we did have some problems. Most of it was due to not being able to source enough current. We haven't seen any issues so far. Thanks for reminding me. I'll keep an eye out for that.
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.
There is a demonstration there of full loopback, without the 1 sec delay. The delay is purely so you can send a command using a totally normal audio API that only uses the sound card when needed.
I could probably get away with 1 stop bit... I didn't try. To be honest if the transfer speed matters so much, it might be better to use some other means of communications :)
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.
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.
Every appearance of SHOULD/MAY in a spec is just begging for bugs or incompatibility. We'd be better off if those words were banned. Spec writers would be less inclined (hopefully) to come up with all sorts of arbitrary behaviour that might happen and could be maybe handled.
Should and may are spec weasel words, in specs there must (hah!) be 'MUST' and 'MUST NOT'. Otherwise a spec is just a piece of rope with a pre-tied noose.
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!
It's not always lazyness, several small connections can be considered worse than one bigger payload in some scenarii.
There's no universal truth about API design, every case is different.
Sending too much data is often better than having to do many RPC calls. It's the same problem than normalizing/denormalizing DB schemas, except that DB engines are smart (denormalizing can hurt perf) while RPC clients aren't.
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.
There are two problematic types of engineers out there, some have no clue what they do and some have too much clue and wave their flags all over the place. You are in the second group and have probably been doing too much C for too long.
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.
That's good for you! I don't personally find the tool in question exactly the most appealing to me personally, but what I am excited about is that the industry is moving on, as C is far too dated as a language and even C14 doesn't give much hope. So, as you suggested that you don't appreciate the abstarction this tool adds, would you consider Rust, as it compiles right down to machine code? Essentially Rust is much C-like in terms of basic syntax, but has expressivenes of a functional language, safety-aware compiler and a ton of other features, including the fact that it's aimed at system-level applications and one should be able to write a kernel in Rust.
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.
Lol, supposedly mine wasn't of the same origin. To be fair, you just broke my whole idea of the two groups of people, which indeed was a very poor attempt that by itself will fall into another group. I am going to asume codehero is a nice guy and walk away from this incredibly amusing discussion. Thank you, dbaupp, for pointing this out.
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.
reddit.com/r/rust is probably the best place to have exploratory discussions.
Although, our pattern matching is a strict superset of C's switch (other than fall-through). But yeah, fall-through and goto aren't supported yet, and if we were to get them (in safe code), they may have to be restricted to preserve memory safety.
Funny you should say that because his team was hired to develop all the tools and IDEs for Siemens and their industrial systems. The tools you see on that page were developed jointly by the BMW embedded development team and I think a few government agencies. So I'm a little puzzled by your comment and your reaction to an obviously better way of developing correct and verified software using C.
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 think you fear learning something new more than anything else and calling yourself a C simpleton doesn't really help your argument. Like I said in another comment when assemblers were being developed the same exact arguments were thrown around so if history is a guide then these tools are the future and the sooner you learn them the better position you'll be in.
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?
You don't have to prove anything to me but your reaction is not rational. I don't think anyone will argue that a tool that integrates unit testing and model checking into a coherent experience is an overall win. As for code size and other matters it depends on your use-case and in this day and age I think a few MBs here and there is not going to make or break an embedded product offering especially if whoever is making that product can deliver it with less bugs.
> As for code size and other matters it depends on your use-case and in this day and age I think a few MBs here and there is not going to make or break an embedded product offering especially if whoever is making that product can deliver it with less bugs.
This statement alone disqualifies you from making any comment about embedded development and automotive embedded development in particular.
