PRU Speak - week 1 status

Google Summer of Code
1

The following have been created (links are here):

  • Video
  • Blog
  • Repository
    This week I’m busy with my practicals (I have one tomorrow and one on Saturday), hence I will not be actively coding. Instead,

  1. I will be reading up on kernel module and driver implementation on Linux.

  2. Coming up with a solid detailed design. (i.e.) what is the best way for different components of the project to interact with each other, whether it is a good idea to have sysfs, what pre-processing should be done before the BotSpeak code is sent to the PRU, how the PRU signals user process and vice versa.)

  3. Based on point number 2, come up with an userspace interface (and it’s implementation) for the first iteration of PRU-Speak.

2

What has been done.

(Note that I was free only from 25th may, I had finals earlier this week)

  • Studied the Linux device driver model. Learnt and understood all that I will be needing for this project.
  • Tried out a simple character driver (but this is not really useful for the project as of now)
  • I have developed a simple platform driver and Device Tree which work together.
  • currently working on sysfs entries and bin files. (I read about them, currently implementing them)

Issues

  • I have been slowed down by problems with getting the kernel headers and git time stamps. But all resolved, slowed me down by half a day though.
  • I still haven’t completely understood panto’s probe function in his remote proc driver (still have to figure how to attach the interrupts etc)
  • Have to take a close look at upcalls and downcalls - This could cause a stall in next week’s schedule!

Goals ( by next week)

  • Finish of the prototype of sysfs entries. (can build upon this easily later)

  • Try to implement mmap for the bin files in sysfs
    ----------------------- Up till here in the next two days ( Thursday and Friday ) -------------------------------

  • write logic in the probe function to load a simple PRU firmware.

  • send data to the PRU firmware by mmaping the bin file ( PRU talks with kernel with the help of down calls and upcalls here)
    ----------------------- Till here by Wednesday, end of week two ------------------------
    So by the next meeting I should have a small PRU script that can interact with my driver.

3

WEEK 3 Update (end of week 2)

What has been done

  • Hacked on panto’s driver

  • Understood the flow of control in upcalls and downcalls.

  • Wrote an “Hello word” program for the PRU with the new compiler.

  • Understood how the code on the PRU must be structured, wrote a C+PRU-Assembly code which handles upcalls/downcalls

  • Modified the original driver and DTS, added features of creation of dev_attr and bin_attr sysfs files.

  • Logic in the sysfs will trigger a downcall to the PRU
    Issues

  • The downcall triggers the IRQ handler in the PRU quite successfully, but there is a random problem with the return value while completing the downcall.

  • The overlay once loaded and unloaded can’t be loaded again. [ ‘rmmod’ also fails in a few cases ]
    Goals

  • Write driver support so that PRU, kernel can share memory.

  • Export this shared memory to userspace.

  • Make the firmware support some basic BotSpeak instructions. DIO, WAIT etc

  • Talk up with Chris Rodgers, take his input.

4

Update - End of week 3

What has been done

  • Implemented downcall/upcall via sysfs interface.
  • Coherent shared memory between PRU and Kernel.
  • Exported shared memory to userspace.
  • Basic Botspeak commands is converted into Botspeak bytecode.
  • Interpreter for these instructions on the PRU.
  • Loader infrastructure to load the bytecode to the PRU.
  • Frontend API in python as seen here

Issues

  • My Beaglebone Black was out of commission for 1.5 days in between. It’s highly unreliable and I don’t know when it will refuse to boot next.
  • The kernel driver code requires some cleaning up, will have to just run the tests once again after it.
  • I haven’t been able to catch up with Chris of Tufts university.

Goals

  • Add more botspeak command support to the PRU
  • Discuss with Chris about what he would like to see
  • Add support for scripting and non scripting mode. (blocking and non blocking?)
  • Add control over 2nd PRU
  • If time permits, add PWM functionality.
5

Update - End of week 4

What has been done

  • Cleaning up kernel code and PRU firmware
  • Watched video conference between the PRU Speak team and Chris.

Issues

  • Dengue virus was killing my platelets

Goals

  • Get PRU0 and PRU1 to interact
  • Implement PWM ( will be a bit tricky )
  • Get digital input support for interpreter.
  • Package the whole thing in as a server at port 6060, ( should try to extend this to run code from the browser? )
6

Update - End of week 5

What has been done

  • Package into server, give port like interface.
  • Wrote some examples involving both PRU’s (later will be used for PWM)
  • Played with the timer, should port all the current “blocking” code to timer based.
  • First meeting with Chris

Issues

  • I’m having problems with making the timer work the way I want.
  • I was still in recovery early this week, back in full swing now :slight_smile:

Goals

  • Work on expanding the command set (as discussed previously)
  • After adding Input commands, try to support the language structure as a whole (by this I mean, all sorts of jumps, variables, conditionals etc.)
7

Update - End of week 6

What has been done

  • Got the timer to work, tried a couple of examples to understand the peripheral better.
  • Moved the wait implementation to non blocking.
  • Can execute single commands from userspace while running of the script. (via sysfs)
  • sysfs entry to Abort an executing script - this is used when one script is to be stopped and a new script is to be loaded.
  • Figured out answers to various design problems thanks to two hangouts. Figured how to handle variables, PWM, ADC etc.
    Just drew an overall design here : https://drive.google.com/file/d/0B8Pib9n32qUvMzEwdWV2aUpMbGs/
  • Exported current state of the PRUSpeak VM to userspace via sysfs - tells me weather the PRU is executing a script or not or just waiting.
  • Started working on an shell which Chris can test this weekend. Shell resembles - http://botspeak.org/?page_id=83 (see under step 3 )

Issues

  • The timer took some time to figure out. (debugging it is hard)
  • The structural design of the userspace infrastructure was a pain. spent 2 days on that - but it was very fruitful :slight_smile: Now I know how to go about giving a nice userspace interface.

Goals (In this particular order)

  • Develop the shell which Chris can use.
  • IF statements and arithmetic, bit operations.
  • Support of variables. [ This will be interesting :wink: ]
8

Update - End of week 7

What has been done

  • Developed a TCP (port 6060) server based shell.
  • Developed a bash interface to use PRU Speak. PRU can be used now by writing to “/dev/pruspeak”
  • Defined an architecture for variable use.
  • Instruction set encoding - Done
  • Wrote a lexer to start with compiler upgrade.
  • Wrote a grammar to use in yacc

Issues

  • I’m a bit behind on the Docs as I lost the doc I was writing on (Google Docs has been blocked in India). Have encoding and stuff on paper as of now.

Goals (In this particular order)

  • Finish the parser by 9th Jul (Wed)
  • Finish the code generation 10th Jul (Thursday)
  • Add PRU support for newly generated byte code - 11th Jul (Friday)
  • Develop some sample scripts and debug code if necessary - 12 Jul (Saturday)
  • Buffer day in case of any problem; otherwise Documentation. - 13 Jul (Sunday)
    Now I will have 5 weeks left. General outline plan -
  1. Develop DIO, PWM libraries. (DTO included)
  2. Develop AI libraries, mechanism for return values.
  3. Higher level libraries for SERVO, TONE/Dimming, etc
  4. Develop a web interface to use PRU Speak.
  5. Clean scrub code. Make it easier to install etc.
    (week 2, 3, 4 will include documentation process in parallel)
9

Update - End of week 8

What has been done

  • Developed the encoding scheme put up here : https://gist.github.com/deepakkarki/5c4ac26291338acd7999
  • Completely revamped the user space bindings, which is now powered by ply.
  • The userspace interface handles allocation of variables, maintains state, provides a single and flexible function to handle all compile related tasks.
  • PRU interpreter supports the new byte code (all that it did previously and also setting variable and arrays, whose value can be changed during script execution)
  • Control instructions such as DEBUG, ABORT, SYSTEM etc are working

Issues

  • Debugging the PRU is hard [ I don’t have an oscilloscope on me :frowning: ]
  • I have to figure out how to go about the PWM stuff so that it does not clash with JIT development later on.
  • Still have to handle execution of independent 64 bit instruction.( currently they can be a part of the script only )
  • The normal “GOTO <inst_number>” has to be be replaced by "GOTO "; since script will contain mixture of 32 and 64 bit inst. This is not an issue, but better talk to Chris first.

Goals

  • Complete PRU interpreter to take all inst.
  • sysfs to execute 64 bit single instructions.
  • return values to userspace.
  • Terminal which we can interact with rather than have to execute prog every time.
  • Add label support
10

Update - End of week 9

What has been done
(This week had a lot of debugging work – a old code showed a few problems which I had to debug)

  • Arithmetic inst support added.
  • Got 64 bit inst working.
  • Return values support.
  • Clean userspace interface. Now everything is through Objects and modules.
  • Added a shell for the new compiler framework.
  • 64 bit support for single instruction. (added new kernel sysfs)
  • Conditional ops work.
  • Array declaration instruction.
  • Array size checks.
  • DTS mod to take input. (pru0_r31_14/15)
  • Lot of debugging on what I had done in the previous week.

Issues

  • Have to figure out “digital in” stuff, I tried out some code, don’t know why it doesn’t work though! ( Still haven’t tried too much )
  • Web frontend, I’m not sure as to how Jason plans to go about it. I would need to develop a back end after discussing it with him.
  • I have to figure how I will prioritize the stuff I have to do! (plus tiny bugs showing up in my way – eg. I have to treat DIO/PWM etc as special, different kind of size checking. current implementation treats every array the same, this breaks things that are working)

Goals

  • PWM support
  • AI support
  • Global pin control.
11

You might want to change your Subject: line to show that :slight_smile:

12

What has been done

  • Digital in now working.
  • Got both the PRU’s up and running.
  • Established communication between the PRU’s
  • Lot of painful debugging
  • PWM instruction complete. can generate PWM signals at 2 KHz

Issues

  • PWM works perfectly for pin pru1_r30[0]. PWM[0] to PWM[100] maps to 0% to 100% of 3.3V
    But the other pins work very weird. if I try using pru1_r30[1], it reaches a max of 1.3V
    The other pins can’t even be set to a PWM value. when I try assigning r30[1] even they hold random values such as 0.5V to .95V (when r30[1] = 0.6V to 1.3V viz. max for that pin)

Goals

  • AI support.
  • Where to now? – I have to discuss a few things.
13

What has been done

  • Socket interface
  • FIFO interface
  • modular kernel driver

Issues

  • New Kernel driver works fine except for PWM (which involves pru1, I found out that there is a problem with the pru1 firmware execution. It just doesn’t happen! – or the pin muxing is messed up)

Goals

  • Almost all coding is done. once the modular driver works fine, write a script to setup stuff and document about how to use (with examples) and internal working.