New project Bonejs

[William Hermans]

I've recently created very simple wrapper code for several peripherals, and one cmd line tool. In a similar context as Bonescript. Except the code I've written is very minimal and simple. I've been working on this in my spare time, while also working on other project simultaneously. So I may not have thought of everything. However, I would be more than happy to hear complaints, gripes, or suggestions. Just remember there is not much code, and each "module" file is to the point and for one purpose( or small set of similar purposes ) only.

https://github.com/wphermans/Bonejs

[William Hermans]

I'll be adding a new wrapper file for devmem2.c for those of you who might be interested. I'm still skeptical whether this is very useful or not. But I've written an example that "toggles" the USR LEDs in a Cylon like pattern. I think at minimum that it could be used as a learning tool - Of how one can access ( read, and write ) to GPIO registers.

[William Hermans]

Oh, and right. The Cylon blink pattern uses ~5-6% CPU. Which is not too bad for a Nodejs app. I'll have to compare that with a C mmap() / /dev/mem implementation, and see how it stacks up.

[William Hermans]

pwm: https://github.com/wphermans/Bonejs/blob/master/documentation/pwm-readme.md

and

devmem: https://github.com/wphermans/Bonejs/blob/master/documentation/devmem-readme.md

Added. Both are very similar to using each from the cmdline. Personally, I think the devmem wrapper is very cool, but I'm not exactly sure how useful it would, or could be in a production environment.

As stated in the last post. the devmem example twiddles the GPIO registers for the USR LEDs. Using GPIO_DATAOUT directly rather than GPIO_SETDATAOUT, and GPIO_CLEARDATAOUT. The result in my opinion while achieving the same end result, it more inline with low level micro-controller development C code. Thus perhaps easier for someone coming from a bare metal environment to grasp - Initially.

Anyway, have at it, and have fun.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/2b6850e2-0b29-42bb-ae64-12ac3d0c6f78%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[William Hermans]

Granted, I do agree. That discussing low level micro-controller C code, when describing Javascript is a bit odd. But in reality, the heavy lifting is done in C, while Javascript just wraps the executable, and making it perhaps easier to use ?

Quite honestly, a couple of years ago I could not see myself doing something of this nature from Javascript, In fact, I'm still somewhat of a C "purist". But I do see a lot of good in Javascript, and mixing implementations with C to make life easier.

[Jason Kridner]

On Fri, Jul 29, 2016 at 12:19 AM William Hermans <yyr...@gmail.com> wrote:

Granted, I do agree. That discussing low level micro-controller C code, when describing Javascript is a bit odd. But in reality, the heavy lifting is done in C, while Javascript just wraps the executable, and making it perhaps easier to use ?

Quite honestly, a couple of years ago I could not see myself doing something of this nature from Javascript, In fact, I'm still somewhat of a C "purist". But I do see a lot of good in Javascript, and mixing implementations with C to make life easier.

I still "think" in C, but JavaScript really can be rather handy. As much as people seem to want to get rid of curly braces, I still appreciate them over making whitespace meaningful. Besides, everyone has a JavaScript interpreter readily at their disposal almost without exception.

 

On Thu, Jul 28, 2016 at 9:14 PM, William Hermans <yyr...@gmail.com> wrote:

pwm: https://github.com/wphermans/Bonejs/blob/master/documentation/pwm-readme.md

and

devmem: https://github.com/wphermans/Bonejs/blob/master/documentation/devmem-readme.md

Added. Both are very similar to using each from the cmdline. Personally, I think the devmem wrapper is very cool, but I'm not exactly sure how useful it would, or could be in a production environment.

As stated in the last post. the devmem example twiddles the GPIO registers for the USR LEDs. Using GPIO_DATAOUT directly rather than GPIO_SETDATAOUT, and GPIO_CLEARDATAOUT. The result in my opinion while achieving the same end result, it more inline with low level micro-controller development C code. Thus perhaps easier for someone coming from a bare metal environment to grasp - Initially.

Anyway, have at it, and have fun.

On Tue, Jul 26, 2016 at 11:33 PM, William Hermans <yyr...@gmail.com> wrote:

Oh, and right. The Cylon blink pattern uses ~5-6% CPU. Which is not too bad for a Nodejs app. I'll have to compare that with a C mmap() / /dev/mem implementation, and see how it stacks up.

On Tuesday, July 26, 2016 at 11:31:09 PM UTC-7, William Hermans wrote:

I'll be adding a new wrapper file for devmem2.c for those of you who might be interested. I'm still skeptical whether this is very useful or not. But I've written an example that "toggles" the USR LEDs in a Cylon like pattern. I think at minimum that it could be used as a learning tool - Of how one can access ( read, and write ) to GPIO registers.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/2b6850e2-0b29-42bb-ae64-12ac3d0c6f78%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqhGVi9VhxNuTNy6MORk2Z7kPc7Ev6wgOYoBDWwDZHMtw%40mail.gmail.com.

[William Hermans]

On Mon, Aug 1, 2016 at 2:27 PM, Jason Kridner <jkri...@beagleboard.org> wrote:

I still "think" in C, but JavaScript really can be rather handy. As much as people seem to want to get rid of curly braces, I still appreciate them over making whitespace meaningful. Besides, everyone has a JavaScript interpreter readily at their disposal almost without exception.

 

I still think in C too, but that's where a lot of us C programmers can get into trouble with Javascript. *If* we do not understand the Javascript language well. Reading the book "Javascript, the good parts" did a lot to putting me on  the right track, but only after a couple years of misusing the language. Speaking of curly braces, placement of curly braces is important in Javascript. This is something that may sound silly from a C programmers standpoint. But it is true.

Anyway, syntax is similar to C in many cases, but that's really where the similarities end. While I also have a love / hate relationship the non blocking nature of Javascript. It is an awesome feature, but at the same time "callback hell" can be difficult to avoid.

Now days though, I actually write all my prototype code in Javascript. Before porting to C, if I port the code at all. Simply because it is quicker, and easier to get things done in Javascript. Despite having far more hands on experience with C, and other procedural type languages. *shrug* It's all good.

[William Hermans]

Additionally, I guess you could say that I never really took Javascript seriously as a language prior to using Nodejs. Hell, I never really saw web development period as something all that important. Mostly because the languages used, in web technologies, really are not that hard to learn. *However*, there is a hell of a lot more to web development, than just the languages. . .

Also, probably 90% of the Javascript developers out there do not really know what they're doing. This is something I was guilty of myself for a few years.

Passed that, you have "features" such as function chaining, that I personally still think are so wrong. Yes, it is possible, and it may even work well in most cases. But can you read, understand, and follow the code ? I doubt it . . .