Senior RnD Engineer

Biography has not been added


's contributions
    • I remember laughin aloud a decade ago when ARM9 device manufacturers used the 'low-power' adjective and I saw the numbers. Today, one can get lower (and I mean _lower_) numbers with specially designed arm processors like TI's MSP432 or even before those, the former EnergyMicro (now Silicon Labs) EFM32 series. I'm glad to see the once ago Motorola dudes coming of age again.

    • Oh, yes, the "continue reading" leads to a page that is exactly the same, which in turn followed (had to manually get the link) to a japanese site in which I had to find my way to the english text and then search for the chips... To find... Yet another proprietary core An MCU with some self-test functions in its peripherals. I wonder if a failure in the self-test hardware can cause a working unit to declare itself faulty. Poor article, poor writing, poor marketing.

    • Does this support HTML/SSI/CGI or is it Websockets and thats it ? Which version of HTTP ? Persistent connections ? Who provides the transport ? What API ? I mean, does it work with lwIP ? Does it require the socket API ? Or, do you expect the user to provide a Berkeley sockets compliant TCP/IP stack ? Or, is it for uIP ? Does it need an RTOS to work or can it run as a baremetal application ? What is its flash and RAM footprint ? 41K for a page is a no go for embedded, and you say this is for "resource-constrained" microcontrollers ? Please define "resource-constrained". Perhaps visiting the github page will answer all my questions, but, hey, this is supposed to be an article, right?

    • This is my current equivalent to a notebook: Every project has a folder on a tree directory, based on whether it is for a particular customer or a research one. Inside that folder there is a file named "blues.txt" which sings all my ramblings and trade-off decisions. All related material is in that folder, and there are also links to other stuff in their proper place, like datasheets. Once a project is somehow advanced, relevant notes evolve to DokuWiki for the hardware and CVStrac for the firmware. Basically: the important parts to resume the project or track an important decision are pretty printed there in markdown or equivalent. All this can be indexed and/or searched later when the need arises, whether on this or any other project.

    • I find this quite loose, more a marketing white paper than a technical article. What is an "IoT protocol" anyway ? Or even a protocol stack ? Furthermore, you can't compare apples to oranges, and CoAP and MQTT are apples and oranges. First of all you have an IoT architecture to embrace, and that depends on the application you are designing. If you want a network of whatever devices that will be interrogated to get some process value, then you will choose HTTP or CoAP in terms of having sort of a server to serve that data to you. And yes, you have to be able to access those devices, so everybody say "NAT" and think about it, or think "IPv6" and say "when?" However, if, on the contrary, you want those devices to report that variable to a central place/database where you will process that data and eventually show the same but not on the device but at a place where anyone can access, then you will probably choose between HTTP and MQTT for sending that data. And, if also you perhaps want that some group of devices also access the data of other devices, or you want to decouple your design by using a publish/subscribe paradigm, in which publishers send their data to a broker and subscribers get that data from the broker, which also is great to overcome the NAT issues and bla bla bla, then you will more likely choose MQTT. And, if you care about anyone accessing your network, then you will also consider adding a TLS layer, which both HTTPS and MQTT over TLS support. And if I had the time, I would continue complaining and lecturing, but I have an IoT network to build. I miss the good days when this was a technical magazine and one could read people like Jack Ganssle here.

    • Well, since your company provides websockets libraries, I'm certain that you would think that is the best way to do things. There is however, a broad category of small embedded systems based on lwIP which thrive to work with the minimum possible memory footprint, and that is a luxury. That and the fact that there is no built-in websockets support (yet?) in the web server. I, though, agree that polling is not a good solution. However, it can be minimized and it is almost always simpler to have the small embedded device just respond to requests from the many gigabytes/gigahertz computer.

    • Yes Jack, they are nuts, but probably they are quite smart and have hidden intentions. I was raised and live in a country where that is common daily stuff, it is called demagogy, and marketing, and positioning themselves as leaders, seeming to potentiate our kids while they are deliberately dumbed down. Though I'm an engineer, I was raised by a professor and have lived with an education expert (a cross between psychology and pedagogy, a career down here) for 30 years. Kids that age are developing their cognitive and emotional systems, they do need caring, love, playing, more playing, and more loving. They need to develop social skills to respect the others, they don't have the necessary maturity to understand abstract concepts and trying to push that into their brains creates the kind of autist-like beings we are starting to see around. Besides, as you say, they can't even properly write... or communicate... Then, there is the painfull experience of having been taught BASIC as my first computer language... I've had to unlearn that to properly address moderately decent programming languages like C. I still have the scars. Please don't do that again... And last, we already did that with logo 30 years ago, are those kids smarter or skillfull programmers today ? Are they better human beings or more socially skilled ? Please don't do that again... Kindergarten is where we learn to behave in society, to recognize the others as equal and understand how to communicate with them, and it can help in all the future learning processes if the correct methodology is approached when just playing. There are many guys/gals like María Montessori, Jean Piagget, and I think I already mentioned you sometime ago guys like Lev Vygotsky and Jerome Bruner; they've been studying this since long ago, and we should know how to properly raise our kids, if we just did the right stuff instead of marketing and competing.

    • If ransomware is file kidnapping (filenapping ?), so, file erasing is the equivalent of murder. How come kidnapping your files and asking for ransom is worse than killing them ? Erasing people's information just for the fun of it is in no way better than cyphering and asking for money to decypher. Finally, disk wiping viruses are the software equivalent of a genocide. My reading on this is that bullying is finding its way into cyberspace; like grabbing someone's hat and asking for something to return it.

    • ... following the Zeitgeist reasoning, software viruses are developed by anti-virus companies as a market expansion policy, and probably by other software companies as a threat to minimize piracy. As almost none of them have businesses on Linux, you'll be safe for many decades...

    • Well, I'm also my own IT department (and R&D and secretary btw, and cook + housekeeping...) I keep important stuff I generate on CVS for code, SVN for documentation. The working PCs have only working copies and everything is stored on a GNU/Linux server. CVS and SVN handle synchronization. Bacula keeps the office server regularly backed up to another server in a different floor. Repositories are also cross-copied via rsync with a similar setup at my home Lab; personal to office, office to personal. PCs are imaged once in a while with Clonezilla (I boot Clonezilla from a CD)

    • The "need" for big servers and clouds might be an indicator that IPv6 is not yet expected to be fully deployed by that time. Without IPv6 the NAT complexity is too high for non-networkers and definitely rules out plug and play devices talking to each other for common people. The only way to circumvent this is by a "rendezvous point", to whom all the devices connect to send/receive data. This is the current M2M way with MQTT and MQTT-SN. IPv6 will enable CoAP and the like. AFAIK the comms model is such that the small device waits for someone to ask it something. So, to successfully reach a device on a private network, one of two things are needed: 1) a network administrator that opens a hole in the firewall and enables NAT to the internal private address for that protocol. 2) a common addressing scheme in which both devices can reach each other by just their unique address (IPv6 or public addresses in IPv4). However, a network administrator might still be needed to open a hole in the firewall. So, my best guess is that cloud services will still be needed to circumvent some restrictions and provide a cleaner experience in which the heavy weights can sell their products without the users actually needing to knowi what is going on.

    • The problem I see is that many embedded people or so-called developers/engineers don't care to be real Gandalfs. I mean, we need to know the dark forces lurking inside the embedded systems we design; hey, we've put them there... The increasing complexity forces some people to use packaged solutions like soda cans, and when those don't work they stare at the system with an astonished look. They have no tools whatsoever to peek inside. Let me clarify with an example: Most of us are not crazy enough to write a TCP/IP stack from scratch, we use lwIP or whatever. When writing an app that runs on TCP/IP and it doesn't work, we should know it is mostly our fault and quite less likely a bug in the stack, and know how to find it. In other words, we are curious enough to learn some TCP/IP before actually developing something running on a TCP/IP stack we don't write and don't care how it works. To summarize, the problem I see is that new generations are not being taught to be curious and know before use, they are being trained to use and do it quick.

    • My educated guess is that all this is driven by two forces: 1) The exacerbation and deployment of the desire for profit, everything is marketing and all that cares is making 2 cents extra. I long for the old days when micros had one or two hidden lists of undocumented instructions instead of ten errata pages. 2) There are many players in the field today, so manufacturers expect their parts to be used for just a single design, so they cram all the info in a single document. That is why in some (particularly asian) cases we get 600 page documents for every microcontroller where 550 are almost the same among all members of a family. Then, applying what we learned from (1), in the spirit of keeping the costs down, and hoping no one will read the I/O specs on a 100MHz, 1MB RAM, 1MB flash microcontroller, those numbers are filled in just in case.

    • I agree those are tools and they are not responsible of the use people does on them. My opinion is quite similar to Jack's. On the professional side, I have a LinkedIn account and don't use anything else as I consider them distractions. As for the Internet, it is like Alexandria's library for me. On the personal side, my opinion on Tw and social networks is not good. I don't like them (particularly FB) because they encourage current human behavior I consider destructive. People think being "connected" replaces being there, and spending all day on your phone watching FB makes you lose the world around you. Thanks to those tools we can exchange ideas without personally knowing each other, and get in contact with friends far away; but due to our bad use of them, we don't visit dear friends, don't talk looking in the eye, and do some more dehumanizing activities. It is not them to blame, it is us, but I think we must first start by being conscious of that fact, so I make my point by showing (the rest) there can be a life without Tw nor FB ;^)