06-26-2017, 07:13 PM
(06-25-2017, 06:29 PM)pfeerick Wrote: ... It certainly ended up neater than I expected it would!
When looking at the next revision of your code, feel free to reuse anything from pine64-SYSLED-heartbeat.sh that you find helpful. It will work as a regularly logged in user, with the following provisions:
In /etc/rc.local, the following (as it needs to be re-applied every boot):
chown -R root:gpio /sys/class/gpio
chmod -R ug+rw /sys/class/gpio
Then the normally logged in user must be in the gpio group i.e.
sudo adduser gpio
sudo usermod -aG gpio your-user-name
I'm intending in the future to make a systemd service version of it so that the /etc/rc.local mods aren't needed.
I am, at least, 2 times surprised myself... this little exercise "told me" a lot about this core-independency and why, perhaps, we should look more at it... not exactly to solve problems, instead to have one mechanism to run code...
2nd: Instead of using 2 pins to talk to the MCU, there is also a possibility to use 1 pin serial communication from the Pine to the MCU, using soft-serial inside the MCU, so that we can send/receive not only ON/OFF but instead, lots of different messages. The serial comm mechanism can inform at what point in the boot the Pine is, giving a better understanding about the whole thing.
I will look at your code, since I need to have, if not the "official" way to access GPIO, at least one that is more correct than the lines that I am using...
Using the Co-Pine-ON MCU, it is also possible to "manage" the POWER-ON button (I think), if so, we can have more elaborated mechanisms, other than just *switch on* thing... I had this thinking at the beginning, perhaps it is also worth enough to implement it...
(06-25-2017, 06:29 PM)pfeerick Wrote: Also, a comment at the top of your PIC source to indicate that it is for the PIC12F1501
Thanks for pointing this...
This is my (PICKLY) fault... should have this line inside the code...
Version 1 of PICKLY was entirely created around 12F1501 and 16F1503...
A version 2 and plus will be able to handle different MCU targets...
(06-25-2017, 06:29 PM)pfeerick Wrote: EDIT: I also meant to say I'm also eager to hear more about your PICKLY Google Blockly work, as it looks like a great way to get started with PIC programming. Whilst not strictly pine64 related, it deserves future mention here as Google Blockly can also export PHP and Python code, which would be a great starting place for newcomers!
FIRST: Yes, I agree with you about Blockly.
It is a powerful tool to help beginners, but also, I think, a powerful too for the casual coder (I mean, people that from time to time will use/benefit from coding)...
As you said, 'no direct connection to Pine'... but, if instead we take Pine64 as a *computer board*, then, it is not a bad idea to promote both uses in relation to coding... 1 plus 1, in this case, could result in more than 3... lol...
PICKLY: After finishing a "version 1", at least in my oppinion, Blockly has lot to offer, and I like to repeat that IT IS NOT ONLY for beginners, also for the CASUAL coder...
Blockly is relative easy to adapt/change, so, any idea that appears find easy way to code... the only problem is that, each idea implicates in MANY lines of new code... the task of creating the code is relative easy and simple, the VOLUME is the concern... you face a choice between keep adding ideas or making it as minimalist as possible... and BOTH OPTIONS seems cool... !?!?
About Visual Block Programming:
Blockly represent a "jump" on the concept, and still evolving, perhaps another "jump" is possible, or near, and we will be all making use of this "blocks" in every day life...
Valter
PS. Let's also mention that Blockly also generate Javascript...
