5 ms·

I like the idea of extensible and replaceable computers: I would be much less concerned about my fridge being an IOT device if the IOT component was an easily u

I like the idea of extensible and replaceable computers: I would be much less concerned about my fridge being an IOT device if the IOT component was an easily upgraded and replaced Intel atom or Qualcomm Snapdragon compute card. In terms of process migration I still think Google has missed a trick by not marrying Android and light-weight containers. If I could flick my wrist to send a phone process to my Chromebook, Android tablet, Andromeda device or smart TV life would be pretty interesting. Maybe one gesture for screen mirroring and another to move rather than mirror or copy the process. This would also open up new channels for malware sure but also cool things like trusted processes / data for authentication. You have an invitation to my party, you say? Dock it with my Google Home device which signed your invitation to prove it, then...

hueving 10y ago
>device which signed your invitation to prove it, then... Then you realize why nobody shows up to your parties. :P
- technofiend 10y ago
  >>device which signed your invitation to prove it, then... >Then you realize why nobody shows up to your parties. :P Sure they do, but they're all hackers or cypherpunks. Listen all three of us had a great time. :-) :-) But seriously, wouldn't it be fun to host a party where everyone had to hack an invitation?
  - hueving 10y ago
    IIRC defcon does this with their badges.
pveierland 10y ago
We designed an architecture for replaceability during the summer for our UAV project. Our current architecture has been based on the Zynq-7000 which is a two ARM-core + FPGA SoC. Here we had custom logic for doing things such as controlling signals to the servos in the FPGA and then software drivers communicating with the FPGA through memory maps. This resulted in a tight coupling between the drivers on the compute platform and the IO hardware. Our next hardware generation will have a dedicated FPGA handling the communication with the GPS, IMU, servos. The compute platform will communicate with the FPGA over Ethernet. This means that all hardware drivers can be written against a network based interface, resulting in a loose coupling between the compute and IO. This means that both the IO hardware and compute hardware can be replaced individually without breaking the setup, and without having to rewrite any drivers. It also results in high transparency for debugging IO, with the possibility of easily recording and playing back a scenario. You can also test the full flight software on a developer's desktop machine during development without the embedded compute platform. As embedded compute platforms get better all the time, while the IO stays more stable, this will make it easy to replace the compute every 2-3 years.
- ferologics 10y ago
  This is essentially what React Native has done for UI <~> Logic communication, allowing the latter (think iOS/Androind/Apple tv os/macOS etc.) to be replaced by any compute platform - even Compute Card in theory I think. You're applying the same mental model to hardware which can be seen in the similarity of tools that can be enabled on top of such abstraction. Way to go! The flexibility that emerges from decoupling our software and hardware solutions is a [recent] trend that will only gain on traction as more people become aware of it's implications to how we create solutions to technological problems. How can we evangelize this better? From my experience it's complicated to communicate this idea well. not sure if true, may be recency bias or the fact that I'm still young and inexperienced in many ways and lack historical background knowledge in tech
  - ferologics 10y ago
    (put an asterisk before "[recent]" not knowing that it will format the comment. HN greenhorn)
- chocolatebunny 10y ago
  Out of curiosity, why are you going to communicate to the FPGA over Ethernet vs PCIe or SPI or USB? It seems like you'd have to do a lot of high level processing on the FPGA to get it behave nicely on an Ethernet network.
  - pveierland 10y ago
    With UDP and custom FPGA IP for handling the packets the processing works fine. Network behavior is made easier as the IO board will mostly be used in a dedicated point-to-point Ethernet connection. Our opinion is that Ethernet is easier to analyze using tools such as Wireshark, in addition to being easier to run in a cable between different PCAs. It also allows the IO board to be easily networked for communicating with development tools to reprogram the FPGA memory, debug issues, do testing from a developer machine etc without concern for driver issues on various host operating systems.
- 10y ago
pekk 10y ago
If only Android apps ran in some kind of virtual machine...

hueving 10y ago

>device which signed your invitation to prove it, then... Then you realize why nobody shows up to your parties. :P

technofiend 10y ago
>>device which signed your invitation to prove it, then... >Then you realize why nobody shows up to your parties. :P Sure they do, but they're all hackers or cypherpunks. Listen all three of us had a great time. :-) :-) But seriously, wouldn't it be fun to host a party where everyone had to hack an invitation?
- hueving 10y ago
  IIRC defcon does this with their badges.

pveierland 10y ago

We designed an architecture for replaceability during the summer for our UAV project. Our current architecture has been based on the Zynq-7000 which is a two ARM-core + FPGA SoC. Here we had custom logic for doing things such as controlling signals to the servos in the FPGA and then software drivers communicating with the FPGA through memory maps. This resulted in a tight coupling between the drivers on the compute platform and the IO hardware. Our next hardware generation will have a dedicated FPGA handling the communication with the GPS, IMU, servos. The compute platform will communicate with the FPGA over Ethernet. This means that all hardware drivers can be written against a network based interface, resulting in a loose coupling between the compute and IO. This means that both the IO hardware and compute hardware can be replaced individually without breaking the setup, and without having to rewrite any drivers. It also results in high transparency for debugging IO, with the possibility of easily recording and playing back a scenario. You can also test the full flight software on a developer's desktop machine during development without the embedded compute platform. As embedded compute platforms get better all the time, while the IO stays more stable, this will make it easy to replace the compute every 2-3 years.

ferologics 10y ago
This is essentially what React Native has done for UI <~> Logic communication, allowing the latter (think iOS/Androind/Apple tv os/macOS etc.) to be replaced by any compute platform - even Compute Card in theory I think. You're applying the same mental model to hardware which can be seen in the similarity of tools that can be enabled on top of such abstraction. Way to go! The flexibility that emerges from decoupling our software and hardware solutions is a [recent] trend that will only gain on traction as more people become aware of it's implications to how we create solutions to technological problems. How can we evangelize this better? From my experience it's complicated to communicate this idea well. not sure if true, may be recency bias or the fact that I'm still young and inexperienced in many ways and lack historical background knowledge in tech
- ferologics 10y ago
  (put an asterisk before "[recent]" not knowing that it will format the comment. HN greenhorn)
chocolatebunny 10y ago
Out of curiosity, why are you going to communicate to the FPGA over Ethernet vs PCIe or SPI or USB? It seems like you'd have to do a lot of high level processing on the FPGA to get it behave nicely on an Ethernet network.
- pveierland 10y ago
  With UDP and custom FPGA IP for handling the packets the processing works fine. Network behavior is made easier as the IO board will mostly be used in a dedicated point-to-point Ethernet connection. Our opinion is that Ethernet is easier to analyze using tools such as Wireshark, in addition to being easier to run in a cable between different PCAs. It also allows the IO board to be easily networked for communicating with development tools to reprogram the FPGA memory, debug issues, do testing from a developer machine etc without concern for driver issues on various host operating systems.
10y ago

pekk 10y ago

If only Android apps ran in some kind of virtual machine...