Hey, Luke, this might be useful to you... (I *think* I have the right thread here... lol...)
https://hackaday.com/2017/09/17/better-stepping-with-8-bit-micros/
On Mon, Sep 18, 2017 at 6:22 AM, Christopher Havel laserhawk64@gmail.com wrote:
Hey, Luke, this might be useful to you... (I *think* I have the right thread here... lol...)
https://hackaday.com/2017/09/17/better-stepping-with-8-bit-micros/
they're using DMA - which is really what you're supposed to be doing anyway.
the entire arduino software ecosystem was never designed to actually give people proper access to the hardware. anything that's a 180mb download and requires a 200mb runtime environment to compile and upload an executable that's only 16k in size *really* isn't going to end well.
so they're stepping well outside of the "normal" boundaries - good luck to them.
personally i feel it's much better to use a faster 32-bit processor, and to stick reaaasonably within an eco-system. however.... RepRapFirmware is just... genuinely much better-designed than Marlin. it's written in c++, it takes full advantage of OO techniques (Marlin does not. at all). it's also event-driven which means that the highest priority - based on a timer - is the actual stepper moving, with other "tasks" running to handle keeping the queue full... lots more as well.
also as it's timer-based and event-driven it's *automatically* far superior to what Marlin does. if you wanted to use DMA (if it isn't already) it would be far easier to use that in RepRapFirmware than Marlin. Marlin is a hard-coded for-loop with an interrupt for handling moves, but it's bit-banged (!) and... yeah.
anyway. back to PCB work...
l.
On 2017-09-18 at 07:07:04 +0100, Luke Kenneth Casson Leighton wrote:
the entire arduino software ecosystem was never designed to actually give people proper access to the hardware. anything that's a 180mb download and requires a 200mb runtime environment to compile and upload an executable that's only 16k in size *really* isn't going to end well.
Well, IIRC they do bundle gcc(-avr), which tends to be quite big, but doesn't really need to be downloaded again if you already have it from your distribution, and the runtime environment is only needed if you want to use their IDE instead of your favourite editor + a Makefile (and there is (was?) at least one example Makefile somewhere in the arduino package).
Looking at the installed sizes on debian (which has an older version for license reasons) I see that the libraries are about 6½MB and the IDE itself is just 1½MB.
https://packages.debian.org/sid/arduino-core https://packages.debian.org/sid/arduino
To really reduce size they would have to drop gcc, but I don't think that would be a reasonable choice for just the aim of side reduction.
Other than assuming that beginners will be fine with just their IDE (and targeting their documentation at them), I don't think they ever did anything to prevent people from going deeper on their own, as they learned more, including using the arduino board as an AVR devboard completely ignoring the arduino software.
so they're stepping well outside of the "normal" boundaries - good luck to them.
Fully agree here: what they are doing lately makes them at the very least quite irrelevant to the Open Hardware world.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Sep 18, 2017 at 10:15 AM, Elena ``of Valhalla'' valhalla-l@trueelena.org wrote:
On 2017-09-18 at 07:07:04 +0100, Luke Kenneth Casson Leighton wrote:
the entire arduino software ecosystem was never designed to actually give people proper access to the hardware. anything that's a 180mb download and requires a 200mb runtime environment to compile and upload an executable that's only 16k in size *really* isn't going to end well.
Well, IIRC they do bundle gcc(-avr), which tends to be quite big, but doesn't really need to be downloaded again if you already have it from your distribution, and the runtime environment is only needed if you want to use their IDE instead of your favourite editor + a Makefile (and there is (was?) at least one example Makefile somewhere in the arduino package).
yehyeh... it wasn't always like that.
Looking at the installed sizes on debian (which has an older version for license reasons) I see that the libraries are about 6½MB and the IDE itself is just 1½MB.
phil was instrumental in arranging that.
https://packages.debian.org/sid/arduino-core https://packages.debian.org/sid/arduino
yep he recommended to the arduino package maintainer that the actual core parts not be glommed together with a runtime and IDE and everything else.
then there's avr-utils, a few other things, the libraries as well: you can now basically mix and match and use editors and minimal build dependencies... but seriously that's *not* the way it's normally done [by beginners]
To really reduce size they would have to drop gcc, but I don't think that would be a reasonable choice for just the aim of side reduction.
yehyeh.
Other than assuming that beginners will be fine with just their IDE (and targeting their documentation at them), I don't think they ever did anything to prevent people from going deeper on their own, as they learned more, including using the arduino board as an AVR devboard completely ignoring the arduino software.
yeah if you've ever heard of the OSMC (Open Source Motor Controller) that uses a PIC, i bought one back in... 2003 or so. 1,000 lines of c, using not even gcc. no libraries, nothing.
.... when i first heard about arduino i was really shocked at how much the dev environment was.
so they're stepping well outside of the "normal" boundaries - good luck to them.
Fully agree here: what they are doing lately makes them at the very least quite irrelevant to the Open Hardware world.
ho hum :) i really wanted to use RADDS because the Duet 0.8.5 and the Duet-NG are almost as much as an entire 3D printer can be sourced for here... only to find that the damn thing's non-free! they're happy to provide a non-commercial license...
... it was the last straw. i spent the weekend making an improved version of RAMPS 1.4 - called RD3D (yes after R2D2...) and it's been sent for first PCB manufacturing, already, this morning. yes i rushed it, yes i realised i'm using only a 500mA regulator which means it might be current-limited: i'll just have to drop a different LDO in place using some wires.
http://reprap.org/wiki/RD3D/1.0
but guess what? it's GPLv3 and it's *properly open*. and awesome. 6 steppers (RAMPS has 5) and 4 MOSFETs (RAMPS has 3) and an on-board MicroSD card and and and.
it was a very... busy... weekend :)
l.
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Sep 18, 2017 at 10:15 AM, Elena ``of Valhalla'' valhalla-l@trueelena.org wrote:
On 2017-09-18 at 07:07:04 +0100, Luke Kenneth Casson Leighton wrote:
the entire arduino software ecosystem was never designed to actually give people proper access to the hardware. anything that's a 180mb download and requires a 200mb runtime environment to compile and upload an executable that's only 16k in size *really* isn't going to end well.
Well, IIRC they do bundle gcc(-avr), which tends to be quite big, but doesn't really need to be downloaded again if you already have it from your distribution, and the runtime environment is only needed if you want to use their IDE instead of your favourite editor + a Makefile (and there is (was?) at least one example Makefile somewhere in the arduino package).
yehyeh... it wasn't always like that.
Looking at the installed sizes on debian (which has an older version for license reasons) I see that the libraries are about 6½MB and the IDE itself is just 1½MB.
phil was instrumental in arranging that.
https://packages.debian.org/sid/arduino-core https://packages.debian.org/sid/arduino
yep he recommended to the arduino package maintainer that the actual core parts not be glommed together with a runtime and IDE and everything else.
Well, I reacted badly to the Java UI (because it was ludicrously broken under tiling window managers -- the menu required you to click the screen elsewhere to get anywhere, and my screen wasn't wide enough to click anything on the sub-menus ;-) ), and noticed that it was actually possible to use a Makefile, and that there were several Makefiles in circulation, so chose what looked to be the most maintained one, and suggested that the author pick up the nice features in the other ones, and then stuck that together as the arduino-core package.
Then we worked out how to make the arduino package play nicely with that, in order to remove the duplication, so ironically I'm now an uploader on both, including the Java bits, despite the fact that my only motivation at the start was driven by my aversion to Java.
As it happens, I fired up my arduino for the first time since doing the arduino-core uploads last week -- My 5 year old daughter and I are knocking up something to drive some LEDs and a motor in order to make her IKEA kitchen have a working turntable in the microwave, and a blue LED to simulate water coming out of the tap, etc.
I was actually using the IDE for that (which now works with Xmonad) just for expediency, but this reminds me that I should use it as an excuse to make sure that arduino-core still works.
Cool :-)
BTW you called it 'R3D3' in the penultimate paragraph.
Cheers, Phil.
On Wed, Sep 20, 2017 at 9:12 AM, Philip Hands phil@hands.com wrote:
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
yep he recommended to the arduino package maintainer that the actual core parts not be glommed together with a runtime and IDE and everything else.
Well, I reacted badly to the Java UI (because it was ludicrously broken under tiling window managers --
ohh that's right. you use xmonad. written in 1200 lines of haskell if i recall. fricking awesome and scary at the same time :)
the menu required you to click the screen elsewhere to get anywhere, and my screen wasn't wide enough to click anything on the sub-menus ;-) ), and noticed that it was actually possible to use a Makefile, and that there were several Makefiles in circulation, so chose what looked to be the most maintained one, and suggested that the author pick up the nice features in the other ones, and then stuck that together as the arduino-core package.
cool!
yyyeah... have you noticed btw that the way they do "finding of libraries" is... to indiscriminately extend make's "VPATH". all and any headers, object files, modules, executables... *all* of those are searched for in *every single one* of the paths.
if you happen to have the same filename somewhere anywhere in those paths, you're hosed.
it's a total global namespace .... nightmare. nnnngh! whyyyy do they doo thiiiiis!
As it happens, I fired up my arduino for the first time since doing the arduino-core uploads last week -- My 5 year old daughter and I are knocking up something to drive some LEDs and a motor in order to make her IKEA kitchen have a working turntable in the microwave, and a blue LED to simulate water coming out of the tap, etc.
ha, cool! yeah i bought something called a "Sparki" robot for me and lilyana to play with. which was for about... 2 days. the GUI on that however i have to say is extremely cool. it's block-based like a jigsaw, and it auto-generates actual code which you can then look at to see if it does what you expected.
Cool :-)
yeah. just added a 4th MOSFET (2 fans, 1 extruder, 1 heater or 2 extruders, 1 fan, 1 heater), an I2C EEPROM, and whoops added in a 4th endstop (X, Y, Z, Z-probe - Z-probe veeery important if you want to do auto-bed-levelling... *sigh*...)
but i have to say, it is completely insane that i've been driven to design and have manufactured my own 3D printing PCB.
so i had to add that last section in order to explain it - mostly it's for the crowd-funding people who might be going, "wtf???"
BTW you called it 'R3D3' in the penultimate paragraph.
ah good call, thx phil.
l.
l.
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
On Wed, Sep 20, 2017 at 9:12 AM, Philip Hands phil@hands.com wrote:
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
yep he recommended to the arduino package maintainer that the actual core parts not be glommed together with a runtime and IDE and everything else.
Well, I reacted badly to the Java UI (because it was ludicrously broken under tiling window managers --
ohh that's right. you use xmonad. written in 1200 lines of haskell if i recall. fricking awesome and scary at the same time :)
the menu required you to click the screen elsewhere to get anywhere, and my screen wasn't wide enough to click anything on the sub-menus ;-) ), and noticed that it was actually possible to use a Makefile, and that there were several Makefiles in circulation, so chose what looked to be the most maintained one, and suggested that the author pick up the nice features in the other ones, and then stuck that together as the arduino-core package.
cool!
yyyeah... have you noticed btw that the way they do "finding of libraries" is... to indiscriminately extend make's "VPATH". all and any headers, object files, modules, executables... *all* of those are searched for in *every single one* of the paths.
if you happen to have the same filename somewhere anywhere in those paths, you're hosed.
it's a total global namespace .... nightmare. nnnngh! whyyyy do they doo thiiiiis!
As it happens, I fired up my arduino for the first time since doing the arduino-core uploads last week -- My 5 year old daughter and I are knocking up something to drive some LEDs and a motor in order to make her IKEA kitchen have a working turntable in the microwave, and a blue LED to simulate water coming out of the tap, etc.
ha, cool! yeah i bought something called a "Sparki" robot for me and lilyana to play with. which was for about... 2 days. the GUI on that however i have to say is extremely cool. it's block-based like a jigsaw, and it auto-generates actual code which you can then look at to see if it does what you expected.
Sounds somewhat like scratch.
Also in the same vein is the thing from microsoft: 'makecode', that the Love To Code folk at chibitronics are using in conjunction with the Chibi Chip:
https://makecode.chibitronics.com/
makecode also supports other microcontrollers boards, it seems:
The chibi chip is one of Bunnie's projects, for making it easy to do clever stuff with circuits made out of sticky copper tape and stick-on LEDs and sensors -- I'm awaiting one in the post, having found a UK based seller last week:
https://chibitronics.com/shop/love-to-code-chibi-chip-cable/
Bunnie gave a nice talk about it at CCC last year:
https://archive.org/details/media.ccc.de-33c3-7975-making_technology_inclusi...
(for which I happened to be on Main Camera, in the video team filming it)
I particularly like his Sauerkraut analogy about always getting the same outcome if you start with the same ingredients.
Cheers, Phil.
On Wed, Sep 20, 2017 at 4:29 PM, Philip Hands phil@hands.com wrote:
ha, cool! yeah i bought something called a "Sparki" robot for me and lilyana to play with. which was for about... 2 days. the GUI on that however i have to say is extremely cool. it's block-based like a jigsaw, and it auto-generates actual code which you can then look at to see if it does what you expected.
Sounds somewhat like scratch.
ah! yes that was the name of its competing... thing.
The chibi chip is one of Bunnie's projects, for making it easy to do clever stuff with circuits made out of sticky copper tape and stick-on LEDs and sensors -- I'm awaiting one in the post, having found a UK based seller last week:
https://chibitronics.com/shop/love-to-code-chibi-chip-cable/
nice! wasn't there some sort of... circuit pen that you could use to literally draw your own traces? why am i suggesting that you get one when you know full well that your house - from the downstairs to the upstairs will instantly be filled with stickers and line-drawings on the walls... ha, i know why: because i would love to hear that that actually happened :)
I particularly like his Sauerkraut analogy about always getting the same outcome if you start with the same ingredients.
:)
I was wondering if you ever thought of creating a hardware encrypted flash drive? I know nitrokey is doing this, but I was wondering if you could make one that could go even up to 128gb and have the software built into it so that you can set a password from your computer then, everytime you put it in you have to type the password in. Also there would be options of:
change password upgrade firmware if wanted up to four different hidden folders to store files and of course the strongest encryption + ten mistakes = reset whatever hidden folder you were trying to get into. meaning the files would all be wiped off. And yes this could be an option rather than a requirement.
even 64gb would be good to be honest, I just don't like the idea of having to rely on software that may disappear in the future or die out.
Nitrokey's weakness is you need their app to access your files. alas... that's why I suggested this.
if you did that, even 64gb I would pay 200$ for something of that sort. as long as it is gpl3 software that is. :)
Mull it over if you want.
Forgive my inevitable naivety with regard to this sort of thing, but can't gparted create encrypted partitions, and why wouldn't that be secure enough...? My understanding is that it still takes a few hundred years to crack AES encryption with a standard PC... and the average criminals who are likely to blackmail you, I can't imagine they're well funded enough to buy a supercomputer sufficient to pop the lid on those things in a reasonably timely fashion.
Of course, if you piss off the Russian Mob, that's different, at least potentially... but that's also a comparatively pretty rare circumstance, I'd think.
Christopher Havel laserhawk64@gmail.com writes:
Forgive my inevitable naivety with regard to this sort of thing, but can't gparted create encrypted partitions, and why wouldn't that be secure enough...? My understanding is that it still takes a few hundred years to crack AES encryption with a standard PC... and the average criminals who are likely to blackmail you, I can't imagine they're well funded enough to buy a supercomputer sufficient to pop the lid on those things in a reasonably timely fashion.
Of course, if you piss off the Russian Mob, that's different, at least potentially... but that's also a comparatively pretty rare circumstance, I'd think.
Obligatory XKCD: https://www.xkcd.com/538/ ;-)
Cheers, Phil.
The hover text is pretty much my position on the subject -- although I've been informed that it's a rather obsolescent conclusion. (...to which my response almost always is, "I'm sorry, sir/madam/etc, but I'm all out of kitchen foil." ;) )
On 09/20/2017 04:14 PM, Christopher Havel wrote:
Forgive my inevitable naivety with regard to this sort of thing, but can't gparted create encrypted partitions, and why wouldn't that be secure enough...? My understanding is that it still takes a few hundred years to crack AES encryption with a standard PC... and the average criminals who are likely to blackmail you, I can't imagine they're well funded enough to buy a supercomputer sufficient to pop the lid on those things in a reasonably timely fashion.
You could be right, but It would be a good thing for those who lose things they don't want others to access. also, hardware encryption is far stronger than software encryption.
Of course, if you piss off the Russian Mob, that's different, at least potentially... but that's also a comparatively pretty rare circumstance, I'd think. _______________________________________________ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
zap calmstorm@posteo.de writes:
...
also, hardware encryption is far stronger than software encryption.
Faster (potentially), maybe less open to side-channel attacks (if properly designed), but I see no reason that the same algorithm implemented in silicon would be any "stronger" than if it were in software.
Most of the time, what you're calling hardware is liable to just be software running on a different processor, perhaps in a box that has been glued shut such that it's less convenient for bugs to be found, fixed and patched.
Cheers, Phil.
On Thu, Sep 21, 2017 at 11:16 AM, Philip Hands phil@hands.com wrote:
Most of the time, what you're calling hardware is liable to just be software running on a different processor, perhaps in a box that has been glued shut such that it's less convenient for bugs to be found, fixed and patched.
glued shut, electric fences added which electrocute the user, or run the instruction "HCF" [Halt and Catch Fire. mythical iinstruction which was supposed to be in the 68000 or perhaps the 8086, but was actually down to running a loop of instructions that flipped IO and internal logic so hard that the processor overheated). :)
the latest freescale has an on-board Cortex M0 i think it is, which is ultra-low-power enough to run permanently on battery, so you can do tamper-detection.
you'll like this: when i was working for NC3A i was asked to help with a little ethernet network box that transferred data from a low-security environment to a high-security one. the rule was simple: absolutely no physical connection, and absolutely no data must travel - ever from the high security level to the low security one.
that *includes* ICMP packet responses which are normally used to acknowledge and set up even a *UDP* connection.
so somebody wrote a *modified* TCP stack which took out the need for ICMP traffic... but it went way waaay further than that.
the metal box was implemented as an ultra-low power receiver / transmitter pair, with a metal firebreak and a tiny hole between for the radio signal to get through on a Coax cable (so that there was no data leakage by emitted radio waves).
power was SEPARATELY provided on both sides of the box.
then.... when it was confirmed 100% working, the ENTIRE BOX WAS FLOODED WITH RESIN.
bit of a heat problem, that....
baiscally what i'm saying, with this story is: the tricky part will not be the software at all: the tricky bit will be getting a processor into a tamper-resistant, tamper-detecting box.
l.
On 09/21/2017 01:10 AM, Luke Kenneth Casson Leighton wrote: ...snip...
baiscally what i'm saying, with this story is: the tricky part will not be the software at all: the tricky bit will be getting a processor into a tamper-resistant, tamper-detecting box.
I can't vouch for them, but ISTR a project on Crowd Supply to produce a USB password storage device. Been too long to recall how well it meets the criteria for real security.
OT: I've recently gotten back to reading the list after all the list emails got sent to spam for a while.
Tor
talking of crypto usb sticks, theres a new one crowdfunding: https://www.crowdsupply.com/nth-dimension/signet
the dev has been helpful/responsive to my questions too.
the bootloader thing is non-free but that is only used in the factory and for updates it uses its own upgrade software in the firmware.
"There is no proprietary software whatsoever. The only technical exception would be the factory bootloader used to initially flash the device. After initial firmware loading the firmware can be updated live through firmware update in the GPLv3 source base. "
"The factory bootloader is still there but can only be activated by jumpering two to the microcontorller's pins together and rebooting. The signet firmware features an "updgrade firmware" command which is completely free software and does not use the factory bootloader. The best way to describe it is that I have superseded propritatry bootloader but I have not physically destroyed it. I hope that clarifies it. "
just a encrypted database. no pgp cypto done on the device. but maybe possible as stretch goal or something. idea for just passwords and storing other keys and bits.
RNG is a mix of: "When random data is needed it is gathered from three different sources in equal amounts, the host, the hardware RNG on the micro-controller, and clock noise measured between the RTC and processor clocks which have separate oscillators. Once the code has all the three noise values they are XOR'ed together. I think the hardware RNG does have trust issues but by using these sources together even if it has some engineered weaknesses I believe will get a higher quality random data by including it."
had kinda forgotten about nitrokey, arr wondering what to do.... already made a pledge for signet... nitrokey is about same~ price but looks like it does more....
read some technical people reviews of nitrokey err left me feeling unsure about it... :/
https://www.crowdsupply.com/third-pin/pastilda
same sort of thing. basically they use an STM32F4 (both of them). btw when you next speak to them, mention libopencm3 and the fact that i use the STM32F072... there is *absolutely no need* for proprietary firmware-flashing tools with the STM32F range *at all*.
l.
heres there article about smartcards and nitrokey https://www.devever.net/~hl/smartcards
thoughts? :/
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Sep 21, 2017 at 5:50 PM, Alexander Ross maillist_arm-netbook@aross.me wrote:
heres there article about smartcards and nitrokey https://www.devever.net/~hl/smartcards
thoughts? :/
pretty interesting. says it all...
this guy is working on Anelok, a little passwords/keys/etc storage that has a little screen and few buttons:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/mk3-running/on-acc...
mailing list for history of his work on it:
Photos: http://lists.en.qi-hardware.com/pipermail/discussion/2017-February/011048.ht...
latest post: http://lists.en.qi-hardware.com/pipermail/discussion/2017-May/011077.html
arm-netbook@lists.phcomp.co.uk
-
Alexander Ross -
Christopher Havel -
Elena ``of Valhalla'' -
Luke Kenneth Casson Leighton -
Philip Hands -
Tor, the Marqueteur -
zap